CBCrypt: Encrypt from the client rather than send passwords to servers

Re:CBCrypt: Encrypt from the client rather than send passwor... by briHass on Tuesday October 06, 2015 @01:50PM (#10340842)

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_Auth...)

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by k3d3 on Tuesday October 06, 2015 @07:10PM (#10343077)

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.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by creshal on Wednesday October 07, 2015 @04:57AM (#10344905)

> 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.

[ Parent | on HN ]