Hacker News Reader

Comment by wj | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com