security - Should Nonces Be Used During Log-In?

Question

Wikipedia presents the following example of nonce-based authentication:

1. Client requests nonce from server.

2. Server responds with nonce (i.e., hereafter referred to as "server nonce").

3. Client uses server nonce, its own client nonce, and user-inputted password to generate a hash.

4. Client sends user-inputted username, client nonce, and hash to server.

5. Server retrieves both server nonce and user password from its database, presumably via username.

6. Server combines server nonce, client nonce and password to generate a hash.

7. Server compares hash just generated with hash sent from client.

8. If the hashes match, client is authenticated. If not, client is rejected.

Doesn't this imply that the server stores user passwords in plain text? In gross violation of security principles that recommend saving salted hashes of passwords rather than the actual passwords themselves?

Answer 1

This protocol is basically a challenge–response authentication. It is used to avoid sending the actual secret (e.?g., password), but the response can only be valid with knowledge of the secret. And to avoid replay attacks, a nonce is incorporated.

However, the mentioned protocol requires the server to store the secret in a retrievable form (e.?g., plaintext or encrypted).

But you could change the protocol to allow the use of password hashes instead of the plaintext passwords by requiring the client to generate the same password hash:

1. Client requests salt and nonce for user-inputted username from server.
2. Server retrieves salt from its database, presumably via username, and responds with salt and nonce (i.e., hereafter referred to as server nonce).
3. Client uses salt and user-inputted password to generate a password hash and uses the password hash, the server nonce, and its own client nonce to generate a nonce hash.
4. Client sends user-inputted username, client nonce, and nonce hash to server.
5. Server retrieves both server nonce and user password hash from its database, presumably via username.
6. Server combines server nonce, client nonce and password hash to generate a nonce hash.
7. Server compares nonce hash just generated with nonce hash sent from client.
8. If the hashes match, client is authenticated. If not, client is rejected.