4 ms·
An eavesdropper who overhears a password just has the password, but an eavesdropper who overhears a hash and a salt now has to run a dictionary attack which mig
by Cicero22 6y ago
An eavesdropper who overhears a password just has the password, but an eavesdropper who overhears a hash and a salt now has to run a dictionary attack which might only have a 99% chance of recovering the password.
In the first case, there's a 100% chance of the password being compromised, but in the second an attacker has to spend resources on cracking a password, and there's still a small chance that they're unable to crack it. The second case seems like a clear winner (I could still be missing something).
- jedberg 6y agoYou're technically correct, but if they have access to the plaintext conversation, they can just steal the cookie that comes back. So sure, you may have prevented the release of a reused password, but you haven't prevented anyone from impersonating your user on your site. Depending on how they have access to your plaintext conversation, they could get your reused password from another site. In other words, while this might make a slight difference in the stealing of reused passwords, it's not really worth the effort. There are far better solutions, like encouraging the use of a password manager.
- Spivak 6y ago> but you haven't prevented anyone from impersonating your user on your site. That is the whole point. In this system the hash generated on the client is literally your password. It's just to provide some extra protection for people who reuse passwords that are compromised on the server or over the wire. >There are far better solutions, like encouraging the use of a password manager. That might be better but your solution requires telling billions of people to not reuse passwords and use a password manager. Or you could implement this on your site and your users are instantly better off. Real users are better off if we just make their behavior safer.
- jedberg 6y agoBut it only helps real users in the rare case that someone has already compromised the secure connection between their computer and your server. That's not a realistic use case if you use https on your site. The effort in implementing this, testing it, testing fallbacks when Javascript is unavailable, testing every change with the fallback on and off, and so on, just isn't worth it for that absolutely tiny gain.