5 ms·

Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity? That's literally impossible without plaintext passwords isn'

Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity? That's literally impossible without plaintext passwords isn't it. That is insane.

TedDoesntTalk 4y ago
> That's literally impossible without plaintext passwords No, it’s not. It’s called locality-sensitive hashing. You’d store the last 10 LSH hashes in a database next to the SHA-256 hashes. Compare those LSH hashes to the LSH hash of the new password. Match? Reject the new password. It’s also used to identify photos that are similar: https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing
- wizofaus 4y ago
  Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).
  - scrollaway 4y ago
    I remember Facebook doing some things like this. Such as storing the capslock-on variant of passwords as well as various typos.
  - TedDoesntTalk 4y ago
    You’re assuming an attacker can access this database somehow? And that the LSH of “somebody else” is reversible? I’ve don’t understand the vulnerability you’re describing.
    - ahtihn 4y ago
      > You’re assuming an attacker can access this database somehow? Well yeah. Protecting against this is the exact reason passwords aren't stored in plaintext.
    - wizofaus 4y ago
      Yes, obviously, I'm just saying it's a potential vulnerability that doesn't exist if you don't store the LSH. The LSH doesn't need to be reversible - I'm just saying that you now have a situation where if you can find multiple people with the same LSH, if one their passwords becomes known to an attacker for any reason (the attacker could be one of those people!), the other passwords are now much easier to guess.
  - gpderetta 4y ago
    You could salt the LSH with a different per-user salt.
    - wizofaus 4y ago
      True, if you were only concerned about similarity with the same user's passwords.
      - gpderetta 4y ago
        which in this case we are. We don't want to reject a password because it is similar to some other user password. Mind, I think the feature is misguided, but it is probably possible to implement it safely.
_dain_ 4y ago
The hashing has to happen serverside, which means the server will temporarily have the plaintext in memory. While there, you can mutate the string by adding/removing/chanigng characters, to get a bunch of strings that are similar. Then you compare all of those to the old hashes you have stored. It will catch people doing common stuff like incrementing a number at the end on every reset.

Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity? That's literally impossible without plaintext passwords isn't it. That is insane.

TedDoesntTalk 4y ago

> That's literally impossible without plaintext passwords No, it’s not. It’s called locality-sensitive hashing. You’d store the last 10 LSH hashes in a database next to the SHA-256 hashes. Compare those LSH hashes to the LSH hash of the new password. Match? Reject the new password. It’s also used to identify photos that are similar: https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing

wizofaus 4y ago
Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).
- scrollaway 4y ago
  I remember Facebook doing some things like this. Such as storing the capslock-on variant of passwords as well as various typos.
- TedDoesntTalk 4y ago
  You’re assuming an attacker can access this database somehow? And that the LSH of “somebody else” is reversible? I’ve don’t understand the vulnerability you’re describing.
  - ahtihn 4y ago
    > You’re assuming an attacker can access this database somehow? Well yeah. Protecting against this is the exact reason passwords aren't stored in plaintext.
  - wizofaus 4y ago
    Yes, obviously, I'm just saying it's a potential vulnerability that doesn't exist if you don't store the LSH. The LSH doesn't need to be reversible - I'm just saying that you now have a situation where if you can find multiple people with the same LSH, if one their passwords becomes known to an attacker for any reason (the attacker could be one of those people!), the other passwords are now much easier to guess.
- gpderetta 4y ago
  You could salt the LSH with a different per-user salt.
  - wizofaus 4y ago
    True, if you were only concerned about similarity with the same user's passwords.
    - gpderetta 4y ago
      which in this case we are. We don't want to reject a password because it is similar to some other user password. Mind, I think the feature is misguided, but it is probably possible to implement it safely.

_dain_ 4y ago

The hashing has to happen serverside, which means the server will temporarily have the plaintext in memory. While there, you can mutate the string by adding/removing/chanigng characters, to get a bunch of strings that are similar. Then you compare all of those to the old hashes you have stored. It will catch people doing common stuff like incrementing a number at the end on every reset.