One common component of Password Policies, Password Lockout Periods, can cause worse security issues then the problem it is looking to solve

1. Problems with Password Change Lockout Periods in Password Policies
A common feature in many Corporate Password Policies is a “Password Change Lockout Period.”
This type of policy requires that after a user changes their password to wait for a lock out period to
expire before the user can change their password again. This type of policy originated as method
to compensate for a technical limitation for a specific type of user Directory store originally used in
the 1970s that is now outdated and should not still exist in Policies. An unfortunate by-product of
this carry over is that a Password Change Lockout Period actually reduces the strength of the
Password Policies and puts systems at risk to attacks based on Social Engineering exploits.
Password Policy Example
Here is an example of a corporate Password Policy from a previous employer:
Enter new password.
Your new password must comply with the password policy:
 The password must meet the system complexity requirements:
o Not contain all or part of the user's account name
o Contain characters from three of the following four categories:
 English uppercase characters (A through Z)
 English lowercase characters (a through z)
 Numerals (0 through 9)
 Non-alphabetic characters (such as !, $, #, %)
 The password must meet the password length requirements of the system. The minimum
password length: 8.
 The password must meet the password history requirements of the system. The number of
passwords to store: 13.

2.  The password must meet the password maximum age requirements of the system.
Maximum password age: 90.
 The password must meet the password age requirements of the system. Minimum
password age: 1.
The last bullet is the Password Change Lockout Period and is the problem: "The password must
meet the password age requirements of the system. Minimum password age: 1" (1 day in this
case).
I briefly go over the background on why a Password Change Lockout Period was originally needed
and why this type of rule adds complexity to the password management process and does not
increase the security of the processes but instead actually makes a system less secure.
A little Password Policy history (as I remember it):
Directories at one time were the most commonly used (and are still extensively used) user store on
both *NIX and Windows systems. Originally, Directories only stored the current password and the
date the password was last changed. With this data, it was simple to implement a "must change
password every x days" password aging policy.
Crafty users realized that when they were forced to change their password they could simply
change it a second time immediately after the first and go back to their original password,
bypassing the password expiration policy.
Administrators realized that users (and often times the admins themselves) were doing this, and the
Password Policy arms race began.
A new multi-value field for “Password History” was added to the Directory schema along with a
global “Password History Length” value. Users were not allowed to reuse a password until the user
exceeded the number of interim password specified by the value in Password History Length.
Users then fired the next volley by changing passwords enough times in a rapid succession to
exceed the password reuse policy limit and go back to their original password. Admins fired back
by raising the Password History Length to a larger number (such as 50) to make manually cycling
through passwords to get back to the user’s favorite password difficult. Crafty users returned fire by
scripting password changes.
The Admins' solution to this end run around The Password History Length was to limit the number
of user initiated passwords changes to (what was usually) one password change per day. This
way if the password history limitation was set to 5 and the users could only change their password
once a day, the original password couldn't be reused for at least 5 days and that was often enough
of a hassle to dissuade users from changing their passwords on 5 successive days. Admins were
still allowed to change a user's password without restrictions to allow password resets if the user
forgot their new password.
LDAP based Directories, such as OpenLDAP, were often the primary data store for authentication
systems and still work this way today. (http://www.openldap.org/doc/admin24/overlays.html)

3. Although harder to implement and not seen in many Directory implementations, Password Aging
Policies that prevent users from reusing a password until a specified elapsed time period (such as
90 days) have emerged. This feature makes a password change lockout period irrelevant and
solves other inherent issues.
Consider these two rules:
 The password must meet the password history requirements of the system. The number of
passwords to store: 13.
 The password must meet the password maximum age requirements of the system.
Maximum password age: 90.
These two rules ensure that a password is not reused for both at least 90 days and until 13 other
passwords have been used in the interim; the 1 day aging requirement is superfluous in this case.
If the user is allowed to change their password immediately and repeatedly (for any number of
times) a prior password still cannot be reused for 90 days instead of the "work around" of Password
Reuse threshold times the Password Change Lockout Period
The Securityimplications of Password Change Lockout Periods
A frequently voiced concern for Password Change Lockout Periods is there are (allegedly) social
engineering attack exposures with allowing users to repeatedly change passwords. I do not find this
to be a supportable reason for a Password Change Lockout Period. It must be assumed that the
mechanism to change passwords is secure. Changing a password more than once a day (or any
time period) cannot be any more or less insecure than changing a password an unlimited number
of times per time period or the entire process is NOT secure. It is a problem if the user can cycle
back to a previous password, but the elapsed time reuse restriction will eliminate this concern.
I have also heard the argument that "there is no reason that users should need to change a
password more often"; this is a flawed assumption. Consider this scenario: A user changes their
password and suspects the new password was "shoulder-surfed" and wants to change their
password again to maintain their login integrity or maybe the user realize the person they just hung
up with really wasn't from IT and they probably shouldn’t have given the caller their login
credentials. That is a serious issue but a rule requiring 24 hour limits between user initiated
password changes unnecessarily lengthens the time until the password can be reset.
Supporters for a Password Change Lockout Period state that a user password can be changed
more than once a day; the limit is one user initiated password change in a 24 hour period and an
administrator can make an unlimited number of subsequent password changes. This process
leaves an account potentially exposed until an administrator can be contacted and resets the
password. This process also adds expense and delay (which weakens the overall security of the
system) without adding any benefit.
Furthermore, administrators are frequently allowed to set insecure passwords for users and often
use the same password for all clients when they reset passwords. It is even worse when there is
an actual IT policy that all resets use the same weak and documented dictionary password like
"Password1". This was the case for my previous employer that used the policy I used as an
example. If it is widely known that the company uses "Password1", "Welcome1" or any other

4. standard or documented password and the users will not be able to change their password for 24
hours, this could be a serious security issue.
A legitimate requirement is that user initiated password changes must be self-service and not
require admin assistance whenever possible provided security is not legitimately compromised.
Realistically, requiring a user to reach out to an admin to reset a password is expensive; it takes
time away from the user's productivity, it requires a human on staff to process the password change
and the fully loaded cost of the admin (benefits, floor space, computers, call center infrastructure,
etc...).
A social engineering attack exploiting a Password Change Lockout Period and Administrators using
weak passwords would avoid almost all the "red flags" users are trained to recognize as danger
signs of a phishing or social engineering exploit attempt. The attacker could tell the target "don't tell
me your password, that is against IT policy and dangerous; call the helpdesk and have them reset
your password. Remember; don't ever tell anyone your password!" Of course the attacker will
already know what this user's password will be for the next 24 hours and the system is vulnerable.
It would also be easy to iterate over a known list of users trying the well know reset password;
eventually an account with reset password will be discovered.
I can think of only one supporting argument for type of Password Change Lockout Period (but with
a slightly different implementation) for preventing a Denial of Service attack. If a user login is
compromised by an attacker so they can successfully login, the attacker could script successive
password changes with the intent of either crashing the system by degrading the performance of
the Authentication System as the Password History tables become unnaturally large or filling the
allotted drive space of the database from password changes. Allowing a number of changes (more
than 1) in a set time period (e.g. 5 changes in the previous 24 hours) allows for a reasonable
number of legitimate user initiated changes without requiring admin intervention and prevents a
legitimate DoS vector.
In summary, the need for a Password Change Lockout Period should no longer exist and this relic
from the 1980s introduces unnecessary limitations that reduces your overall security. We should all
consider eliminating Password Change Lockout Period from our systems.
https://help.salesforce.com/articleView?id=admin_password.htm&type=0
“Require a minimum 1 day password lifetime”
“When you select this option, a password can’t be changed more than once in a 24-hour period.”