Hacker News new | ask | show | jobs
by peterwwillis 3343 days ago
I remember when cookies was where every site kept their cached credentials in plaintext. It was so popular you didn't need a password manager, just a cookie and form manager.

In case most of you didn't know/forgot: a large amount of the modern security practices on the web are due to browsers making it easy for sites to attack users, and making MITM trivial. The most common attack vector is literally the browser and protocol design, not a bug in the browser.

Also, to replace passwords, all you need is TOTP. You can combine TOTP with a 2nd factor for a little boost, but TOTP is much better than passwords, and more convenient when automated. Combine this with password reset and one-time use codes and the majority of users would not need to remember more than one or two passwords (the password for their e-mail or OAuth provider). You can also password-protect the shared secret to protect data at rest (some VPNs do this as alternative to physical tokens)

A protocol extension could define a handshake to negotiate TOTP tokens. The browser would generate a token with a plugin and send it securely after prompting the user to authorize it, and optionally try to verify the identity of the site. It could be extended to rotate the shared secret after an expiration period.

Also, it's about time we defined a better secure mail standard so we can rely on password resets to be valid and eliminate phishing.

1 comments

It's a nice idea, but their implementation proposal is lame. They keep depending on a phone like a phone is secure or ubiquitous (of which it is neither) or on keyfobs or "gestures" (of which the former nobody will use, and the latter is just a less secure password).

They rely on public key auth, which is more complicated and less reliable than a simple TOTP token. Considering that web browsers already support public key authentication but nobody uses it because their design is a UX garbage fire, I don't think that scheme will work well.

Other things are problematic too, like scripts (rather than the web server) having control of the process; this is an unnecessary attack vector. They also depend on browser-specific technology which limits how this system can be extended to other clients. This spec was clearly written by a JS developer, for JS developers.

This should not be a "web standard". Service providers that need strong authentication for HTTP don't only use web browsers. It will be more useful to be able to support existing applications through the use of an HTTP extension, rather than updating every single web app in the world to support this scheme.

In fact, now that I think of it, you could tack TOTP onto existing HTTP authentication right now! Just allow "TOTP:<token>" as a password entry. I don't know why I didn't think of that before.