An Introduction to Unique Password Enforcement and Password History

Many organizations are firm proponents of password history (also known as unique password enforcement). With password history, the last X number of passwords a user has employed are stored as part of their user account. Why? Well, suppose Maria Fuentes uses p@ssw0rd as her password. Let’s further suppose that Maria needs to (or wants to) change her password. Without password history, there’s nothing to prevent her from simply reusing that same password: p@ssw0rd. With password history, however, Maria can’t do that: instead, the system will flag the fact that she’s already used p@ssw0rd (or, in this example, currently using p@ssw0rdand make her select a new, never-before-used password. 

Why do  organizations do this? Typically, it’s because limiting password reuse adds another layer of security to a website. or app For example, suppose you suffer a security breach and a hacker steals all your passwords. You inform your users and ask them all to change their passwords the next time they log on. Your users dutifully follow your instructions, but all of them simply reuse their old passwords, the same passwords that were just stolen. Password history helps prevent situations like this.

Note. Just be sure that you don't get a false sense of security when it comes to, well, security: password history adds additional security to a website or app, but, by itself, it doesn't make a website or an app impregnable. Password history should be considered  another tool in your security arsenal, not the only tool in your security arsenal.

If password history is important to you, Akamai offers a way to add this feature to your Identity Cloud app or website. By making one simple API call you can configure the Identity Cloud to remember as many as the last 10 passwords employed by a user, and to prevent that user from reusing any of those passwords. In the case of a security breach, this helps ensure that your users don't simply reuse passwords that might have leaked or been stolen.

And what if you don’t want to use password history? That’s fine: although the password history capability has been added to all of your Identity Cloud entity types, the feature isn’t automatically enabled on any of those entity types. If you don’t want to use password history then just leave everything exactly as it is. And what if you enable password history and then think the better of it? No problem: you can disable password history just as easily as you can enable it

Important. Password history requires that your passwords be stored using bcrypt password hashing. If you enable password history then your passwords will automatically be converted to bcrypt, For organizations already using bcrypt that won't be a problem. However, if your organization doesn't use bcrypt that won't necessarily be true: problems could potentially arise if your passwords are automatically converted from, say, SHA256 to bcrypt. See your Identity Cloud representative for more information.

If you decide not to use password history your Identity Cloud  passwords and password resets continue to work the same  they’ve always worked; among other things, that means that a user can use the same password as many times as they want. For example, suppose Maria Fuentes uses p@ssw0rd as her password. If she resets her password she can employ p@ssw0rd as her “new” password: nothing prevents her from doing that. You say you don’t like the idea of users using the same password over and over? Then enable password history. That's why it's there.

Incidentally, if password history is enabled, the feature is invoked any time a user tries to change their password; this includes both a user resetting their password from their user profile and a user who has forgotten their password and needs to create a new password before they can log on. Elsewhere in this documentation we’ll explain the password history process in a little more detail. For now, however, just think of password history as being a list of the previous X number of passwords that the user has employed:

  • p@ssw0rd
  • myPa33word!
  • p@ssw0rd_13
  • PASSwordABC$

Suppose our hypothetical user needs to change their password, and chooses p@ssw0rd_13 as the new password. When they submit this change the Identity Cloud checks the password history and finds p@ssw0rd_13. As a result, the password change operation fails with the error This password is not acceptable. Select a different password. This same error will occur again (and again) until the user comes up with a valid password that isn’t listed in their password history.

Keep in mind as well that, after it's been enabled, password history takes place immediately. For example, suppose password history is disabled and a user logs on and changes their password to p@ssw0rd. Shortly after that password history is enabled. If the user tries to change their password and uses their current password (p@ssw0rd) that attempt will be rejected: even though the user might have only had that password for a few minutes, they won't be able to resuse it. That will also be true of any other passwords that might be stored in the user's user profile. 

Note. We should add that password history respects any other restrictions (e.g., minimum number of characters) that you’ve placed on passwords. For example, suppose your passwords must contain at least 8 characters, and someone tries to use the password x. That password will be rejected because it doesn’t meet the minimum number of characters requirement, even though x is a password that the user has never employed.