That problem is pervasive with any sort of private key system, as well as the password databases becoming popular.
Private key files pose a challenge, absolutely. But is it so much worse than having every company Jack store passwords in $non_crypto_hash_system?
(begin-rumination....
Right now, compromise risk for credentials typically lies on the companies. They frequently fail in protecting these credentials. However, your credentials are - inadvertently - distributed out between multiple companies. When one goes down, the other credentials are considerably less affected.
(More so if you've been bad and used the same password everywhere).
Examining a local store, we centralize risk onto the local desktop. Suppose that in order to log into the user's central system, the user had to provide a password. (Example: gpg-agent). Then, to log into a remote system (web, ssh, etc), the user's credentials get passed into the remote system via some well-known private/public authentication scheme.
Points of failure here:
- user forgets own password. All credentials are lost until they manage to get reauthenticated into the system.
- Malware hacks the user's keystore and uploads private keys to $malware_database. Case 1: in-memory hack. Case 2: hacks system database.
- Case 3-ish. Malware injects dialog requesting system password and gullible user enters it. Upload commences...
I am sure other scenarios can be imagined. In these scenarios, the risk is shifted from the company onto the user (and the key storage engineers).
I can imagine that password forgetting would be heniously problematic and cause PR disasters: many people don't like to take responsibility)
Perhaps a possible solution is to generate a private key in the browser using an algorithm such as PBKDF2 or bcrypt operating against a public per-user salt and a high entropy password. The private key is only kept in the clients memory long enough to sign something for the server.
This is not the best possible solution but I can't see how it would be worse than a compromised salt/bcrypt hash.
Private key files pose a challenge, absolutely. But is it so much worse than having every company Jack store passwords in $non_crypto_hash_system?
(begin-rumination....
Right now, compromise risk for credentials typically lies on the companies. They frequently fail in protecting these credentials. However, your credentials are - inadvertently - distributed out between multiple companies. When one goes down, the other credentials are considerably less affected.
(More so if you've been bad and used the same password everywhere).
Examining a local store, we centralize risk onto the local desktop. Suppose that in order to log into the user's central system, the user had to provide a password. (Example: gpg-agent). Then, to log into a remote system (web, ssh, etc), the user's credentials get passed into the remote system via some well-known private/public authentication scheme.
Points of failure here:
- user forgets own password. All credentials are lost until they manage to get reauthenticated into the system.
- Malware hacks the user's keystore and uploads private keys to $malware_database. Case 1: in-memory hack. Case 2: hacks system database.
- Case 3-ish. Malware injects dialog requesting system password and gullible user enters it. Upload commences...
I am sure other scenarios can be imagined. In these scenarios, the risk is shifted from the company onto the user (and the key storage engineers).
I can imagine that password forgetting would be heniously problematic and cause PR disasters: many people don't like to take responsibility)