Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

Here's a simpler solution: integrate password managers with modern browsers out of the box. Each site I log on to gets a hash of my password with their domain. But I need to install an extension to get this. Just make it more accessible. It doesn't matter if you use sha-1 or md5; it'll get everyone to use high-entropy passwords, and to not reuse passwords across sites. It'll be strictly better (by orders of magnitude) than the current situation.



This does not improve the situation much - if your password is weak it is still easy to recover using a dictionary attack - just compute hash(salt + hash(password + domain)) for common passwords until you find a match in your compromised password database. As long as the only secret is the users password and this password is weak, you are out of luck whatever you do.

On the other hand if your password is strong, then it is very unlikely that an attacker is able to recover it even from a plain unsalted MD5 hash. The only thing gained is protection of reused not-to-weak passwords in the case a system storing plain text passwords gets compromised.


Ah, I see your point. Whereas if people with unsecure passwords saw others logging into their accounts they might be more likely to change their habits. I stand corrected.


> 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 ..)


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.


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.


How do you change the password for just one of your sites after said site is compromised?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: