News for hackers. Stuff that matters.

A comment on CBCrypt: Encrypt from the client rather than send passwords to servers. Parent comment

Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Tuesday October 06, 2015 @02:53PM (#10341391)
Yes, you do have to trust the server.
[ Parent | on HN ]
Re:CBCrypt: Encrypt from the client rather than send passwor... by sarciszewski on Tuesday October 06, 2015 @03:34PM (#10341695)
Specifically, to deliver the Javascript in the first place.
[ Parent | on HN ]
Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Tuesday October 06, 2015 @03:37PM (#10341723)
No, I mean, you have to trust it to store password hashes, just like in any other scheme. The ECDH public key is generated deterministically from the password. If you have it, you can crack it to recover the password.
[ Parent | on HN ]
Re:CBCrypt: Encrypt from the client rather than send passwor... by sgk284 on Tuesday October 06, 2015 @04:19PM (#10342027)
His underlying assumption is that given an ECDH public-key it is computationally infeasible to derive the private key / seed that went into creating it (via brute force). I suppose that's a fair assumption if your password has high enough entropy or is stretched sufficiently?
[ Parent | on HN ]
Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Tuesday October 06, 2015 @04:49PM (#10342270)
No. The security of the password storage in this system has nothing to do with that of ECDH.
[ Parent | on HN ]
Re:CBCrypt: Encrypt from the client rather than send passwor... by sarciszewski on Tuesday October 06, 2015 @08:43PM (#10343462)
This sounds worse than I imagined when I was reading through it earlier. Sorry if I muddied the waters earlier.
[ Parent | on HN ]