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

Re:CBCrypt: Encrypt from the client rather than send passwor... by Retric on Tuesday October 06, 2015 @11:53AM (#10339750)

If a server just wants a hash, then that hash becomes the password. MITM attacks still work as long as all server credentials are public. EX: A fake wifi hotspot wants to MITM a connection and can fake any public information (public key's, IP's, DNS, etc.)

Further, a fake website can sidestep this by not using a secured connection and just faking the UI.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by Stefan-H on Tuesday October 06, 2015 @12:17PM (#10339958)

If you read the mechanism, you'll see that this involves more than a site faking the UI - it requires browser integration. This mechanism does not protect a single site, but rather the ability to pivot from one site to another with the same password or key. You also breeze over "can fake any public information" - I have no idea what you are trying to say by the ability to fake public keys - that is not really a thing. HTTPS rides on having a trusted intermediary and so even a malicious MITM couldn't simply fake a public key.

[ Parent | on HN ]

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

You run into the question, is this the 'magic' UI or a PNG send from HAXORU.

Windows reserves CTRL + ALT + DEL for this reason, but doing that on a tablet / phone that's already in production quickly runs into issues. Also, windows had plenty of issues with fake login screens.

PS: I suspect protecting people from such things ends up requiring fairly strong AI or significant compromises.

[ Parent | on HN ]