24

When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".

Does that mean that servers store my previous passwords? How is that secure?

Boann
  • 221
  • 1
  • 6
sluge
  • 1,085
  • 1
  • 10
  • 9
  • 3
    This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad. – emory Dec 26 '18 at 22:31
  • 3
    They do not (you hope). They also don't store your *current* password (again, you *hope*). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password. – Jared Smith Dec 27 '18 at 00:43
  • 1
    Possibly related? https://security.stackexchange.com/q/53481/172684 – user2652379 Dec 27 '18 at 07:12
  • 2
    Possible duplicate of [Does Facebook store plain-text passwords?](https://security.stackexchange.com/questions/53481/does-facebook-store-plain-text-passwords) – pushkin Dec 27 '18 at 15:29
  • Typically I think the old and new password are available only while you change your password. Once you changed it, the old password disappeared. Of course if the password policy is "do not reuse last 10 passwords" (I have seen such policies) then passwords or password hash values needs to be stored. – Wernfried Domscheit Feb 02 '22 at 07:36

3 Answers3

29

Hash functions are deterministic; the same input always results in the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site.

As pointed out by Micheal

The salt for the old passwords does not have to be the same as the new one.

In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt with an increase on the storage.

From here, without the server side code, we cannot say more than like this.

kelalaka
  • 5,409
  • 4
  • 24
  • 47
  • 1
    Especially if salt is a user name or user's email. – sluge Dec 26 '18 at 07:44
  • 14
    Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk. – Federico Poloni Dec 26 '18 at 10:04
  • 25
    @FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password. – Jörg W Mittag Dec 26 '18 at 11:13
  • @JörgWMittag Good point, I hadn't thought about that. – Federico Poloni Dec 26 '18 at 11:51
  • @JörgWMittag theoretically, they could do even better. I won't mention too much here, but [locality sensitive hashing](https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing) might allow them to do even better. There is an implementation of an algorithm [here](https://github.com/trendmicro/tlsh), but I have not looked into it enough to see what (if any) security guarantees it gives. – DreamConspiracy Dec 26 '18 at 13:16
  • 1
    This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords. – Serge Ballesta Dec 26 '18 at 14:13
  • 11
    @DreamConspiracy Wiki states that `it aims to maximize the probability of a “collision” for similar items` This is a not a good property for Cryptographic hash functions. – kelalaka Dec 26 '18 at 17:14
  • 1
    @JörgWMittag: In fact, Facebook mentioned that they do something like hashing variations to prevent people from reusing similar passwords, mentioned on another question on this site. – Mooing Duck Dec 26 '18 at 17:17
  • @kelalaka that depends on your definition of a cryptographic hash function. Im sure one could modify the random oracle model a little bit to give a hash function that is provably resistant to first preimage attacks (which are the most important when storing passwords), but allow for locality sensitivity. – DreamConspiracy Dec 26 '18 at 17:18
  • 1
    @DreamConspiracy The problem, in my mind, the local can be carried, Do you remember a word game where in each step you change only one letter to arrive the final word while each step is also meaningful word. – kelalaka Dec 26 '18 at 17:22
  • 1
    @kelalaka this is a general problem with LSH- I imagine various applications of randomness can be used to combat this, but I will try and get back to you with more info once I know more – DreamConspiracy Dec 26 '18 at 17:24
  • 1
    @kelalaka The salt for the old password does not have to be the same as the new one. (In fact, the other properties do not have to be the same either.) The hash just has to be stored with enough data to recreate it, given the password itself. A list of old password hashes and their salts is not uncommon and (assuming no password reuse or generative patterns) should be safe. – Michael Dec 26 '18 at 17:41
  • 1
    @Michael Yes, I wrote it in a way that to minimize the data stored. let me clarify that, Thanks – kelalaka Dec 26 '18 at 17:43
  • @FedericoPoloni (and Jörg): There are several questions on the enforcement of _dissimilar_ passwords. [This one](https://security.stackexchange.com/q/3170/56961) is a good start. – Michael Dec 26 '18 at 18:05
  • 1
    @Jörg W Mittag, a variant on storing variations is to store (the hash of) a canonical form. If you want to prevent only case changes, the canonical form should be lower case. Likewise if you want to prevent 1337 substitutions, you could replace the standard symbols with their corresponding letters.Thus if the password was Hat$hepsut, you store hash(hatshepsut). Apply the same transformation to the proposed new password and you have just one comparison to make. – Josiah Dec 26 '18 at 20:48
  • 3
    Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive. – curiousdannii Dec 27 '18 at 01:08
  • 1
    @curiousdannii correct. my old habit. let me clarify. – kelalaka Dec 27 '18 at 07:48
  • @JörgWMittag Theoretically. Betcha ten bucks they don't. – user253751 Dec 27 '18 at 12:12
4

Most of the time you have to reauthenticate in order to change your password. In this case, the backend could

  • Hash the (old) password you provided and compare it to the stored hash for authentication

  • Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like

    S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2

Stefan Braun
  • 796
  • 5
  • 10
  • 4
    As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text? – sluge Dec 26 '18 at 12:24
  • The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible. – Stefan Braun Dec 26 '18 at 12:35
  • 3
    @StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful. – schroeder Dec 26 '18 at 13:06
  • 3
    Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually _store_ it plaintext. – Damon Dec 26 '18 at 13:18
  • 3
    What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password. – Barmar Dec 26 '18 at 19:09
  • @sluge I'd love to say no one does this (store in clear text).... my first job unfortunately got me disillusioned from this. Not every business does this, but there are definitely some (at least one I worked with) that does it :/ – Patrice Dec 27 '18 at 14:06
2

Possibly yes, unknown in practice, assume that they do.

There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).

The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.

The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).

Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.

As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.

Tom
  • 10,124
  • 18
  • 51