Hacker News Reader

Comment by ilovetux | Hacker News Reader

I don't believe so, I remember learning about Public Key Infrastructure a while ago. It's one of those things (kind of like git) where there is a steep learning curve up front, but once you understand it seems simple.

A password manager on the other hand is just a place to store credentials. Credentials is a concept that most people understand. A password manager in this context could be as simple as a text file on your desktop (not a great idea), or the one included with your browser (a little better, but make sure you set a master password), but if you want more features there are more sophisticated options available.

View on HN

Ok lets compare these approaches rationally, especially from a user perspective. If you let the service provider choose/generate the password it might as well generate your keys for you, there really isn't much of a difference. From a credential management perspective there really isn't a difference either between a long non-human readable password and a long non-human readable private key. They basically suffer from the same problem, neither can be used without access to the credential manager. The only "advantage" passwords in that scenario have is that you don't need to sign anything you can just send it to the relying party however when you rely on password managers to input your credentials anyway that manager can manage signing as well right. I'm not advocating to use PKI instead of passwords just that forcing the use of password managers through very complicated long forced passwords has in my opinion not much of an advantage over PKI when both are equally opaque for casual users.

I understand what you are saying, but the fundamental difference here is that for PKI, the browser has to be configured properly as your key pair must exist and the correct public certificate must be used in TLS negotiation. The advantage here is that the password can be copy and pasted into a password form after TLS has been negotiated.

Coupling authentication with encryption has its place, but I would think that it would work better when accessing a service through an app rather than a browser since the app publisher can create unique a key pair and sign the certificate with their own CA and use that for authentication, but in the context of a web app accessed through the browser copy-and-paste beats having to configure your client certificate per domain at least from a "user friction" point of view.

Reply on news.ycombinator.com