Ask HN: Why aren't we using paired keys instead of passwords for authentication?
6 comments
You can. You install a client certificate and configure your web application to demand that certificate during the TLS handshake. It works fine.
The reason it doesn't get used in practice is similar to the reason why HTTP Authentication doesn't get used in practice: login is something many apps want to keep control over, and delegating that feature to browser chrome (either in the form of the HTTP Authentication popup, or the [even worse] certificate selection UI) makes it difficult to control login, provide password reset, display user help, &c.
Over the medium term, expect to see 2FA products filling this gap. The phone-based 2FA products all allow web app developers to control their own login UX while mitigating the password vulnerability.
The incipient success of 2FA solutions is also a reason I wouldn't bet on browser-based public key authentication or federation happening; the latter solutions are competing with a more pragmatic, simpler alternative.
The reason it doesn't get used in practice is similar to the reason why HTTP Authentication doesn't get used in practice: login is something many apps want to keep control over, and delegating that feature to browser chrome (either in the form of the HTTP Authentication popup, or the [even worse] certificate selection UI) makes it difficult to control login, provide password reset, display user help, &c.
Over the medium term, expect to see 2FA products filling this gap. The phone-based 2FA products all allow web app developers to control their own login UX while mitigating the password vulnerability.
The incipient success of 2FA solutions is also a reason I wouldn't bet on browser-based public key authentication or federation happening; the latter solutions are competing with a more pragmatic, simpler alternative.
Mozilla Persona is basically this, plus usability and fallbacks for older browsers.
Because paired keys aren't user friendly to a non-developer. Which is most people in the world.
In the current incarnation, no they're not, but built into the browser? The user wouldn't need to see anything more than a "sign in with you private key" button, next to the "sign in with google" button.
Handling them in the browser is a good idea, but still needs a lot of work to make it workable:
- What happens when their computer crashes?
- How do they transfer these certificates to other devices (multiple computers, phones, tablets, etc)?
- How do they keep them in sync across multiple devices if they need to regenerate the certificate?
- Certificates would be super easy to steal once you get access to a device (arguably easier to steal than installing a keylogger to get passwords)
The only way I can see it working for most users is through a third-party management solution (Google, iCloud, whatever).
- What happens when their computer crashes?
- How do they transfer these certificates to other devices (multiple computers, phones, tablets, etc)?
- How do they keep them in sync across multiple devices if they need to regenerate the certificate?
- Certificates would be super easy to steal once you get access to a device (arguably easier to steal than installing a keylogger to get passwords)
The only way I can see it working for most users is through a third-party management solution (Google, iCloud, whatever).
You assume that would remove confusion. If anything it might add to it.
For users, it may seem similar to OpenID (sign in with google/facebook/twitter, etc.) but the public key could be provided automatically by the browser.
Of course, there may be portability issues, but with the availability and prevalence of smart phones, tablets, etc. and with the increasingly common "browser sync", I'm sure that could be easily dealt with.
So if anyone is working on this, where are they, and if not, why not?