[tripzilch]

> But that requires sites to not be bozos, to deal with a more complex cryptosystem. If we could achieve that then we could just get them to do the damn hashing right.

Not quite.

If a site gets the damn hashing wrong, a successful attack means that your password is now open on the streets.

If a site gets asymmetric crypto wrong, a successful attack means that particular account/site is now compromised, but your pk is still completely private, because you never send it over the network in the first place, bozo site or not. (now if the client is a bozo and allows the pk to be sent across the network, then yes ..)

[dredmorbius]

No: you hash the master password, locally, and use that hash as the value you provide the remote site.

Now, they should also hash the hash, so that should it be know, your account on that site and that site alone cannot be compromised. But your master password is safe.

One of the problems with a scheme such as this is sites with multiple subdomains that use the same account per user. I'm thinking of Stack Exchange and Slashdot, for example. So simply using the hostname to generate a hash won't quite work.

But either this or the PKI method would be vastly preferable to what exists today.

For myself: I've been generating unique, per-site passwords for the past decade or more, and saving those in an encrypted database. Multiple copies of that spread around to prevent loss of access in the event of any single system going down. But otherwise: secure.

[akkartik]

My point was that if we could change every site on the internet to use public keys we wouldn't be having this conversation because they'd already be doing the hashing right with bcrypt.

Sure you can get some sites to use it, and sure you can come up with some way to secure a few savvy people. But it wouldn't elevate ambient security if you expect every site on the internet to change.

Instead my proposal would start securing 80% of the internet by fixing three codebases.