41

What additional security can a "password minimum age" provide?

For example: the user can change their password only after 24 hours have elapsed since the last password change.

R15
  • 2,943
  • 1
  • 12
  • 21
whoisthesomeone
  • 521
  • 1
  • 4
  • 3

4 Answers4

49

It is normally used in conjunction with a setting to prevent re-use of X number of previous passwords - the minimum password age is intended to discourage users from cycling through their previous passwords to get back to a preferred one.

Obviously the effectiveness is dependent on both the minimum password age setting and the users.

R15
  • 2,943
  • 1
  • 12
  • 21
  • 53
    So it's basically a bad patch to a bad feature? – o0'. Jan 09 '15 at 15:54
  • @Lohoris: Well the alternative - storing the list of previously used passwords and check whether the [edit distance](https://en.wikipedia.org/wiki/Edit_distance) is large enough isn't safe either since a server is not supposed to store the password. – Willem Van Onsem Jan 10 '15 at 15:37
  • 3
    @CommuSoft the Server may also store the previous passwords hashed, each one with it's own salt. – Tokk Jan 10 '15 at 16:17
  • 1
    @Tokk You can't check edit distance if all you have are the hashes of the old passwords. – Damian Yerrick Jan 10 '15 at 17:49
  • 2
    @tepples You sure can check the edit distance _from_ your current password by comparing its modifaction's hashes with the stored ones – Tobias Kienzler Jan 10 '15 at 18:19
  • @TobiasKienzler The system doesn't have the prior passwords against which to compare the user's current password. All it has are the hashes, whose edit distances are near n/2 bits from the hash of the current password. If the user is required to put in the current password and new password to change the password, the system can calculate _their_ edit distance, but not edit distance to old passwords. Only exact matches to old passwords are possible. – Damian Yerrick Jan 10 '15 at 18:44
  • 1
    @tepples You can compute all mutations of the new password within the unacceptable edit distance, calculate _their_ hashes and compare them to old password hashes (with the respective salts). – Tobias Kienzler Jan 10 '15 at 20:12
  • @tepples: the quality of a good hash function lies in the fact that if two strings differ slightly, the hash function differs enourmuously. That's for instance why modern hash functions like *Keccak* use a [*sponge*-function](http://en.wikipedia.org/wiki/Sponge_function). So if the edit distance between two hashes is small/large, this shouldn't imply the real distance is large/small (note swap). – Willem Van Onsem Jan 10 '15 at 22:28
  • 2
    @TobiasKienzler "compute all mutations"? I'd appreciate your feedback on [this question](http://security.stackexchange.com/q/78898/36212) if you get a chance. – Damian Yerrick Jan 11 '15 at 00:54
  • 1
    @CommuSoft the alternative is not requiring the users to change password in the first place, since it actually decreases security. – o0'. Jan 11 '15 at 16:14
  • 1
    @Lohoris: 2nd that, some people I know eventually set passwords to `pass1`, `pass2`, `pass3` with `pass` the original password anyway. – Willem Van Onsem Jan 12 '15 at 11:04
23

Here is a more formal explanation from Microsoft:

Vulnerability

Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach. To address password reuse, you must use a combination of security settings. Using this policy setting with the Enforce password history policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but you do not configure the Minimum password age policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. You must configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.

Countermeasure

Configure the Minimum password age policy setting to a value of at least 2 days. Users should know about this limitation and contact the Help Desk if they need to change their password during that two-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend.

Potential impact

If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user cannot change the password until the next day.

Source.

Cristian Dobre
  • 9,837
  • 1
  • 31
  • 51
  • I guess this is the most correct answer - not sure, but this is in fact a MS invention, isn't it? And usefulness of this kind of policy is not without opponents, see e.g. https://www.schneier.com/blog/archives/2010/11/changing_passwo.html – Zane Jan 10 '15 at 20:00
  • @Zane, if this is Microsoft's invention, then why don't they use it themselves? Less than a year ago I changed my Hotmail password 7 times to get to my original one. – Arturo Torres Sánchez Jan 11 '15 at 01:54
  • 1
    @ArturoTorresSánchez Microsoft is a huge company with a lot of different products. Small wonder they aren't all consistent with each other. – Chris Hayes Jan 11 '15 at 08:19
  • This would **only** work if passwords are unsalted, or if salt is the same for an user. MS still uses fast unsalted hashes which are unsecure for **decades** – Smit Johnth Jan 12 '15 at 03:29
  • The new recommendation is one day. https://technet.microsoft.com/en-us/library/hh994570(v=ws.11).aspx – Zlatty Jun 03 '16 at 19:21
2

It could also be used that way that you change your password every day and minimum password age is 1 day. That way, if someone hacks your account or gets your password etc. he/she can't change your password, meaning you still have access to your account. Downside is that, you can't change your password either for next 24 h so they have still access to your account, too.

Edit: this isn't official reason, but possible and good use.

user66067
  • 21
  • 1
  • 3
    Disagree. Hacker can't change your password _if and only if_ you have changed it in the last 24hrs, making this unlikely a reason. – Question Overflow Jan 11 '15 at 08:31
  • 1
    Also, a hacker will try this more often than you will so he will probably be first and you will not be able to change your password for one day. – Silver Jul 31 '18 at 14:12
1

There are at least two things going on and this is the sort of AD security function that only makes sense if you properly use the AD function to lockout after "n" failed attempts, and also require your system to remember "n x 2" previous passwords -- with "n x 2" being pulled completely out of the air to be sufficiently larger than "n" so that an attacker who has a rough idea of your victim's password is will lock themselves out before exploring your less-security-conscious co-workers' password space. Ultimately these policies only really become powerful when your users are alert, and you don't unlock their account automatically within "n" minutes of locking out in plain sight. If your users assume that being locked out is a red-alert dead give away and they require administrative intervention to restore access, you have a much more secure environment than if your user simply says "huh, I'm locked out" and gets in 10 minutes later, or "huh, I forgot my password" and has the IT guy who maybe changed their password yesterday to perform nefarious deeds reset their password for them.

This is funny because a new guy asked me about this last week:

1) It is intended to prevent a user from cycling through "n" unique passwords so that they can cycle back to their "preferred password," like "Password1."

So if the system remembers your last 10 (n=10) passwords (through hashes, not clear text, any system that inspects your "edit distance" is compromising security by storing clear text or mincing up the password into multiple hashes) then the end user will need to waste at least "n x minimum password age" days changing their password until they arrive at their original, discouraging the practice. Despite the fact that people like to say "changing passwords decreases security," this is only correct if your users are essentially leaving their new passwords out. If your users are routinely flipping from "Password1" to "Password2" and so forth, you are still more secure if an attacker has to guess their way through this series of passwords. All bets are off with a brute-force password file attack, but all bets are pretty much always off in that scenario with NT hashes.

2) If you walk into your place of business and are an adult with a consciousness of security and an expectation to behave with security in the forefront of your brain, you should consider an inability to log into your workstation a security incident. This feature gives you slightly more information that you might otherwise have, if you're the type of person that cruises from "Password2" to "Password3" until you reach the end.

So if you're locked out of your account and have no idea why, red alert! Somebody is trying something, or you locked yourself out, or there's an automated process trying to use your credentials.

Even if you're the one who enters the wrong password 20 times, did you really forget it, or did someone else change it on you?

Let's say that you finally get in without administrative intervention, and decide that even though you're 99% sure your password was "Password2" yesterday, suddenly it's "Password3." Because a naughty SA changed your password temporarily in order to perform some auditable events under your account, and then tried to change your password back, but they were off by one. This is highly unlikely, why wouldn't the SA just guess your password? Maybe they are trying to avoid triggering any login failure events and simply used their normal admin tools to change it, and then change it "back."

Instead of simply saying "huh, that's weird," you have the ability to TRY to change your password and to determine if someone other than you changed it the day before, in order to perform "nefarious deeds" under your account. You will be told that you can't change your password, because it was changed recently.

This is not an "official reason" either, #1 is -- but it is empowering for the end user to be able to know with some certainty whether someone else is compromising your password. In my experience, people tend to use the same passwords in secure and non-secure environments, and black hat or disgruntled administrators can figure out your favorite password "trends" more easily than you might expect.

Too often people think they "forget their password" and just assume that it was magically forgotten from one day to the next. More often than not, that is the case. But if you're in a truly secure environment, think twice!

And yes, I realize that this security-conscious end user shouldn't be cycling through passwords like this, because it's only a matter of time before someone is able to explore your lockout window and password-change-frequency window (30-90 days, etc) to figure you out, but users too often operate under the assumption that admins know their password and can do whatever they want. If you don't assume this, and instead know that they have to go out of their way to figure out what your password might be, just that information is game-changer to have.

user42600
  • 11
  • 2
  • It seems like your use case would be better handled by just having the ability to see the date of the most recent password change. – Ken Williams Dec 07 '16 at 16:11