Ask HN: Why do we still use passwords instead of public/private keys? Reading about password breaches and how to protect logins, I wonder why it can't just be like with ssh - simple, secure, but virtually unguessable (at least for now)... |
Ask HN: Why do we still use passwords instead of public/private keys? Reading about password breaches and how to protect logins, I wonder why it can't just be like with ssh - simple, secure, but virtually unguessable (at least for now)... |
Also, it takes more discipline and understanding to handle keys than it takes to handle passwords.
Practically, there is no salvation anyway.
[0] It can be brute-forced offline -- https://security.stackexchange.com/questions/62455/find-pass... -- so unlike online password checking that can be rate-limited, length is essential.
[1] https://serverfault.com/questions/589680/disallow-ssh-keys-w...
This is the same aspect that I think will be very important in making Bitcoin/cryptocurrencies viable as a replacement for current currencies
User experience > security
Do you have one key per service? One key per identity and multiple services that you use that key/identity with? Multiple keys associated with the same account?
Keybase offers an interesting way forward since it handles the key management side of things. It can also handle revoking keys and using multiple keys per service (no juggling the keys across devices, each device can get its own key). My two keys could be jtsummers_home and jtsummers_mobile both associated with jtsummers the identity on Keybase. If I add a new device, say jtsummers_internationalmobile, I can add it and still access my services while abroad. And when I want to scrap that one (I've returned home, lost the device, whatever) I can revoke it and services should no longer accept it when authenticating.
Downside is that this is one, centralized, service offering. Better would be a distributed or federated mechanism for the same concept.
If you don't have something like Keybase, then your users will have to have a mechanism of reactivating service after losing a key, signalling you that the a key has been compromised or lost (and you need a way to trust this, how do you do that?). We still don't have good business-to-consumer secure communication. In order for it to be secure you have to be inside their web-based service that the user has authenticated against. This is a bit of a Catch-22 situation. You can't send them a secure email unless the user has a PGP key or similar (uncommon, and we're back to key management and trust issues). You'll also have to accept multiple keys so the user doesn't have to move private keys across devices (a potential point of security failures). And that again gets back to users needing a way to reliably revoke keys for lost, stolen, or otherwise compromised devices.
I've done work with DoD where they use smartcards with a set of public/private key pairs and do exactly what you want. Nearly every service uses these certificates for identity and access control. This is an effective way, but their solution to the trust problem is to issue 3-year keys through a certificate authority. This creates a trust problem for users: How do they know that the CA doesn't make use of their private key somehow. DoD makes use, like many CAs, of a key escrow system where old keys can be retrieved but are, ostensibly, stored offline or behind an airgap of some sort. I believe there is also a mechanism they use to revoke keys early, but I never encountered this.
This works, and for the DoD work I did I had no reason not to trust that the keys were being stored and managed effectively. But I'm not about to trust an arbitrary CA, and many people wouldn't trust a government CA. You have to solve this trust problem as well to move forward.