3 ms·

Wells Fargo used to require that a new password be sufficiently different from an old password. e.g. if my password was "Madison111$" I could change it to "Madi

by wj 7y ago

Wells Fargo used to require that a new password be sufficiently different from an old password. e.g. if my password was "Madison111$" I could change it to "Madison222$" except that when I did so I would be prompted to change it again the next time I logged in. Since I always iterated on a version of my password this was an issue. The reason was explained to me when I finally called and asked why I was being required to change my password every single time I logged in. So, I changed Madison to Matthew and was good to go. Not sure how they were doing that if they weren't storing the password in plaintext.

apocalyptic0n3 7y ago
It is definitely possible to do that. When the user submits a password to save, it hashes it and saves it to the database. At the same time, it calculates x number of variations of the passwords, hashes those, and saves those to the database as well. The next time you go to update your password, the hash gets compared against the actual previous hash as well as the x number of hashed variations and if any match, it gets rejected. Not super efficient and in most cases, probably not worth the effort. But completely doable to do.
- StavrosK 7y ago
  How many variations will you store? It's very easy to calculate the Levenshtein distance on plaintext data, but basically impossible to enumerate all the variants and hash them.
Eric_WVGG 7y ago
they could do it without plaintext by storing hash(/^[a-zA-Z]+$/)
helen___keller 7y ago
One (devastatingly bad) way to do that is to store hashed subsets of your password string, say the first and second half, and if one matches then your new password is considered too similar to the old password Note that this demolishes the security protection of hashing because brute forcing two (n/2) length password hashes is much easier than brute forcing a length n password hash.
acranox 7y ago
For user accounts on a Linux system, this is often done during the change process. `passwd` asks for the old password, and then the new password twice. At this phase, the password program knows both the old and new passwords unhashed, and can compare them. So while the other answers may also be right, if it's really just comparing the current password to the old one, then it can be done this way without storing passwords in plaintext. But it was a little unclear to me from your description how many old passwords are being compared, or if the the password change method requires entering the old one too.
0xcde4c3db 7y ago
One way to do this is to store a much weaker hash of the password and require some minimum difference in that hash, e.g. add all the character codes together, and reject a new password if its sum doesn't differ by at least 50.
nojvek 7y ago
Microsoft does this. When logging into PowerBI, you have to change passwords every 6 months. They somehow store last 5 used password patterns and won’t allow re-using them. So for every 6 months you gotta come up with new combinations and remember them. It’s a pain in the ass because I only login once in a while. I refuse to use their software until they give a sane password experience with two factor auth. Well I refuse to use it because I have to click 20 things before I can even proper login.

by wj 7y ago

apocalyptic0n3 7y ago

It is definitely possible to do that. When the user submits a password to save, it hashes it and saves it to the database. At the same time, it calculates x number of variations of the passwords, hashes those, and saves those to the database as well. The next time you go to update your password, the hash gets compared against the actual previous hash as well as the x number of hashed variations and if any match, it gets rejected. Not super efficient and in most cases, probably not worth the effort. But completely doable to do.

StavrosK 7y ago
How many variations will you store? It's very easy to calculate the Levenshtein distance on plaintext data, but basically impossible to enumerate all the variants and hash them.

Eric_WVGG 7y ago

they could do it without plaintext by storing hash(/^[a-zA-Z]+$/)

helen___keller 7y ago

One (devastatingly bad) way to do that is to store hashed subsets of your password string, say the first and second half, and if one matches then your new password is considered too similar to the old password Note that this demolishes the security protection of hashing because brute forcing two (n/2) length password hashes is much easier than brute forcing a length n password hash.

acranox 7y ago

For user accounts on a Linux system, this is often done during the change process. `passwd` asks for the old password, and then the new password twice. At this phase, the password program knows both the old and new passwords unhashed, and can compare them. So while the other answers may also be right, if it's really just comparing the current password to the old one, then it can be done this way without storing passwords in plaintext. But it was a little unclear to me from your description how many old passwords are being compared, or if the the password change method requires entering the old one too.

0xcde4c3db 7y ago

One way to do this is to store a much weaker hash of the password and require some minimum difference in that hash, e.g. add all the character codes together, and reject a new password if its sum doesn't differ by at least 50.

nojvek 7y ago

Microsoft does this. When logging into PowerBI, you have to change passwords every 6 months. They somehow store last 5 used password patterns and won’t allow re-using them. So for every 6 months you gotta come up with new combinations and remember them. It’s a pain in the ass because I only login once in a while. I refuse to use their software until they give a sane password experience with two factor auth. Well I refuse to use it because I have to click 20 things before I can even proper login.