Hacker News Reader

Comment by Stefan-H | Hacker News Reader

Not quite - a malicious server would receive the plaintext password in the current status quo.

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.

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.

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.

You could scrypt on the client.

You're still passing the output to the server, which can be repeated. Certainly better than just a password, but not as good as public key crypto.

In the end, I'd probably prefer something like SRP

> You're still passing the output to the server, which can be repeated.

Not if the server generates a unique ID for each attempt, and that ID must be used in hashing. It can be as simple as a timestamp.

Which is then going beyond just using scrypt on the client. What you explain is simply challenge-response authentication.

Reply on news.ycombinator.com