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

Re:CBCrypt: Encrypt from the client rather than send passwor... by dchest on Tuesday October 06, 2015 @02:48PM (#10341360)

Yes, there's a challenge/response scheme (like in SRP), so the communication part is slightly improved, but what I'm talking about is that the server stores public key, and this public key is deterministically derived from password, thus stealing the database of public keys from the server is equal to stealing the database of password hashes (like in SRP).

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by hinkley on Wednesday October 07, 2015 @03:20AM (#10344654)

I haven't read their code or critiques of it, so I can't say if that's the case for this algorithm.

But for this class of algorithms, that doesn't have to be the case. Starting with a cryptographic hash could keep the key from being reversed to the input. There are probably other things that could help as well, like maybe not using the password in the public key at all.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Wednesday October 07, 2015 @10:16AM (#10346124)

How exactly does "starting with a cryptographic hash" solve this problem?

Remember, the attack is: start with "aardvark", run the deterministic key-generation process, hash, scrypt, elliptic curve and all, and check to see if you get the same result. If you don't, move on to "apple", then "ataxia" and so on.

The attacker has every piece of information in the system except the password string, which they can substitute with a dictionary.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by sarciszewski on Wednesday October 07, 2015 @01:01PM (#10347225)

I haven't had a chance to look at the code yet, but riddle me this: Are they eschewing salts entirely?

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Wednesday October 07, 2015 @01:05PM (#10347255)

Yes. The same [password,name,host] tuple should produce the same keypair.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by zaroth on Wednesday October 07, 2015 @09:46AM (#10345943)

It's not a question of reversing the hash, it's a question of what is the 'password validator' and what are the inputs to the algorithm which get you from 'candidate password' to 'compare result to the password validator and return true or false'.

[ Parent | on HN ]