4 ms·

Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. IMO the

by yaur 11y ago

Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. IMO the current state of things is better than it would be with 1000s of random websites with DBs full of clear-text passwords.

creshal 11y ago
> Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. Do they? Doesn't the server just need to share the salt and algorithm parameters it stores anyway?
- jcranmer 11y ago
  The server can store the salt and parameters, although it gets really hairy if you decide that MD5 is too weak and now you want to upgrade to SHA-1 or SHA-256.
briHass 11y ago
Nah. Hashes of hashes works just fine, and allows the actual password value to never be stored plaintext. A simple example: Stored on server: x = SHA256("mypassword") Server challenge to client: send a secure random nonce Client sends: c = HMACSHA256(nonce, SHA256("mypassword")) Server verifies: c == HMACSHA256(nonce, x) In some implementations, the server challenge and 'c' are encrypted using 'x' or some derivation that both sides can create. In addition, salts can remove the sensitivity of the stored 'x' values (https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...)
- k3d3 11y ago
  The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem. This only mitigates knowing the password itself, not anything to do with authentication.
  - creshal 11y ago
    > The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem. But now you have to grab the hash first from one of the endpoints, MITMing the connection no longer suffices to impersonate the user. I suppose public key schemes would be preferable, but deploying those isn't feasible for a lot of use cases.

by yaur 11y ago

creshal 11y ago

> Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. Do they? Doesn't the server just need to share the salt and algorithm parameters it stores anyway?

jcranmer 11y ago
The server can store the salt and parameters, although it gets really hairy if you decide that MD5 is too weak and now you want to upgrade to SHA-1 or SHA-256.

briHass 11y ago

Nah. Hashes of hashes works just fine, and allows the actual password value to never be stored plaintext. A simple example: Stored on server: x = SHA256("mypassword") Server challenge to client: send a secure random nonce Client sends: c = HMACSHA256(nonce, SHA256("mypassword")) Server verifies: c == HMACSHA256(nonce, x) In some implementations, the server challenge and 'c' are encrypted using 'x' or some derivation that both sides can create. In addition, salts can remove the sensitivity of the stored 'x' values (https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...)

k3d3 11y ago
The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem. This only mitigates knowing the password itself, not anything to do with authentication.
- creshal 11y ago
  > The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem. But now you have to grab the hash first from one of the endpoints, MITMing the connection no longer suffices to impersonate the user. I suppose public key schemes would be preferable, but deploying those isn't feasible for a lot of use cases.