3 ms·
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
by lexs 8y ago
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.
- ilovetux 8y agoI 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.