How to only send hashed passwords while not storing passwords in plaintext on the sever?

Question

In a web-based auth system I do the following:

1. Client: Ask the server for a "nonce".
2. Client: Generate a "cnonce".
3. Client: hash(nonce + cnonce + password)

4. Client: Send cnonce and the hash from point 3 to the server.

5. Server: hash(nonce + cnonce + password)

6. Server: Compare the hashes.

This would require me to save passwords in plaintext/encrypted as the server needs "password" to calculate the hash to compare with.

Of course I don't want to do this and therefore I hash all passwords saved on the server with hash(password, salt). But now I can't compare with the hash the client sends me as I don't have the password component.

One way to solve this would be to provide the client with the unique user salt so that the client could calculate hash(nonce + cnonce + hash(password, salt)) and send it to the server, allowing the server to compare the hashes. But according to How to store salt? the salt should never be shared.

The reason to why I use nonce on a HTTPS connection is described in: Should I hash the password before sending it to the server side?

So my question is how to get out of this infinite loop of "don'ts"?

Answer 1

To summarise the comments:

I don't fully understand the stackoverflow answer you are referring to. In your explanation you send a nonce from the server to the client over HTTPS which is considered broken in this attack. Therefor the attacker obtains the nonce. A cnonce is generated and both nonces and the password are hashed.

The cnonce and the hash are sent over the (presumably insecure) HTTPS connection. The attacker now has the nonce, cnonce and hash. He can try to reverse the hash to obtain the password (bruteforce). But that is not even necessary as the server is willing to accept the hash and grant access. The attack simply resends the hash. As @Matthew stated, you've just created a password substitute.

You could invalidate the server nonce after one authentication so that if the hash is resent it is rejected. This seems like a security improvement since the attacker could only succeed by reversing the hash which is very hard with complex and long passwords.

Does the effort outweigh the benefit? I think so, HTTPS is considered secure if configured correctly. The entire internet is depending on HTTPS to secure authentication so unless your application is very sensitive, you should rely on it.

Good luck on the assignment!

Answer 2

The objective of the salt is that different accounts will have different hashed passwords (by which I refer to the end result that you store in your db, after all transformations).

Thus, it is not a problem that an attacker learns the salt used for a given user. He could start calculating possible hashed passwords, but he would need a different rainbow table for user, so it wouldn't be useful to engage in such calculations before stealing your database.

The problem with sharing the salt with the client is that you may be leaking the users that exists on your db, as existing users will always return the same salt (you can obfuscate this by returning a salt derived from the given username for users that don't really exist).

Also note that, although you don't specify what exactly is the + operation in your hashes above, you should replace with hmac the steps of taking a hash of the combined values.

For instance, supposing that + was the concatenation operator, a malicious actor that intercepted a login request with nonce=123456789 and cnonce=987654321, could trivially impersonate a login request where the server provided a nonce=12345 (ie. there is an higher probability of getting a valid nonce that just getting exactly the same one).

You may also find interesting the Secure Remote Password protocol (RFC 5054). Although both parties work with plaintext passwords, you could equally adapt it to salted hashes calculated at both sides (your "password" is the output of the salt operation).

Finally, you have to understand that in these schemas, the salted hash is plaintext-equivalent, as that's enough for logging in. You could store that salted password encrypted¹ with an application-specific password (it would have a role similar to a pepper), but nonetheless its properties in case of compromise would be a bit different than in the usual approach. If someone stole your database (eg. from a sql dump in an unprotected backup), this pepper -if not stolen with the db- would be the only thing in the way of the attacker preventing him from impersonating any user.

¹ yes, it needs to be reversible for your protocol to work

Answer 3

The server certainly needs to store a verifier for every password entry. Our verifiers will be (user_salt, server_salt, server_hash) triples, where:

• user_salt and server_salt are random 16 byte arrays.
• server_hash = keyedhash(server_salt, pwhash(user_salt, password)), where:
• pwhash denotes a "slow" password hashing function like PBKDF2, bcrypt, scrypt or Argon2;
• keyedhash denotes a keyed hash function like HMAC-SHA2.

Now we can use an authentication protocol like this:

1. Client: Sends username to server;
2. Server: Responds with the corresponding user_salt;
3. Client: Computes client_hash = pwhash(user_salt, password);
4. Client: Sends client_hash to server;
5. Server: Computes server_hash = keyedhash(server_salt, client_hash);
6. Compares server_hash to the value stored in the user's password entry.

The enrollment/password change protocol is similar:

1. Client: authenticates with the server;
2. Client: sends a password change request;
3. Server: responds with a random new_client_salt;
4. Client: computes new_client_hash = pwhash(new_client_salt, new_password);
5. Client: sends new_client_hash;
6. Server: selects a random new_server_salt;
7. Server: computes new_server_hash = keyedhash(new_server_salt, new_client_hash);
8. Server: stores (new_client_salt, new_server_salt, new_server_hash) as username's new password entry.

Both protocols should be executed over an authenticated, confidential channel (e.g., an SSL connection). An eavesdropper who sees client_hash would be able to impersonate the user.

One of the advantages of a protocol like this is that, in addition to never sending the password over the channel, it computes the slow password hashing function on the client side, which means you can crank up the function's work factor to make password cracking attacks harder.

See also these links for similar proposals:

• https://www.rfc-editor.org/rfc/rfc5802
• http://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication