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

Re:CBCrypt: Encrypt from the client rather than send passwor... by yaur on Tuesday October 06, 2015 @12:04PM (#10339861)

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.

[ Parent | on HN ]

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 ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by creshal on Tuesday October 06, 2015 @12:06PM (#10339876)

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

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by jcranmer on Tuesday October 06, 2015 @12:39PM (#10340150)

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.

[ Parent | on HN ]