Well, the problem here is that big corps are doing obviously-wrong things with user data. It's not like there's any uncertainty in the industry about how to do things correctly, it's just that these corps and many others are deciding not to.
What makes you think they would make better decisions if the technology was called something other than "passwords"?
There is no technology that cannot be ruined by ignorant implementation.
Passwords suck for other reasons. This is a poor example.
As silly as it is, it's what I'm doing for a lot of my non-essential sites. Being able to see who I've signed up with is also nice, as I'm sure I'm signed up to a whole host of sites that I have zero memory of.
That, and Facebook supports two factor authentication and (hopefully) isn't leaving their pw db as unsalted md5...
I like using OpenID. I just use my domain name as a delegate and point it at my current OpenID provider of choice for authentication (which is currently my Google profile; used to be myOpenID 'til they went down for 1/2 a day). As long as I retain my domain name, I can control authentication, even if my current provider were to be compromised (just point my domain name/delegate at a different provider).
The problem, of course, is a lot of sites still don't support OpenID.
TLS does allow client authentication using keys. It is a flawed solution as it puts too much importance in protecting the key. What happens when you need to login from an internet cafe? How do you securely move keys between devices? What happens when the machine has malware that steal the keys?
Good security assumes that everything can and will be compromised and provides defence in depth. Client certs do little to help.
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.
