4 ms·
You can prevent this circumvention by only allowing the client side generated hash to be good for one login attempt. This is done by giving the client a unique
by seekely 17y ago
You can prevent this circumvention by only allowing the client side generated hash to be good for one login attempt. This is done by giving the client a unique challenge string for each login request and hashing the password with the challenge string.
For example, the user browses to http://www.example.org/login http://www.example.org/login. The generated login form on the page contains a hidden field called "challenge" with a randomly generated hash from the server. When the user submits the login form, have the client do a hash(challenge + password) and send this to the server. Upon receiving the hash and checking credentials, the server invalidates the challenge string regardless if the login attempt was successful.
This obviously does not work if the user does not have Javascript enabled and is not preferable to SSL.
- Retric 17y agoSecurity is a hard problem. Unless the server knows the password they can't validate Hash(challenge + password). If you intercept both the challenge and the resulting hash you can brute force the password. If you have a method of safely sending the password in the first place you should probably use that all the time instead of trying to build a JavaScript system to avoid sending the password in the clear. PS: You could implement all the security features of SSL in JavaScript but that wold be pointless and slow. If you really wanted to build a custom security system I would recommended using a Java applet, but even with a team of experts it takes years to build something as secure as SSL.