Doesn't persisting previous passwords pose a vulnerability?

Question

Recently I attempted to log in to Facebook, but I'd forgotten that I'd changed my password. Facebook bounced me back to the login screen and advised me that I'd attempted to enter an old password.

Covered thousands of times, if not more, in various articles/threads are reasons justifying the need for password expiration. It's, basically, best not to keep using the same password forever. So I'd have assumed that this translates to it being best that the same passwords aren't held in a DB forever.

Question:

With old passwords still in the DB, then has the system (e.g. Facebook) not disregarded, what is thought as, a safe security measure?

Answer 1

I can see a couple of potential issues with a solution like this:

• If a users (old) password is compromised, then an attempt to log in with it can be used to confirm that the user exists, and has an account - probably not a big deal in the context of FB, where most accounts are searchable anyway, but I still think the principle holds in general.
• If someone suspects that they have your password, this can be used to at least confirm that the user has a specific password previously. For the average users, chances are good that that same password will be used for any number of other services too then.

Those two hold even if a user has a good password (ie. a long string of hard-to-guess characters). Since the average FB user is likely to use the name of his or her cat/dog/child/hamster/boyfriend/girlfriend/whatever instead, then being able to confirm the previous use of a certain password can provide insight that may help someone guess a new password too.

As a concrete example, I know of someone who for a long time used the following scheme based on the names of their children (names changed, obviously):

• First child: Mark
• Second child: Emma
• Third child: Carl

Based on those, the user would switch between passwords like this:

• MarkEmmaCarl
• MaEmCa
• MarEmmCar
• ...and so on.

Sure, guessing a next password based on some quasi-random scheme like this may still require a significant amount of work, but a lot of it can be automated, and it will in any case be far easier than for a random string. If you can establish a pattern by confirming the existence of one or two previous passwords like this however, then you have a pretty strong incentive to keep trying...

Answer 2

The reasons for password rotation (in situations other than expected compromise) are pretty thin these days. The old arguments of "to prevent an attacker from having access forever" and "to make it so an attacker can't brute-force your password before you change it" are a serious case of "at that point, it's already game over" and either mean the service in question has serious problems with its brute-forcing protection or that somebody spent a really weird amount of resources trying to break your password hash, respectively (if the password hash is weak - that is, fast - then it's back to the "already game over" case), respectively.

You can't actually sign in with the old password. Furthermore, it's not like they're saved in plain text or anything like that. As such, there's no real harm to storing the old passwords, and it can be a user-friendly measure. The only reason storing the old passwords would be bad is if you had reused that password somewhere else, which of course you should never, ever do.

Answer 3

Two things.

1. Firstly, you are comparing apples and oranges. Password expiration and storing old passwords are related but are not the same thing. Why shouldn't a site store old passwords? What are the risks involved? If an attacker steals them, she has useless data, that can maybe be used to guess new passwords for users after the hashes of the old ones have been cracked. Seems like a lot of effort for an attacker, if the hash dump doesn't coincidentally include a password of a high priority target. An old password dump is as interesting as yesterday's paper. Which means, absolutely boring, it's paper!

2. Secondly, it is true, that it has been covered a thousand of times that users should keep changing passwords. You know what else is true, though? The opposite has also been covered a thousand times.

Most famously this was - after a lot of experts have preached it for years - brought to attention by the renewed publication of NIST Special Publication 800-63b, where it says:

“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

Furthermore NIST says:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

(emphasis mine)

So if Facebook has the rule to not reuse passwords, then it is absolutely fine, to check if the hash of the new password is the same as the old one.