Preventing information leakage while returning an error message

Question

Say my website contains 2 functions:

1. Allow a user to change their own password
2. Allow an administrator to change a user's password (the user must change again before they login)

Now let's say that there is a business requirement which stipulates that a user is not allowed to reuse a previous password.

In 1, it is ok to return a "You cannot reuse a previous password" message, providing the user has successfully authenticated themselves with their current password.

In 2, I need to prevent information leakage. The administrator should not be given information on a user's previous password. I have implemented this by returning a generic "Invalid password" message. However I think a smart user can still figure out that if an "Invalid password" message is being returned for a perfectly valid string, then something else is going on.

Is there any way around this or am I just being too fastidious? My first thought is that the solution is to remove 2, and add a Reset Password feature.

EDIT - I think there is a bit of misunderstanding of the problem. The problem is that the user may have used one of their previous passwords on another site (eg: Bank). Thinking a bit more about this, I'm not sure how much more problematic the "changing another users password" leakage source is than someone simply trying to brute-forcing the main login form...

Answer 1

Why does the administrator need to know the new password?

2) is actually only a problem if the administrator provides a new password, but not if the temporary password is randomly assigned and communicated to the user by a medium which the administrator can not eavesdrop.

Don't let the administrator select the password, and he can no longer get any information on either the new or any previous password.

Answer 2

Why you don't make an exception for 2? I mean, if the administrator sets a new password, it doesn't do the verification process of the old passwords. Just sets the new password and flags it so it needs to be changed at next logon.

That way you can be sure the administrator has no access to the historical password file.

There is a small risk for the repeated password since it's going to be changed next time the user logs in; but any administrator will figure out what's going on if he tries to use "temp-password" twice as a password for a user that forgets his password frequently.

Answer 3

a business requirement [...] stipulates that a user is not allowed to reuse a previous password.

The user cannot reuse her own previous password, but it doesn't prevent a user to reuse a password of somebody else, isn't it? I mean, if Jack and Mary are changing their passwords and Jack types the previous password of Mary, it shouldn't return a error, should it?

This also means that an administrator who hijacks an account of a user may reuse the user's password as well. Why not? It's not the same user (unless an administrator can hijack her own account), so the same rule apply here as well.

If you do alert the administrator that the hijacking password is actually the real account password, then you're indeed leaking personal information of a user to another one. The worst part is that the unscrupulous administrator who receives the error has a hint that he could simply login as a user, without continuing the hijack procedure.