[taeric]

I'm curious how you think these other items work. They ultimately boil down to a shared secret that is beyond what you can remember. Which... isn't the best thing, necessarily.

Consider, if I leave my hardware token at home when I go on vacation, I'm basically locked out of all of my accounts. This is fine, as I typically plan for this to be the case. But it is an attack vector. I can't even audit my protected assets while away.

[Zamicol]

The point of public key cryptography is that there isn't a shared secret.

[GoblinSlayer]

A shared secret is not an attack vector though, a reused secret is. If you reuse an asymmetric key, it will identify you across the world. But if you don't reuse an asymmetric key, then the point of asymmetric cryptography is moot and is no better than a password manager.

[nybble41]

Using something like the Hierarchical Deterministic approach used for modern cryptocurrency wallets ("HD wallets") you can reuse a single master asymmetric key for any number of logins without linking those logins together.

In this scheme there is a single master private key which you protect in whatever way seems best and never share with anyone. From this master private key you can derive any number of subordinate private keys, each with its own public key. You share one of those public keys with each service, along with the derivation path, and authenticate using the corresponding private key. Only the unchanging master private key needs to be stored, so unlike a password manager there is no need to make new backups or sync a password database across multiple devices when you set up a new account. Best of all, without either the master private key or the corresponding master public key there is no (known) way to show that any two subordinate keys were derived from the same master key—they appear unrelated.

[krupan]

Identifying yourself is the whole point of logging in to a website. Yes, if you want to maintain a distinct digital identity for each website you’ll need to use a different key pair for each website, which by the way is actually feasible.

With our current email-address-and-password scheme that is so difficult to do it might as well be impossible. You’d need a distinct email account for each distinct digital identity that you want to maintain.

[GoblinSlayer]

If a web site wants your email address or phone number, it will require them, asymmetric cryptography won't help you. On the other hand, this very site uses password authentication, but doesn't require an email address.

[yosamino]

While technically correct, a private key will usually need to be encrypted to provide adequate security.

From the user point of view, they will still need to remember the password to unlock this private key.

[taeric]

Further to this point, the shared item is moved to a public key and the infrastructure to facilitate communication. Such that it is not a panacea. Getting away from trust in the system is...

Likely you will envision a system to register your key. And then you have to have a bootstrap to authenticate to this system. Probably a password.

[krupan]

Right, if it’s not a panacea then we should definitely not pursue it.

[taeric]

Not my point. Just not clear that the alternatives actually are better. Again, I use hardware tokens. Not seeing my family join me on that anytime soon.

List of problems with every approach always falls back to, "what happens if you lose it?"

And the resolution to that is always outside of the technical chain.

[krupan]

But from a security point of view this is a massive improvement! That password is never shared with anyone else. Someone has to first get ahold of your private key before they can start brute forcing that password in order to steal credentials. This is not a trivial thing! Plus users only need that one password, not a unique one for every website/app.

[jjav]

More generically than "shared secret" which is one implementation, the idea is shared trust.

We both (client and server) trust some common background info. It can't be hand-waved away because that trust must exist or be established.

Shared secrets (passwords) are close to an optimal solution when considering all possible criteria. Various forms of PAKEs can be better sometimes, but not very popular. Other solutions address different threat models, often with more significant tradeoffs than a shared secret.

[krupan]

How is any of that worse than passwords? I only see improvements. Still not perfect, but big improvements.

[taeric]

My question is how is it any better? A weak link is the trust chain, in both.

For problems, easy ones to consider is that of access. Easy to forget to take a key with you. Or lose it in a fire/disaster.

You can also be compelled to turn over a hardware token. Or a digital file.