0

Ok, well I seem to have hit a dilemma with my work. I have already got a working registration page on where the user can sign up and all the fields are validated prior to being submitted, this validation is done with the the exact users input and measures the length of the password, username etc.. client side.

However, before the form is finally submitted the password is hashed in my hopes to stop people sniffing out passwords. So the server receives the details and the hashed password. My problem is if the user changes the JavaScript validation to allow for a shorter password my php script will have no way of telling. I can't allow users to have passwords shorter than 8 characters long but it's almost impossible to run validation on the hashed password?

Although if the user has disables JavaScript I can validate the password as it will not of been hashed in the first place but it's if someone has altered the JavaScript to void the validation client side is where I seem to be noticing a problem. Admittedly I could use encryption and decryption but I feel there must be something I am overlooking as I always do.

I don't really see the use of my posting my code but if that needs be I will. I apologize if I'm not very clear with my explanation or if I'm missing something blatant and obvious.

Roy
  • 3,027
  • 4
  • 29
  • 43
  • 3
    Use SSL. Otherwise, any attempts with Javascript to hash, encode, encrypt, or whatever, aren't worth it. You've already pointed out a few flaws, so do your best to simply validate the input, and let the server take care of real validation. – Ian Apr 26 '13 at 19:51

1 Answers1

4

Passwords should be hashed server-side. Otherwise, the hash can be sniffed and replayed just as easily as a plain-text password. Don't forget to uniquely salt as well.

For transport, you need HTTPS.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • That's a very good point actually, I took completely the wrong approach to this. I guess I just didn't like the idea in implementing ssl, thanks. – Roy Apr 26 '13 at 20:00
  • 1
    @user1, There are methods for mostly secure password exchange without HTTPS, but they do not verify the server, so man-in-the-middle attacks are possible. See also: http://stackoverflow.com/questions/2336678/login-without-https-how-to-secure – Brad Apr 26 '13 at 20:15