http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...
Take OpenID for example. I've encountered a bajillion nay-sayers, "it's too complicated" this and "too many steps for the user" that. So what's "sign in with Facebook" if not a better presentation of the exact same idea? And how many people have no problem using it every day?
To have a security revolution, we need to have a security software revolution. The tech exists for the vast majority of problems, we just need to use it.
Plus: the same problem as normal SSL certs: the registries aren't secure/trustable.
I don't think PKI is the solution for this problem.
BrowserID is moving in the right direction, I can trust Google to have appropriate security for my personal information, but as we've seen time and time again sites like gawker, mtgox cannot be. It would be nice to see a service like BrowserID catch on and I'd be willing to pay for a vendor for the service if they provide full disclosure on their method storing of my data. So I know they aren't storing in plaintext, hashing with md5, encrypting the passwords etc.
Haven't your arguments been refuted by the simple fact that people use keypairs every day to log into servers easily and securely? The last time I had to type an account's password was when I had to run "sudo" on a test server.
Truth is, nobody is giving up good old passwords just yet. Two-factor helps when necessary, but the password is still there.
The actual issue, IMO, is avoiding recovery of the plaintext passwords en masse when a typical website gets hacked. People reuse their passwords. So, as a webmaster, I don't want to be sitting on a pile of weak hashes, etc, etc.
Salted hashes like bcrypt seem to help (as far as I've read about these things). PKI offers even more potential.
E.g. a password-encrypted random keypair could be something - the client gets it at will from the server, decrypts it by prompting for password, and then uses it to authenticate a random nonce from the server.
Effectively, in that situation the server willingly gives up the entire authentication database, but trusts keypair blob's encryption to do its job against brute-force attacks.
That solution doesn't really solve the problems we're seeing all too often these days, user data being stolen and used. How do you determine who gets what encrypted keypair file, what's to stop an attacker from bruteforcing a persons keypair or even selectively attacking someone and decrypting their keypair. (I'm assuming you mean encrypted with a key generated from a PBKDF here).
Authentication is quite the hard thing to accomplish. BrowserID is a step forward for what we have today, but IMO it's not a step in the right direction, it's just moving the burden somewhere else.
I've been experimenting with SSL client certs for a while. They don't have a decent UX/UI in any browser I've used (redxaxder provides a link in another thread) and are a significant hurdle to general adoption. We could maybe see significant process in this area if some well known, popular site, like Facebook or gmail, supported SSL client certificate authentication.
We need to see more work in this area.
