Ask HN: Why do we still use passwords instead of public/private keys?

https://news.ycombinator.com/item?id=15968203

by jonas123 • 9 years ago

7 7 9 years ago

news.ycombinator.com

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)...

owens99• 9 years ago

From a business perspective

User experience > security

PaulHoule• 9 years ago

If user experience is bad, people will bypass security measures.

DominikSerafin• 9 years ago

Usability.

This is the same aspect that I think will be very important in making Bitcoin/cryptocurrencies viable as a replacement for current currencies

Artlav• 9 years ago

Ideally, passwords are in the heads of users, not accessible from a device. A key would, necessarily, be stored on a device, easily stolen by viruses or by stealing the device.

Also, it takes more discipline and understanding to handle keys than it takes to handle passwords.

Practically, there is no salvation anyway.

hunter2_• 9 years ago

A user who is worried about theft of their private key could put a long [0] passphrase on it, but alas, the service provider who supports key auth can't enforce that keys be passphrase-protected [1]. A user who does this is effectively creating a 2FA requirement for their account. But to your second point, the onus is on the user which isn't ideal.

[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...

Jtsummers• 9 years ago

Key management is difficult. Trust is difficult. Some solutions out there exist that make it easier, but it's still not as userfriendly as passwords can be.

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.

fiftyacorn• 9 years ago

we'd lose them

Ask HN: Why do we still use passwords instead of public/private keys?

Related Stories