How Does Password History Affect the User Experience?

To begin with, keep in mind that nothing changes for end users if you don’t enable password history: in that case, the Identity Cloud continues to use the password policies currently in place, and users continue to see the same error messages they’ve always seen any time they violate one of those password policies. For example, if user tries to a user a password that consists of a single character, that password will (by default) fail with the following error:

If you enable password history,you’ve also enabled a new way that users can violate your password policies: by attempting to reuse a previous password. For example, with password history enabled Hosted Login users still reset their passwords in the usual manner. However, if they try to reuse a password they’ll see a message similar to this:

Similarly, users logging on by using the JavaScript SDK will see a password_unacceptable message if they attempt to reuse a password.

And what happens if your organization employs an API-only implementation of the Identity Cloud (that is, what happens if you don’t use either Hosted Login or the JavaScript SDK, but create your own screens)? In that case, an entity.update API call that tries to reuse a password will fail with the following error:

    "error": "password_unacceptable",
    "request_id": "8cpwu3hcqsqt5mek",
    "error_description": "password is unacceptable",
    "stat": "error",
    "code": 352

If you're using the Authentication APIs and the /oauth/update_profile_native endpoint you'll get a similar error. In that case, however, the error code will be 214.

In your password reset code, you’ll need to trap for the password_unacceptable error and then display the appropriate message.

And speaking of appropriate messages, you might be thinking that the default error messages – This password is not acceptable. Select a different password. – is a little vague. To be honest, it is a little vague, and that’s by design: as a general rule, the Identity Cloud limits the amount of information given out when working with passwords. That's why you see errors similar to this one:

If a more specific error message was displayed, a message such as Incorrect username, a hacker would think, “OK, I got the password right; now I just need to get the username right.” This way a hacker doesn’t know whether it’s the username or the password (or both) that are wrong. The This password is not acceptable message serves a similar function: it tells the user that they must try a different password but, at the same time, doesn't provide any clues as to the password policies currently in use.

From a security standpoint, that's a recommended procedure. On the other hand, we realize that some organizations won't like the default error message: they'd prefer to tell the user why the chosen password in unacceptable. What are you supposed to do if you don’t  like the default error message that pops up when a user tries to reuse a password? The next section in this documentation explains how you can change the wording of that message.

As noted elsewhere, password history takes place immediately after its been enabled. 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. That's just something worth keeping in mind.