1

What is the best way to prevent a standard ASP.NET form from submitting certain fields in the onsubmit event? Specifically, I have a registration page where I first validate the fields (RequiredFieldValidator) and then submit the form. However I would like to only submit the password hash from a hidden field, without the actual plain text password field.

I could override the default onsubmit function to nullify the fields before submitting, but then I won't be able to validate the password. What is the best way to handle the situation?

I am writing in C# on ASP.NET 3.5.

Thank you.

JonathanReez
  • 1,319
  • 3
  • 16
  • 34
  • 2
    That is a bad bad idea. You should **always** hash the password on the server. – Daniel A. White Aug 18 '11 at 16:29
  • I hash the passwords with salt during registration and then store the hash on the server. Is this a wrongful approach? – JonathanReez Aug 18 '11 at 16:34
  • For what purpose are you hashing the password on the client? If it's for security, I recommend using HTTPS and be done with it – Earlz Aug 18 '11 at 16:39
  • 1
    When SSL is enabled, the password is being sent in plain-text. When it's disabled (not all hosting environments support it), it's sent as a hash. – JonathanReez Aug 18 '11 at 16:45
  • @Jon oh ok I see then. Makes sense in this case to make something secure. I don't believe it's possible to negotiate a 100% secure connection with just javascript though. Hashing should make attacks significantly harder though – Earlz Aug 18 '11 at 16:49
  • During login, passwords are also hashed with a timestamp, so it should be relatively secure for most purposes. – JonathanReez Aug 18 '11 at 16:51

1 Answers1

2

You could keep the plain text inputs outside of the <form> or remove them with javascript right before submitting the form or just ignore those fields on the server when handling the post.

As for hashing the password client-side, check out this answer...

The only (currently practical) way to protect against login interception (packet sniffing) during login is by using a certificate-based encryption scheme (e.g. SSL) or a proven & tested challenge-response scheme (e.g. the Diffie-Hellman-based SRP). Any other method can be easily circumvented by an eavesdropping attacker. On that note: hashing the password client-side (e.g. with Javascript) is useless unless it is combined with one of the above - ie. either securing the line with strong encryption or using a tried-and-tested challenge-response mechanism (if you don't know what that is, just know that it is one of the most difficult to prove, most difficult to design, and most difficult to implement concepts in digital security). Hashing the password is effective against password disclosure, but not against replay attacks, Man-In-The-Middle attacks / hijackings, or brute-force attacks (since we are handing the attacker both username, salt and hashed password).

Community
  • 1
  • 1
dotjoe
  • 24,002
  • 5
  • 60
  • 72
  • I guess I'll end up redirecting the form's onsubmit event as described [here](http://www.duncangunn.me.uk/dasblog/2008/03/07/InterceptingWebFormOnSubmit.aspx). SSL is used by default of course, but if it's disabled for some reason, I employ hashing. – JonathanReez Aug 18 '11 at 17:20
  • Yes good idea to hash it on the client if you can't ensure SSL will be enabled. It's not bullet proof but better than nothing. – dotjoe Aug 19 '11 at 14:39