5 ms·

Having to mount a dictionary attack which may fail/ take an indeterminate period time seems like a win. Albeit only for users who reuse the same, strong passwor

Having to mount a dictionary attack which may fail/ take an indeterminate period time seems like a win. Albeit only for users who reuse the same, strong password.

jedberg 6y ago
Exactly. And if they’re using a strong password already than you haven’t gained anything. The dictionary attack on the client created hash and the attack on the server hash of the plaintext take the same effort.
- Spivak 6y ago
  Right, but if you steal the client-hash you have the user's password for this service. If you steal their plaintext password you have their password for every service. This measure is to limit the blast radius of a compromised password given that people reuse passwords.
  - jedberg 6y ago
    No, if you have the salt and the client side hash then you do a dictionary attack and you have their plaintext password, the one they presumably use on multiple sites. All you've done is move your attack from the server to the client. It's the same attack on both ends.
    - Spivak 6y ago
      This doesn't do anything to make a weak password stronger, it makes a strong password resilient to being compromised over the wire or by an errant console.log(http_request) on the server. If the password is so weak that you can just invert the hash then there's not much that can help you.
      - jedberg 6y ago
        If they're on the server seeing your console.log, then they can just change the javascript to stop hashing the passwords on the client side.
- 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 ago
    You'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 ago
        But 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.
- bhl 6y ago
  I agree with jedberg’s assessment that the password scheme described above, while preventing the direct transmission of a plaintext password, is still vulnerable to an offline dictionary attack in the event the server database is compromised. One solution may be to look into https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

Having to mount a dictionary attack which may fail/ take an indeterminate period time seems like a win. Albeit only for users who reuse the same, strong password.

jedberg 6y ago

Exactly. And if they’re using a strong password already than you haven’t gained anything. The dictionary attack on the client created hash and the attack on the server hash of the plaintext take the same effort.

Spivak 6y ago
Right, but if you steal the client-hash you have the user's password for this service. If you steal their plaintext password you have their password for every service. This measure is to limit the blast radius of a compromised password given that people reuse passwords.
- jedberg 6y ago
  No, if you have the salt and the client side hash then you do a dictionary attack and you have their plaintext password, the one they presumably use on multiple sites. All you've done is move your attack from the server to the client. It's the same attack on both ends.
  - Spivak 6y ago
    This doesn't do anything to make a weak password stronger, it makes a strong password resilient to being compromised over the wire or by an errant console.log(http_request) on the server. If the password is so weak that you can just invert the hash then there's not much that can help you.
    - jedberg 6y ago
      If they're on the server seeing your console.log, then they can just change the javascript to stop hashing the passwords on the client side.
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 ago
  You'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 ago
      But 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.
bhl 6y ago
I agree with jedberg’s assessment that the password scheme described above, while preventing the direct transmission of a plaintext password, is still vulnerable to an offline dictionary attack in the event the server database is compromised. One solution may be to look into https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof