01-11-2010, 10:22 PM
I'm not sure if there's really a way to make this more secure - but, this is what I have...
I have a form with a hidden field that retrieves a hashed user ID from a session, and then inserts that info into the hidden form field.
How can I make sure that a user doesn't change this info when submitting the form?
I'm guessing that it's impossible to guard against, since it's a hidden form field and a user could simply change either the session info or just the hidden form field data.
Any ideas on how to make this more secure?
01-11-2010, 10:50 PM
What exactly are you trying to do with the form field?
01-11-2010, 11:40 PM
Why pass the value along if you're already tracking it in a session?
The answer is you can't, any values passed through a form are given to us from a client, so you need to validate everything yourself.
01-12-2010, 07:35 AM
I have a registration page that takes the user to a payment page after successfully signing up.
When the user first registers, a random hashed user ID is generated for that user and then inserted into my database and into a session.
On the payment page, the user ID from the session is inserted into a hidden form field. This user ID is submitted to PayPal when the user makes their first payment. PayPal needs a custom user ID to update my records using the PayPal IPN.
01-12-2010, 12:57 PM
In that case, I'd leave it as it is. If any user tries to tamper with the data it won't let them use the service even if they have paid, so it will be them that is losing out not you
01-12-2010, 01:31 PM
Nice reply Jay.
In fact, if the op has their email, he can send them an email
asking them to play with the data again, maybe a few times ;-)
01-12-2010, 11:45 PM
Thanks for the help!
I hash the e-mail address from the registration page with a random salt, using SHA-1. Then I use that hash as the user ID for each user in the database.
So, I'm guessing it would be fairly hard for a malicious user to generate a hash (user ID) for an existing user anyways, right?
I was even thinking of using SHA-512, but that's probably taking it too far.
01-13-2010, 12:07 AM
I see no reason why you shouldn't use SHA512