[dekz]

So you either require the user to somehow sync a private key across multiple computers (Including phones and tablets) or the can't access the site with this method. Do you agree on the digest, method, sizes? Do you blacklist md5, sha1? Does everyone agree to this or can I go to one site which uses an insecure algorithm and theres the potential for information to be leaked, which affects my usage of that private key on other websites. Do I have a private key for each different website? Do I then need something to manage this for me, ala KeyPass or 1Password? How do I authenticate with KeyPass or 1Password, with a password? We're back to where we started.

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.

[pavel_lishin]

Haven't all of your questions basically been answered in practice by the fact that keys are simple and effective when used to log in over ssh? Do you have a different private key per each server you log into, does a compromised server automatically render your keypair worthless, do you have software to handle keys now?

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.

[tptacek]

The first time you log into an SSH server, your connection is actually insecure (this is also true of every subsequent time you log in and see that yes/no dialog).

[parfe]

It's insecure in that you don't know the identify of the endpoint without verifying the fingerprint out of band. That problem is already solved in browsers thanks to SSL certs and certificate authorities.

[cosgroveb]

Is there any way to be sure of an server's ssh fingerprint before logging in? You need to do that offline right? Maybe a PGP signed e-mail from the sysadmin?

[tptacek]

That's exactly the kind of thing you're supposed to do to verify those keys.

(I don't either).

This is a much bigger deal in a web setting, though.

[mmatants]

The big question is what kind of problem is being solved?

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.

[dekz]

> the client gets it at will from the server, decrypts it by prompting for password

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.

[mmatants]

So the server stores a keypair for the given account, and the keypair is encrypted with the account password. The keypair itself, once "unlocked" on the client-side, is then used to encrypt/decrypt a nonce at login time.

The inherent trait of this approach is that an attacker gets everyone's encrypted keypairs "for free", and can brute-force away. My hope was that the keypair's own encryption is more resilient to brute-forcing than a hash.

But that's very much questionable.