How password enforcement affects 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 will 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, any 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

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 know, “Oh, it looks like 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 unacceptable message serves a similar function: it tells the user that they must try a different passwords 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 article Modify the "Password is not acceptable" error message explains how you can change the wording of that message.