Occasionally (though rarely), some of our users say that their password doesn't work: they say that they have typed the correct password but got the 'wrong password' message.

We tell them to use the reset password feature, which they do, but they stay with that feeling that the authentication system sometimes doesn't work.

Our guess is that their password is not what they remember, but since we don't store it in plain text, do we have any way to prove that's the case?

On some occasions we were able to show them that on a certain date they had changed their password and then forgot about it, and they were satisfied. But that's not always the case.

There's not a really quick way to prove this because the hash is designed not to be reversible.

You could take their claimed password, and manually generate the hash as @TechTreeDev suggested. You should be using a salted hash (i.e. BCrypt) so make sure you use the same salt.


If the manually generated hash matches, then you've proved an issue in the login code.
More likely the generated hash will be different, then you've ruled out login code issues, but there still could be an issue with the password setup, or a mistake in your manual generation.


That's pretty much the extent of what you can do to check a single person's password. Beyond that we get into system testing.


If you suspect an intermittent/random chance edge case, you could create a monkey test script to set up passwords and then try them. This approach is probably overkill though.
The best thing is to review your login code and all points that reset the password. The code should be as short and concise as possible. In my experience, the best way to rule out edge case issues is with code review, as such edge cases are often not covered by manual testing.


A few things to specifically look for:


Make sure that maxlength setting is consistent (or better yet, not present) on any password <input>s. You are looking for consistency between password set up and the login form.
Make sure there is no server-side truncation.
Make sure that encoding is consistent. If a non-ASCII character is used in the password, the password setup form and login forms need to behave exactly the same.
Also don't automatically strip anything like whitespace or non-ASCII characters from the password. This is the kind of thing you can easily catch with a code review if your code is concise.


Finally some human tips:


Verify they are using the correct username first.
Check the caps lock setting is correct.
Give the customer support folks a log of every date/time of login or of password reset. If there has been at least one login since the last reset then they know the system worked correctly.

As long as the login code is unchanged, and the hash is unchanged since last success, then you can be reasonably certain that the issue must be a mis-typed password.
Review the UX of the Wrong Password error, providing the user with some simple tips and authoritative explanation of possibilities. This may reduce call-ins to customer service.
It may be helpful to email notify the customer when a password is reset to remind them. (or other family member in case of shared accounts)

