Change password error history message count is wrong

[Stanley Quan]

During change_password api call, the error message "passwords that must be unique is " "%(unique_count)s." shows a number that is greater than the actual history that is kept. The unique_count comes from unique_last_password_count from keystone.conf

According to keystone.conf unique_last_password_count feature starts with a value greater than 1. This means the password history feature starts with unique_last_password_count = 2.

So the error message should not display the unique_last_password_count as the unique history.

I have observed:
unique_last_password_count = 2 you get exception if try to change password to same password.
unique_last_password_count = 3 you get exception if try to change password to current and one other password.

unique_last_password_count = 4 you get exception if try to change password to current and two other passwords.

Not sure if the english sounds right. The actual error message count is either
(unique_count - 1) or (unique - 2) depending on if you consider the current password as part of the unique count???

class PasswordHistoryValidationError(PasswordValidationError):
    message_format = _("The new password cannot be identical to a "
                       "previous password. The number of previous "
                       "passwords that must be unique is "
                       "%(unique_count)s.")

# This controls the number of previous user password iterations to keep in
# history, in order to enforce that newly created passwords are unique. Setting
# the value to one (the default) disables this feature. Thus, to enable this
# feature, values must be greater than 1. This feature depends on the `sql`
# backend for the `[identity] driver`. (integer value)
# Minimum value: 1
#unique_last_password_count = 1

[Gage Hugo (gagehugo)]

I believe this feature is working as intended. For example, when you set:

unique_last_password_count = 2

you get an exception if you try to change your password to the same password. It's correct because the value "2" is counting both the old password and "new" one you are trying to change it to.

However, you are correct in that this value is greater than the history of "used" passwords being stored, since we are counting the "new" password being changed as part of the total unique passwords. I wonder if the "last" part of "unique_last_password_count" is the confusing bit here, perhaps this config value could be changed to "unique_password_count" instead? The message for the exception is slightly confusing in this regard too, could change "...number of previous passwords..." to "...number of passwords..."

[Lance Bragstad (lbragstad)]

This actually sounds like something we can add a keystone-manage doctor check for.

[wangxiyuan (wangxiyuan)]

Agree with Gage that we'd better to update the config help message.

@Lance, so for keystone-manage doctor, what should be checked or ensured with ``unique_last_password_count``?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/522136

[Lance Bragstad (lbragstad)]

@wangxiyuan, actually, I'm not sure a doctor check here would be possible. I was jumping to the conclusion that there was another configuration option at play in addition to unique_last_password_count, but I don't think there is.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/522136
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=49d75d668cdfd757f9e064b22d0acf1213f4b574
Submitter: Zuul
Branch: master

commit 49d75d668cdfd757f9e064b22d0acf1213f4b574
Author: wangxiyuan <email address hidden>
Date: Wed Nov 22 14:42:47 2017 +0800

    Update the help message for unique_last_password_count

    The help message for unique_last_password_count doesn't tell the
    count logic to users, so that the users may misunderstand it.

    This patch updated the message to make it more clear.

    Change-Id: I8ab1db5c07b199a3a0ef86a79e9895be48c0a1db
    Closes-bug: #1727099

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 13.0.0.0b2 development milestone.