3 ms·
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("mypas
by 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 agoThe 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.