
Ask HN: Why do we still use passwords instead of public/private keys? - jonas123
Reading about password breaches and how to protect logins, I wonder why it can&#x27;t just be like with ssh - simple, secure, but virtually unguessable (at least for now)...
======
Artlav
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_
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...](https://security.stackexchange.com/questions/62455/find-passphrase-
on-encrypted-ssh-private-key) \-- so unlike online password checking that can
be rate-limited, length is essential.

[1] [https://serverfault.com/questions/589680/disallow-ssh-
keys-w...](https://serverfault.com/questions/589680/disallow-ssh-keys-without-
passphrase)

------
DominikSerafin
Usability.

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

------
owens99
From a business perspective

User experience > security

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

------
fiftyacorn
we'd lose them

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

