4 ms·

> The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is.

by csydas 4y ago

> The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These checklists are pushed on regulators who likely lack any ability to assess the validity of such requirements, rubber stamp the checklists into regulations, and now you have a series of unenforceable or ridiculous security policies and practices that basically serve to frustrate the user while failing to prevent actual attacks. I've been at companies where there were rather interesting policies like - Three factor authentication (because a single method isn't enough for some reason) - No password managers allowed (how this is enforced is completely unknown) - 6 week password lifetime - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) - Random character requirements/limitations (you must use non-letter characters from set X, but not from set Y, and absolutely only latin letters) And those are just some of the bangers surrounding password policies; the less said about the network security policies and antivirus policies the better. And these requirements don't come from some regulation/risk assessment group; they're enforced by such groups, but the actual requirements come from some security firm that sell lists and a stamp of approval once you have every box checked. It's difficult to not look at such firms as swindlers with a guaranteed paycheck from a captive audience; they sell their services to regulators as a benchmark to meet, and then in turn they sell implementation services to companies that are forced to meet said regulations. And the end result is just extremely frustrated users who still end up falling for "Hey Bob check this out" phishing emails which is plenty for an attacker to get in and jump around your network until they compromise enough of the environment to take the business down. But hey! The business followed the checklist, so they can't be held liable for exfiltrated data!

nulbyte 4y ago
> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.
- dalyons 4y ago
  I think you missed the word “similarity”. You can’t check similarity with hashes, only exact matches
  - mijoharas 4y ago
    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.
koolba 4y ago
> Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Most systems that allow you to change your password require the current password as a verification. This means the software performing the validation of the new password also has access to your old password and could perform a comparison of the two to see how many characters differ or the overall edit distance. If only the new password is available, it’s still possible to perform this analysis against older password hashes by simply manipulating the new password and checking if it validates against the old hashes. Possible transformations are replacing any numbers with other digits, e.g. “foobar2” would check “foobar1” through “foobar9”.
- csydas 4y ago
  ah, that's reasonable and logical I guess to just do common "simple" transformations and check the hash. Thanks!
  - AstralStorm 4y ago
    It's not that easy, normally having function have a big avalanche factor - even one bit changes the whole hash. There are some malleable having algorithms but they're necessarily less secure. If you're sending multiple hashes to check nobody is stopping the user from sending garbage, except their lack of JS/browser skill. If you're sending the plaintext password, what are you doing using a hash? When your backend is compromised, attacker will just grab all the password when they're getting changed.
    - csydas 4y ago
      No, I think you misunderstood the post I responded to a bit. In the case where the current password is captured on the password change, you have two plaintext values that aren't stored yet and you can just do some text analysis and understand how close they are. With past passwords, you just take the current input and transform it with common transformations (adding numbers, incrementing/decrementing numbers, etc), hash it, and see if it matches a previous password hash. If so, then you know that they're using a very similar password pattern repeatedly.

by csydas 4y ago

nulbyte 4y ago

> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.

dalyons 4y ago
I think you missed the word “similarity”. You can’t check similarity with hashes, only exact matches
- mijoharas 4y ago
  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.

koolba 4y ago

> Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Most systems that allow you to change your password require the current password as a verification. This means the software performing the validation of the new password also has access to your old password and could perform a comparison of the two to see how many characters differ or the overall edit distance. If only the new password is available, it’s still possible to perform this analysis against older password hashes by simply manipulating the new password and checking if it validates against the old hashes. Possible transformations are replacing any numbers with other digits, e.g. “foobar2” would check “foobar1” through “foobar9”.

csydas 4y ago
ah, that's reasonable and logical I guess to just do common "simple" transformations and check the hash. Thanks!
- AstralStorm 4y ago
  It's not that easy, normally having function have a big avalanche factor - even one bit changes the whole hash. There are some malleable having algorithms but they're necessarily less secure. If you're sending multiple hashes to check nobody is stopping the user from sending garbage, except their lack of JS/browser skill. If you're sending the plaintext password, what are you doing using a hash? When your backend is compromised, attacker will just grab all the password when they're getting changed.
  - csydas 4y ago
    No, I think you misunderstood the post I responded to a bit. In the case where the current password is captured on the password change, you have two plaintext values that aren't stored yet and you can just do some text analysis and understand how close they are. With past passwords, you just take the current input and transform it with common transformations (adding numbers, incrementing/decrementing numbers, etc), hash it, and see if it matches a previous password hash. If so, then you know that they're using a very similar password pattern repeatedly.