How to prove that authentication system works, and that the customer is using the wrong password?

Question

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.

Answer 1

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)

Answer 2

There's one way to know for sure, and that is calculating the hash of what the user entered, using the same salt, and comparing that with what you have. However, that's what the login process already does and the user doesn't believe that. Why should they believe it when you do it for them?

---

Instead, you could do what I've been seeing a lot lately, in Windows 10 for example, but also on websites:

Give the user a way to verify what they've entered.

Of course, when logging in, the characters should be represented as dots or other characters, so snoopers can't see the password by looking over the user's shoulder.

But as long as it's in the input field, it hasn't been encrypted or hashed in any way yet. So provide a button that turns those dots into the actual characters.
That way, after entering the wrong password, they can enter it again and see what they've just entered. Or they can check prior to logging in.

Forgotten CapsLocks, hanging Shifts, typos; they can all be detected by the user this way.

Answer 3

To improve your user experience you need first of all add some UI to tell users of the following conditions:

• Caps lock activated
• Warning if there are trailing whitespaces in username
• Warning if there re trailing whitespaces in password
• prevent using whitespaces in email (if using email instead of username)
• prevent using and automatically remove newlines (there are several new line variants)
• prevent using and automatically remove control characters
• if you are using Javascript, some browsers have it disabled, so you have to move these steps on server side.

Also when password inserted is wrong display the following message:

Password or username/mail is wrong, please type it paying attention to lower-case or uppercase letters and all symbols numbers, they must match perfectly. Avoid doing copy-paste because sometimes copying text may add additional unwanted whitespaces and/or newlines.

Keep in mind that your users may be right! I once had a old phone that didn't allowed me to login into a web page, I don't know if that was a text encoding issue but my password was alpha numeric and worked perfectly on a PC.

Answer 4

The accepted answer really covers most of it. But assuming that I tried all the suggestions there and still couldn't find the problem, I'd then try to catch the error when it happens. To do that, you could add code that logged the received plaintext password if a user failed to log in twice in a row (so as to filter out all the users who just made a stupid error and corrected it on the second try).

In order to not weaken the security of your system, you could only enable the password logging when there actually was a user on the phone who had trouble logging in, and log only his/her password, with his/her consent.

Logging the actual password your application sees has the advantage that you see exactly what your application sees. After a few calls from desperate users, you might start to pick up a pattern in their passwords (e.g. trailing space, special characters etc) which pointed to a problem in your login code, or you might see that they meant to type "mysweetheart" but typed "myseetheart" instead, which would mean that the login problems were most likely all user error.

Answer 5

I don't think manually performing the password hashing steps would be the solution. Should you have detected that it indeed fails, sure, you may do that at low-level to debug, but your customers will forget about it almost immediately.

Here the problem is that they are using a wrong password, either because they mistyped it, or really think they had used a different one than the one they did.

To rule out the first case, make them write the intended password in a text editor (eg. notepad), cut it to the clipboard and paste into the password field. The password is showed to the customer during the process, so that removes the cases where a wrong letter is being pressed, Caps Lock was set… (of course we are expecting that they do this at a time when nobody else is looking at their screen)

The second case is harder, as we do not want to encourage the customers to keep a text file with their passwords. Ideally, you would convince your customers to use a password manager like KeePass. Then, if the password -the same that worked before- is correctly copied from the password manager, you can be quite certain that it is indeed the right password.

Other than that, which really requires a change of mind of your customers, you may ask your customers to:

• create a new password
• change their password to that by pasting it
• try logging in with the same password they have in the clipboard

as many times as they want, in order to attempt to reproduce it.

Answer 6

Assuming you are logging whenever a user logs in, you may be able to show that they have been able to log in since they last changed their password, That would at least be sufficient to rule out some potential issues.

Answer 7

On encountering four different authentication systems with this actual property, it's fairly easy to verify in each case.

Case #1: System randomly fails. On failure, the incorrect login counter is not incremented. (I haven't been able to inspect the insides but I'm pretty sure what's happening is it sometimes loses connection with another server and just reports incorrect password when this happens.)

Case #2: System blew up when I put an apostrophe in my password. Demonstrating the password field was subject to SQL injection was trivial.

Case #3: Valid password was rejected by a character filter on the login screen the password screen didn't have. This was trivial to demonstrate the problem as well.

Case #4: System would not let me log in becasue it interpreted at-sign as kill line. Booo. Logging in by telnetting to the FTP port proved I had the right password.

Answer 8

You could store each users last few (hashed) passwords in your database. If the entered password does not match the current password, compare it to the old one(s). If there is a match there, present a "You have entered an old password - try again" message, or error code to that effect (so when they contact you, you can ask "Do you see Error Code 47? That means you have used an old password.")

This way, you can be fairly sure the login system is working as it has made at least some password lookups and the user gets some feedback that they have forgotten their new password.

Answer 9

I'm posting a second answer which I thought of yesterday, but wasn't sure it was advisable.

You could create a temporary log of passwords set/reset and attempted in an encrypted form. Security experts (including me) would shudder at this idea of encrypting (instead of hashing) passwords (or even incorrect password attempts), so I would suggest three precautions if you decide you need to start logging this information.

1. Submit the information to a separate/isolated computer so if the main server is compromised then the passwords log is still safe.
2. Use public key (asymmetric) encryption for the logged information. The private (decryption) key is only stored in an isolated environment for the developer to review the logged data.
3. Schedule a task (or code it in) so that this temporary log is disabled at a particular date, or when a sufficient number of tests have been successful.