19

Is it advisable to have users re-type their password to confirm it's correct? On User Experience the general consensus seems to be no but I'm wondering if this has security ramifications?

EDIT: my two-cents is wouldn't that lead some users to feel the site is unsafe or unprofessional?

EDIT 2: In fairness the question asked on UX was regarding a password shown in plain text (so less likely a mistake will be made), does this change any answers?

Community
  • 1
Celeritas
  • 10,039
  • 22
  • 77
  • 144
  • 19
    I personally think the UX trend towards a single field is wrong. In the sense that no user will care if you ask them to repeat their password. This is a one-time activity for most users, if they want an account, they'll play along. They're not going to throw a furious tantrum and leave, just because of that. The UX guys are saying these days resetting a password is a trivial matter. No matter how you look at it, resetting your password is a whole lot more pain than just repeating it the once when you create/change it. – Lee Kowalkowski Jan 29 '13 at 21:57
  • Are you talking about the creation of a new password, or as part of the main authentication dialog? Creation: yes; login: irritating annoyance. – Kaz Jan 30 '13 at 04:35
  • 2
    @Kaz, can you imagine at least one valid reason for having to confirm password in login? – Oleg V. Volkov Jan 30 '13 at 11:57
  • Yes I *can* imagine a valid reason. Suppose that the UI has to deal with an authentication module which will disable the account after only, say, three invalid. Getting the user to type the same thing can help reduce the number of mistakes. – Kaz Jan 31 '13 at 01:25
  • What about the scenario of the user copy and pasting the password to avoid having to type it twice? (I do not think it is that uncommon.) – Johan May 11 '13 at 04:58

5 Answers5

36

The real reason to have a user type their password twice is to avoid mis-typing it in. It is very easy, when typing a new password, to get a capital letter incorrect, or accidentally type the letter next to the one you think you are typing.

If this happened the user would not be able to access their account, at which point weaker forms of security, like a password reset, may come into play.

Typing it twice is a quick check that the user is consistent enough to get it the same twice - so they probably have it correct.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • Plus typing the password twice makes it easy to remember it. – Vorac Apr 01 '13 at 14:56
  • 1
    @Vorac: You could make a (weak) claim for *easier*, but it still falls far short of *easy to remember*. With exceptions for savants, but they'll remember it after typing it once. – Ben Voigt Feb 08 '14 at 16:33
15

There's a key point that's being barely touched upon here, and addressed a bit more in the UX thread you linked, which I'd like to highlight.

The password confirmation field, on its own, does not serve any security purpose. However, it does serve as a usability supplement to ease headaches that might otherwise be caused by something that is a security function.

The reason we have users confirm their passwords is because they cannot see their password on-screen when they enter it. The reason we do not allow them to see the password on-screen is to prevent shoulder-surfers, security cameras, shared desktop users, and screen capture tools from seeing the password.

If the password field were to remain unmasked, then it would be reasonable to do without password confirmation. You can already see this in action in some applications (KeePass is one exampe) which allow you to selectively mask/unmask the password field. In those applications, the password confirmation field is only enabled when the password is masked.

The purpose of the password confirmation dialog is as a sanity check for the user. Users cannot be trusted to enter their password error-free 100% of the time, and much less so when they can't visually verify the password prior to submission. However, it is very unlikely that a user is going to "fat-finger" their password the same way twice in a row. This allows a user to be relatively confident that they are setting the password to what they think they are, without having to compromise security by displaying it on the screen.

Of course, it should be understood that this is only necessary at the registration phase. This is because you only have one chance, during setup, to set your password before you are committed to it. When logging in, you get multiple attempts. A one-time error at login is much less costly than it would be (without the confirmation field) at registration.

Iszi
  • 26,997
  • 18
  • 98
  • 163
10

It is best to have users type their password twice, because:

  1. they may have mistyped it, and they would not know it because the password is "hidden" on their display (it is just a bunch of '*');
  2. if the user is serious in his security, then he generated a brand new password which he will have to learn by heart. This kind of memory is in the muscles (actually, in the brain cells which directly manage the muscles). Making the user type his brand new password twice means halving the probability that he will have forgotten it ten minutes from now.

We do not require the users to enter the password three times because it would make them angry.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    Add to #1: *...as it should be.* – Iszi Jan 29 '13 at 19:14
  • 1
    @Iszi: Yes, but don't forget [Polynomial's answer](http://security.stackexchange.com/a/23339/13239) about whether passwords should be masked. Passwords should be masked by default, but the user should have the option to view it. (Apple's compromise on their handheld devices is decent: The last typed character is visible, but all others are masked.) – Jonathan Garber Jan 29 '13 at 21:12
  • What about having one of those `password strength` meters, and the higher the strength the more times they have to repeat it. i.e. if the password strength is up at 80%, they have to type it 8 times. You could even make it exponential. 1 repeat at 10%, 4 times at 20%, 8 at 30%, etc., 256 times at 80%, and 1024 at 100%. This will ensure users remember their passwords, and they will thank you for it later. – Buttle Butkus Jan 30 '13 at 01:04
  • 6
    Sounds like a great way to ensure that all passwords are weak. – Thomas Pornin Jan 30 '13 at 01:15
  • 3
    @JonathanGarber In my opinion, I like what Windows 8 did with their login screen. A button removes the passChar (the '*') and changes the textbox into real-text. This only lasts until you release the button, so you can hold it down as long as you need, or not at all. – Jon Jan 30 '13 at 03:28
8

There's an important point here:

The confirmation box exists specifically because the password box traditionally masks your input. The question isn't do you confirm or not, the question is do you mask the password or not. If you mask the password input, then you must confirm otherwise the user might enter incorrectly and not know. But if you display the password as the user enters it, then he can see for himself whether he entered it correctly.

The advantage of masking the password is that it hides this sensitive information from shoulder-surfing bystanders. The disadvantage is that it makes it more difficult to confirm that you typed the thing correctly.

The general consensus is that it's better to err on the side of safety, and most users indeed expect you to do so. If you give them an unmasked password field, users will generally get the impression that you don't know what you're doing.

tylerl
  • 82,225
  • 25
  • 148
  • 226
1

This has nothing to do with security, it has to do with user experience. Your users will be frustrated if they can't login to their new account because they mistyped the password when they registered. The retype password field is there for verifying that the user typed it correctly the first time. It doesn't have much to do with security because it doesn't affect anything else - you can check on the client to see if the passwords match; it doesn't have to be transmitted over the web or anything.

KyleM
  • 435
  • 1
  • 6
  • 13