Hacker News Reader

Comment by downandout | Hacker News Reader

This is still nothing more than a password...it's essentially just a password that is emailed to you. I've never understood why we can't instead authenticate ourselves to our browser or device, and get people out of the habit of authenticating to individual websites. This would eliminate phishing and greatly enhance security. Touch ID is a big step in this direction, but still can't be used for websites.

When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.

View on HN

It is possible to use public key authentication with most modern browsers (not sure exactly which browsers support this). However, it's true that browsers currently don't provide any method to authenticate the user with the browser itself. (Although you could argue whether or not this is necessary since the user has presumably already authenticated with the machine running the browser.)

The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.

You could login to the browser using a password. It would still be valuable to reduce the design problem space to one username/password, rather than one for every stupid site and app on the internet.

Absolutely. My point was that this is not currently possible without any sort of browser extension. However, I think password managers are a reasonable solution that does indeed generally only require one password. (A bit of a simplification of course since multiple passwords do exist, but at least you don't have to deal with them as a user.)

I've been wondering whether the concept in the article could be expanded out using client auth certificates.

So instead of clicking the login button and getting an email every time you need to authenticate (or using really long sessions), you use the "email to login" method once per new device. The resulting page takes the user through creating and uploading a client auth certificate, and stores it (along with a user provided device name to allow revocation).

In-browser cert+key generation is not perfect by any means but it certainly is possible - it's how providers of S/MIME certificates [1] are able to give you a signed certificate without you manually creating a private key+csr and uploading it.

[1] e.g. https://www.comodo.com/home/email-security/free-email-certif...

TLS client authentication [1] is doing this already.

[1]: http://www.browserauth.net/tls-client-authentication

> This is still nothing more than a password

No, it's an OTP. And that's so much more than a password...

Reply on news.ycombinator.com