Facebook stores old password hashes (along with the old salt), such that if you try to log in with a previous password, Facebook tells you that you updated the password (and when). Nice user experience. Except this site isn't ux.stackexchange.com.

So, what security threats are presented by this?

See also about Facebook storing old passwords here and here.

  • Wait, what? Are you saying you can log into Facebook with an old password, after you changed it? I don't think that's correct, but if it is, that sounds like a really bad idea. From your linked questions I know they save old hashes so they can tell you when your newly changed password is too similar to an old one, but I don't see anything there indicating you can actually use the old one to log in!
    – Ben
    Sep 23 '16 at 12:35
  • 5
    @Ben, I don't think OP is suggesting that you would be logged in with one, only that if you try to you are informed that you have changed your password but not logged in.
    – Anders
    Sep 23 '16 at 12:37
  • Ooooh that makes more sense. That sounds like a cool feature!
    – Ben
    Sep 23 '16 at 12:57
  • Facebook also uses this information to prevent you from reusing old passwords, and also to prevent you from using passwords too similar to your old passwords. Sep 23 '16 at 19:16
  • 3
    @DarrenH, wrong. The plaintext is available while changing the password. It would be trivial to apply some common transformations to the new password (incrementing/decrementing numbers, reversing case, reversing the password, applying 1337 substitutions, etc.) and hash the result. If the result matches a stored hash, the password is "similar" to an old password.
    – Ben
    Sep 23 '16 at 23:01

The other answers look pretty reasonable, but I wanted to add a few possibilities.

If an attacker recovers one or more of your passwords from other breaches, it seems like plugging them into Facebook's UI could leak at least a few types of information:

  • Whether you used the password on multiple services or not.
  • With known disclosure dates for the breach, they could also gain a data point on how long it took you to update the password.

If pattern-matching on recovered passwords suggests a likely iterator or mutation pattern in your password, it also seems like an attacker could also try one or two passwords they haven't seen in order to support or refute a thesis about how your passwords evolve over time.

I would guess any attacker is somewhat limited in how many such tests they could attempt without someone noticing, but it seems like information along these lines could inform heuristics for how known users change their passwords, improve statistics on how common different update patterns are, and help hone priority lists of users/accounts that are most vulnerable.

These seem like fairly small risks at the individual level, but it also seems like (Martin Bos' post on cracking hashes in the LinkedIn breach is instructive) small heuristic improvements turn into pretty nice levers for recovering more passwords in a large scale breach while simultaneously improving the heuristic/lever.

  • 1
    It is great to see detailed answers on edge case attacks that don't normally come to mind. Sep 23 '16 at 16:52
  • "into Facebook's UI could leak at least a few types of information" > Wouldn't it just mean that you're trying to authenticate with a set of credentials that no longer works?
    – ndrix
    Sep 23 '16 at 20:23
  • 3
    @m1ke Per OP, Facebook confirms the password was once good, and when it stopped being good. If you got the credentials from a breach of a different service, you know they used that password in more than one place. If the breach went public at a known time, you have a little information about how often they change passwords (either by coincidence, or in response to news of breaches). This info isn't exactly a decoder ring, and it's a far cry from uncovering a heavily-recycled password that still works, but it's also far better than asking your Magic 8-Ball which accounts to single out.
    – abathur
    Sep 23 '16 at 23:38
  • 1
    +1 to @Wildcard if I could for adding the link!
    – dave
    Sep 25 '16 at 8:09

This is also done by systems that block you from re-using passwords. If, for example, in Windows you require monthly password changes and require that no password be re-used from the past year, the password file will contain your current password hash + the 11 previous ones.

It is a security risk if the password hashes fall into the wrong hands and are cracked, if anyone used their previous password on any other sites. A user may reasonably expect that a password is gone from the database after (s)he has changed it.

  • Are you sure? In the case of stopping duplicates, it makes more sense to store the hash of the hash, does it not?
    – Stoud
    Sep 23 '16 at 11:44
  • 19
    What? How does hashing the hash help anything at all?
    – Ben
    Sep 23 '16 at 12:36
  • 2
    @Stoud Presumably the password is stored with with a PBKDF, so if you hashed the hash, that would at best just be equivalent to a small increase in the difficulty factor of the KDF.
    – Paul
    Sep 23 '16 at 13:27
  • 3
    Also, if a user has a method to how they create passwords (not unlikely if they have to change it monthly and cannot repeat an old one) then cracking the passwords would give insight to what the current password is. Sep 23 '16 at 15:50

TL;DR The security risk is only increased in the event of a database breach where the older passwords are stored on a Weaker Work Factor

One more thing, is straight theft of a password via a virus on the victim's computer. It could be helpful to know for sure that the password was once valid, and then to try some variations on this, but this would only have limited effect as this attack is probably going to then require Online Brute Force which will probably fail.

A site of this importance should already be using a Secure Password Hash such as BCrypt already w/ appropriate Salt & Pepper.

In this case, if the hashes are compromised, then the attacker would next have to Brute Force a multitude of possible passwords, so that the original password could be determined. This may take a long time if the password has a decent level of entropy. However, some users are lazy, and will use simple passwords. Those will be cracked first.

There are two types of brute force to consider.

  1. Online Brute Force, which typically will not get you very far. The site's public servers should only allow you to try a limited number of passwords in a given time period before Captcha is presented, severely limiting the number of possible passwords that can be attempted.

    There should be additional layers of security as well. For example, if enough Captcha-authorized attempts continue to fail, then they should lock down the account or block that IP.

    So there's probably no additional security risk to this type of attack.

  2. Offline Brute Force is when the database is comprimised and the hashes are stolen. In this case, not only do the latest hashes leak, but the older ones as well, because, as you say, those were not erased.

    In this case, there is also no additional security risk because cracking the older hashes will serve no purpose.

    An exception to this is if the Work Factor was adjusted. The older passwords may be stored on a weaker Work Factor, in which case the attacker would crack the older one first, and use that as a potential hint to crack the latest password.

    Once an offline hash is brute-forced, that password would be used by an attacker to gain access to either the main site's account, or try other sites (i.e. Email or Online Banking) where the user may have re-used that same password. (so don't re-use passwords)

  • One risk is when all passwords of the same user use the same salt. In that case, the attacker could brute force all past passwords at once, and if he hits one of the previous passwords, he has a hint for the new ones Sep 23 '16 at 15:55
  • "all passwords of the same user use the same salt" That would be a very poor practice, and against the default configuration of BCrypt. Sep 23 '16 at 16:50
  • 1
    Good point, if the work factor is increased in later version then my old password is easier to crack than my new one. How much information that yields depends on my password practices.
    – dave
    Sep 24 '16 at 6:56

The increased risk regarding the service in question is at most comparable to

  • allowing users to keep their passwords unchanged for an extended period of time (corresponding to the age of the oldest stored hash)
  • assuming that the number of attacks is higher by a factor corresponding to the number of stored hashes.

Regarding other services, the risk is only increased if one of the old passwords is still valid for another service, which you should not do anyway.

However, if said service makes the old passwords valid for some use (e.g., allows an old password as authentication in a lost-password process) the risk grows dramatically.
