What pros and cons are there to a one-time random salt between client and server?

Question

In researching on best practices in hashing passwords using a salt I came across a presentation on slideshare. The approach outlined is as follows

1. Client requests login page
2. Server-side code generates random SALT and sends the SALT back to client along with login form
3. 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
4. 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.
5. Server-side code compares A and B and if they match the user is authenticated.
6. Salt is destroyed on server-side.
7. 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.

Answer 1

Indeed, this approach does not help against the theft of the password database. It's easier to see why: it concerns only the exchange of data, and does not impact the database format. Since the database stores direct hashes of passwords, it is vulnerable to a rainbow table attack, making all but the highest-entropy passwords breakable.

This one-time random value is a nonce, and such values are indeed commonly used in communication protocols to avoid replay attacks. Without a nonce, an attacker could eavesdrop on a legitimate conversation and replay later the login phase with the server. You might find such implementations because it is useful under the following hypotheses:

• the communication uses HTTP;
• the attacker can passively listen to all TCP/IP communications but cannot directly talk to any client, only to the server.

There are old web applications designed under these hypotheses. Adding a nonce to the login phase was a significant burden to attackers in the days when they were mostly bored college students on university campuses. In today's world of ubiquitous advanced networking tools and computing devices, assuming that TCP connections cannot be hijacked is not realistic. Such a protocol is vulnerable to a man-in-the-middle attack where the attacker provides a fake DNS response to the client or hijacks the TCP connection. Using HTTPS (with proper authentication of the server, i.e. proper validation of the certificate) makes the addition of a nonce to the login protocol itself redundant (HTTPS itself contains a nonce so that connections cannot be replayed).

Answer 2

You are correct in saying that this type of salt does not delay password cracking if a database of password is obtained. Rainbow tables can used to crack passwords easily.

From my (very limited) experience, i have not seen any implementations of such a feature.

I don't really see how it would prevent a bruteforce attacked from the application frontend, as a new salt is generated, appended and compared each time, while the hash of the password remains the same.

The only thing i can think of that this prevents is an attacker passing of one login session as another(different salts each time), although such stuff could be tracked easily through logs.

Notes: I have not actually clicked through the slides, and is basing my answer of the outline you gave.

I would be interested in hearing any opinions to the contrary, as i really can't see how this is useful at all.

Answer 3

In such uses it's a nonce, not a SALT, and what you are describing is a form of challenge response protocol. See CRAM-MD5 for a standardized protocol similar to what you are suggesting (it's about one step different).