Introduction to unique password enforcement

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, she can’t do that: the system will flag the fact that she’s already used p@ssw0rd and make her select a new, never-before-used password. 

Why do many organizations do this? Typically, it’s because limiting password reuse adds an additional layer of security to a website. or app Imagine, for example, a security breach in which a hacker steals all your passwords. You inform your users and ask them all to change their passwords they log on. Your users dutifully follow your instructions, but all of the, simply reuse their old passwords, the same passwords that were just stolen. Password history helps prevent a potential disaster such as this.

📘

Just 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 app impregnable. Password history should be considered just another tool in your security arsenal.

If password history is important to you, <> now offers a way for you to add this feature to your <> app or website. By making one simple API call you can configure the <> to remember as many as the last 10 passwords employed by a user, and to prevent users from reusing 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 enforcement just as easily as you can enable it. 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, this 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 use p@ssw0rd as her “new” password: nothing prevents her from doing that. You say you don’t like the idea of users being able to reuse 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. In Password enforcement and user accounts we 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 this user needs to change their password, and chooses p@ssw0rd_13 for their 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 unacceptable. Select a different password. This same error occurs again (and again) until the user comes up with a valid password that isn’t listed in their password history.

📘

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 it is a password that the user has never employed.