In researching on best practices in hashing passwords using a salt I came across a presentation on slideshare. The approach outlined is as follows
- Client requests login page
- Server-side code generates random SALT and sends the SALT back to client along with login form
- Client-side JavaScript generates a hash of the password entered by the user added to the salt (hashpwd + salt) called A and sends this to server along with the username
- Server-side code retrieves the hashed password for this user from the db and uses it to generate a new hash (hashpwd + salt), called B.
- Server-side code compares A and B and if they match the user is authenticated.
- Salt is destroyed on server-side.
- The next sign-in request generates a new SALT that only survives for that request.
In this approach the passwords are stored in the database hashed but without a salt. So if the passwords are stolen (like LinkedIn), am I right in saying this approach is useless? Without a hash the password can be cracked relatively easily. What protection does this approach offer? I think it prevents replay attacks by generating a new SALT and makes brute-force attacks from the front-end impossible too. I would be interested to hear insights into this approach and a good list of pros and cons of the approach. I am not a security expert by any stretch of the imagination.