Is a "repeat password" field necessary in a signup page?

  • Possible Duplicate:
    Why should we ask the password twice during registration?

    When designing a new and simplified signup page I got into an argument with a colleague about the necessity of the "repeat password" field.

    We designed the signup process in such a way that the user will be logged in automatically after completing the email verification process. So, at least initially there will be no need for the user to enter their password. Therefore the user will only 'verify' the password when logging in the second time in case we omit the "repeat password" field.

    We do have a "recover password" option so in the worst case the user could go through that process in case they mis-typed the password when signing up. But then again, how often do you mis-type your password?

    Even the big players don't seem to agree on which way is the best...

    Don't need to re-type the password:

    • Twitter
    • Facebook (although they require re-typing your email)
    • Dropbox

    Need to re-type the password:

    • Yahoo
    • Reddit

    Is this necessary?

    The point of having to repeat your password is to demonstrate how easy it is to miss-type the same thing twice in succession.

    DropBox doesn't have a repeat box, and the signup feels really confortable.

    Passwords are evil! Seriously, this repeat password rubbish is slowly dying out in the sites that have better signup and signin interaction designs. Try creating a new account on for instance.

    openid is nice for home users, but if your site is aimed at larger corporates then a lot will have openid providers like yahoo blocked, possibly even myopenid.

    Slightly off-topic, but I'm surprised no-one has mentioned the Lotus Notes approach ;) !See this link to a Lotus Notes password dialog animation By pure coincidence snapped from a Coding Horror post on the subject with a lot of comments.

    Twitter did great by me- their "don't need to retype your password" also includes a "don't tell you that you can't include spaces in your password" feature that caused me to create a password when I signed up that could not be accepted by their password page but they didn't tell me that at the time. Only after going through arduous password recovery did I find a page that finally told me my previous password was unacceptable...

    Typing a password incorrectly is incredibly rare, IF you're **reusing** the same password across multiple sites, because you've already typed it a thousand times or more. Users who follow better practice, by having a unique password for each site, are much more likely to mistype as they don't have the muscle memory trained.

    Another thought: If you don't ask for a confirmation of their password at the time of signup, then you should provide more assistance if they have problems signing in for the first time with that password.

    All of you are gracefully missing the point! **The re-type your password field is for the peace of mind of your users**; not yours. People are insecure when typing their passwords in a registration form (even when it's one they've used before). Yes, they can go though the (troublesome) re-cover your password field (even if it's right after registration), however if you have any common sense you'll know many of your users don't want that; and will go though a test of patience before realizing the problem, -if- they realize the problem at all. Rule #1: your users are not as "smart" as you.

    We've closed this as a dupe as we've got a newer, more focused question. This Q/answers got sorta derailed and I'd rather not bury any new answers in here.

  • orj

    orj Correct answer

    11 years ago

    I'm no UI expert but I think in many cases it is unnecessary. Certainly in my own experience it is rare for me to enter a password incorrectly. A better solution is to not have a password at all. Use one of the growing number of authentication providers (e.g., OpenId, Google, Facebook, Twitter, etc). Why does the user need another password for your app or site?

    The technical users of your app will use a password generator and/or storage mechanism. The non-technical users will use one of the favourite throwaway passwords that they use for many different sites/apps. Better to just integrate with an authentication system they already use. There may also be other knock on benefits for your application such as integration into Google Apps if you use Google's auth.

    If you do choose to require the user to provide a new password to your application then at least don't clear the password field on form entry error. Nothing is more infuriating than having a password field get cleared because you make an error in some other part of the form. You fix the error resubmit and then there is an error again because the password is missing. This drives me nuts. If you are concerned about echoing the user's password back in the HTML, don't. There are many other options. Encrypt it in the form, remember it in session state, use a dumby password in the HTML. Whatever, just don't force the user to enter it again!

    +1 using OpenID or similar and for not clearing the password on error.

    +1 I like the idea of deferring authentication to a trusted third party.

    Just OpenID!! Do something like stackoverflow. provide buttons for simple login using OpenIDs.

    +1 especially for the order of providers: OpenID, Google, Facebook, Twitter seems the right order to support providers. I'd rather have my app work only with facebook than only with twitter.

    This doesn't address the issue. Users still have to sign up with OpenID/Facebook/Twitter etc in order to sign into other sites/apps. You can't assume that they have those accounts or would want to use those accounts to sign in.

    I would also add third party apps as authentication providers. But please consider: Nobody (statistically speaking) has an OpenID and knows of it. Our webservice has several hundreds of thousands of users and less than 5% of all logins are openID logins.

    @pipTheGeek I always enjoy my password not being deleted after a failed try, but I complicate things a bit in my applications. I use JavaScript to hash the password on the spot, which in turn I send to PHP with Fetch API. On error the UI shows an error message, but does not delete the password. On success it replaces password in UI with hash (dots), so the user might understand what I did. Feel like it's safer that way. And there is always a Login with Google/Facebook option as well.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used