Forms

Why the Confirm Password Field Must Die

Sign up forms are one of the trickiest web pages to design. Including and excluding certain form elements affects the conversion rate. The designer’s job is to figure out which elements they should include or exclude.

A common question is whether designers should include a confirm password field. But the confirm password field works like an email confirmation field and causes the same problems.

Confirm Password Fields Lower Conversion Rate

Many think the confirm password field is necessary to include when creating a password. This is because a password field masks the user’s input. If users mistype their password, they won’t recognize it. The confirm password catches typos by prompting users to type their password twice.

While the confirm password field seems sensible, including it can lower your conversion rate. This research study found that the confirm password field was responsible for over a quarter of all users that abandoned their sign up form. It was also responsible for hundreds of user corrections, including field refocuses and deletes.

Once they removed the confirm password field and replaced it with an unmasking option, the number of user corrections decreased. Not only that, but it increased form starts, completions and the conversion rate.

Excluding It is Not Enough

It’s not enough to exclude the confirm password field. Many sites exclude it, but don’t offer an unmasking option. If users mistype their password, the masking will keep users from recognizing it. This leads to failed logins, password resets and user frustration.

You should include an option for users to unmask their password input. This allows them to check what they typed to prevent any errors. Knowing they typed in the correct password can comfort them before they submit the form.

Show Password Toggle

Including a ‘show password’ option is easy to do. Place a text or icon button inside the password field. When users click it, it’ll display their input unmasked. Allow them to toggle it to turn the masking on or off as needed.

Text Button

Your text button should say ‘Show’ as the default with a masked password. When the user clicks to unmask the password, it should say ‘Hide’.

text-button-toggle

Icon Button

An eye icon is an effective way to represent unmasking. When it’s clicked, display the eye icon with a slash over it to represent masking.

eye-icon-toggle

R.I.P. Confirm Password Fields

It’s time to lay confirm password fields to rest. What was once a common convention on sign up forms has evolved into something better.

No longer does your sign up form have to suffer from a high corrections and abandonment rate. By giving users control over their password input, you give them the peace of mind to complete your form.


Book

Affiliate

elegant wordpress themes

This Post Has 51 Comments

  1. Dave Reply

    Do you have any studies for the support time required for users who instinctively believe they’ve typed their password correct the first time and choose not to use the “Show password” toggle?

    I’d say the “show password” single field approach is a luxury for those with the staffing/time to support the inexperienced.

    Removing the confirmation password field must surely result in far more users experiencing the “forgotten password reset” workflow, which never fails to annoy. Particularly so on mobile, where entering complex passwords (which may have been set totally at random by password managers) is next to impossible.

    Abandonment rates must be balanced against the negative user experience of those forced to reset their passwords more frequently.

    I think the Show Password toggle has benefits, but so does double-password entry. We can’t dismiss either entirely.

  2. Dimitris Siakavelis Reply

    Oh let me disagree with this one, sorry.

    I’m not ready to allow anyone standing behind me to see – even for a split second – the password i’m about to use on that particular website.

    • anthony Reply

      Nobody wants someone standing behind them to see their password. But optional unmasking doesn’t cause that to happen. Being careless and signing up in crowded places where people can see your screen is what causes that. Making it optional allows users to have control over the unmasking so that they can do it when it’s safe.

  3. bact' Reply

    I’m not sure in which level this new design of passwrod will be dealed: at browser’s internal engine or at userspace level (via JavaScript/CSS for example).

    Normally, password field is done by input=”password”. When the browser see this, it will recognize that a value in this input field is a password – and it has to take a special care with it, treat it differently from normal text value (from input=”text”), including the masking.

    If the browser doesn’t provide the masking/unmasking toggle mechanism natively, this toggle can be done in userspace – modifying the behavior of input=”text”.

    But there is a big privacy/security problem here. Because the browser cannot recognize that the value in the field is actually a password. And the browser may remember the password, even if the user set in the browser’s settings that he doesn’t want it to remember password (but remember only values in normal fields).

    Apart from the privacy/security concern, I think the overall user experience will be compromised if the browser start to do something that the user is not expected.

    Overall, your proposal might be a good idea, but it should be better to implement this at the browser internal engine level 🙂

    • ab Reply

      do you even know what you’re talking about?
      it’s simple dom manipulation of an input field. The browser will deal with the input of the field in any case, that’s the whole idea about user input. You type, your OS APIs interpret and send to browser (or rather browser uses listener)

      • Nathan Reply

        It appears you’re the one who doesn’t know what you’re talking about.

        Yes it is simple DOM manipulation, that’s not the issue here. The issue is that after manipulating the input to be type=”text”, the browser may handle the input differently than if it were type=”password”.

        As previously mentioned, the browser may save the password as text for the next time the user visits the page.

        A solution to this would be to handle the form submit with javascript. Ensure to revert text fields back to password fields before submitting the form. But OP’s point still stands, attention to detail is required here when dealing with users’ password.

  4. bact' Reply

    Overall, your proposal might be a good idea, but it should be better to implement this at the browser internal engine level 🙂

  5. Breno Rocha Reply

    I’m not sure about that. Sometimes our eyes deceive us. And it’s not because the password is hidden, it’s just because sometimes we want to complete the form quickly and we do not realize if we made some typing mistakes.

    • anthony Reply

      Seeing the password unmasked allows users to catch specific typing mistakes with less effort. Whereas, typing mistakes on a confirm password field brings up an error message, but doesn’t tell users where specifically that mistake is. They end up refocusing the password and confirm password field and deleting/retyping both inputs, which takes more effort.

      • Breno Rocha Reply

        I mean, sometimes when I’m in a hurry, I do not check the fields properly and some users too. So, if I confirm a wrong pass (supposing I typed and confirm a different password than I had in my mind), I have to request a new one.

        And maybe some users can’t feel comfortable while typing a password on a form with someone next.

        • anthony Reply

          If you confirm a wrong pass than the one you had in mind, thats your mistake. If you’re typing your password right next to someone, thats your fault. Unmasking or masking has nothing to do with causing those mistakes.

          • Jorge Toro

            Before I begin, let me clarify that I am not against the Unmasking password feature. I am more concerned about using it as the only way to handle password input and dismiss the password confirmation as something bad.

            A few comments…

            It is actually a “case study” not a “research study”. Research studies are much broader than case studies (I’ve done both). Using a case study from one company alone should be looked at with a grain of salt since one case study should not be used for generalization.

            “…that’s your mistake… that’s you fault…”

            “If you confirm a wrong pass than the one you had in mind, thats your mistake”…

            Good design should prevent users from making mistakes in the first place (any HCI book will tell you that). why? because we are humans… imperfect machines capable of making mistakes on a regular basis… and that’s precisely what the confirm password feature aims to solve: Preventing users from typing the wrong password. The Unmasking password also aims to solve the same problem differently but comes at the expense of opening the door for a user mistake: accidental password revealing.

            With that said, I think this feature would be great for “email” confirmation, but I still have safety concerns with passwords.

            As I mentioned, unmasking a password removes the password confirmation step, yes, but it opens the door for users to accidentally reveal a password when they shouldn’t (again, good design should prevent us from getting into those unsafe situations in the first place).

            Now, in terms of effectiveness, I am pretty confident when I say that if you do a GOMS analysis you might find that both methods might have about the same complexity.

            Using Confirmation
            1. type pwd
            2. type conf. pwd (as pwd is being typed, system can automatically verify if the pwds match)
            3. if wrong pwd, repeat 1,2 or 2

            -or-

            Using Unmasking
            1. type pwd
            2. reveal pwd (move mouse over icon, click on icon)
            3. read/analyze pwd (if pwd is complex, this might take longer than a simple one, for instance “D@nc1n6E!ephant” vs “dancing1”)
            4. if pwd is wrong, go to step 1 and fix

            If you allow fixing an unmasked password, unmasking will be faster. Once again, the security aspect of it is the problem… (but I still argue, this is great for email confirmation)

            Also, on the security aspect of things let’s not forget screen sharing or screen recording software or even video cameras (someone might not even need to be sitting next, someone could use a zoom camera from the distance and that’s it – yes, hackers will love this one-). If you are in an environment in which you are sharing your screen or your screen is being recorded (which could happen and as humans we could accidentally forget of such thing), unmasking the pwd opens the door to accidental revealing.

            …and yes, some might argue again that its the user’s mistake, to which I say the system should account for such human characteristic instead of shifting the blame on the user (saying “that’s your fault”) because if we just put the blame on the user, then we should remove many designs that primarily aim to aid the user’s limitations on making accidental mistakes

            – Don’t beep when you leave the lights on/door open/key in ingnition in your car (to name a few). It’s your fault if you don’t check for those things.

            – Don’t step on brake (or clutch) before turning engine on (in cars). It’s your fault if you don’t know you should do those things before turning the engine on.

            and the list goes on and on…

          • anthony

            Security is accounted for by giving users control over unmasking. The toggle button allows users to turn masking on and off instantly. This kills two birds with one stone by giving users a balance between security and usability.

            If we were to say, “never unmask passwords ever for the fear of someone stealing your password”, that would not solve any of the usability issues users face when creating passwords.

            If you want to give users the best experience, you have to look at both sides – security and usability, not just security. This solution is a balance of both.

  6. Pawel Smietanka Reply

    I would say that password field must die.

  7. Mike Reply

    I agree this is much better than a redundant password confirmation. I’d argue that “show/hide” is a lot clearer than the iconography, though, and would recommend using the words over using an eye icon.

    • Mark Reply

      +1

      Iconography in this case isn’t ubiquitous enough yet. Show/Hide is short enough anyway.

      Only caveat here is foreign languages. English is more concise than say, Spanish.

  8. John Baker Reply

    Heh these comments remind me of what a round table debate about some point of ui contention. One of the things that helps me is this phrase.

    “I could be wrong.” or better yet “lets prove me wrong”

    Show me the metrics.

    1) Form drop out for one.
    2) Or how many times people hit the unmask button (I bet its zero)
    3) Or how many times people use the forgot password system.

    Randomly display both options at a 50% ratio and measure the above metrics. Thats your answer.

  9. Randy C Reply

    I do like having the ability to see my password, but only as an option I can choose – and usually that’s only when I’m trying to login.

    I am unconvinced that seeing the password in text is going to help the user catch his/her subtle typo.

    If you want the best user conversion, just get the email and don’t ask for a password at all.

    If you do need to collect a password, you will create a worse user experience for the percentage of your users who mistype it upon registration and then can’t figure out why they can’t login. You can count them as a “conversion” and add them to the numbers you report, but few of them will continue. I’d rather lose those who don’t want to type a password twice. There is a reason why systems prompt twice for the password – it is virtually foolproof.

  10. Liam Reply

    Believe it or not, people do use the internet in public places and need to sign up for things on-the-spot with people around. Simply telling everyone that it’s the user’s fault if they’re with people and to wait for later isn’t a suitable solution.

    As a UX designer your job is to make things easier and quicker for users. Telling them to wait until they’re in a private place is NOT an excusable solution, nor is letting them get their password wrong and then needing to reset it (or find another site with the same solution).

    Yes, there are still UX problems with the “confirm password” field, but it’s used everywhere for a good reason – it works.

    • anthony Reply

      User controlled unmasking isn’t telling people to “wait for later” to sign up. Why? Because it’s USER CONTROLLED. That means you don’t have to unmask your password if you don’t want to.

      If the user makes a conscious decision to unmask their password knowing there are people behind them and someone steals their password, IT IS THEIR FAULT. Just like if I have a hundred dollar bill and I drop it on the ground in a public place and someone steals it, it’s my fault. The user experience designer’s job is not to teach you how to be a responsible human being.

      • Richard Reply

        I think you need step back and realize you’re supposed bulletproof strategy is not as good as you think it is.

        If I’m in a public space when registering then I have no choice but to reveal my password to confirm what I’ve typed. If the user is at all concerned about security then they will absolutely have to “wait for later” to make sure nobody sees what is being typed. You claim your strategy isn’t telling anyone to wait for later to check their password but then go on to say that not waiting is irresponsible.

        It sounds like you don’t really care how effective your strategy is, you just blindly believe you’re solving a problem by ignoring the one you’ve just created. The confirm password field, as much as you hate it, doesn’t suffer from this problem.

        • anthony Reply

          You act like if you’re in a public place there’s a 100% chance that everyone will see your password if you unmask it. Do you know how paranoid and delusional you sound?

          Most sites don’t even have a confirm password field nor an unmask button. Look at facebook, twitter, uber, evernote and dropbox. None of these popular sites even offer users a way to confirm their password. Are you telling me none of their users can type their password correctly when they sign up? You’ve never typed in your password correctly when it’s masked? You act like typing a masked password is impossible to do when so many users do this every day on the most popular sites.

          If you’re in a public place, and you don’t want to expose your password to people staring at your screen behind you, what can you do? Here are some ideas you didn’t think of. You can turn your computer away, lower your screen, put your hand over your screen, move seats, or you can just type your password without unmasking it since that’s what most users do and have been doing. Where is the “wait for later” in that?

          • Glen

            From experience, people hate their password being exposed when others are around (remembering a lot of people use the same password for everything). To check it, they have to expose it – otherwise risk a typo. Simple. A typo leads to a password reset being needed – a longer process than confirming the password with an additional field.

            There is situations where people are around – we cannot be dictators when it comes to people’s choice of when to use/sign up for a product. e.g. “only sign up in this situation”. Imagine trying to explain this to your client: “Our sign up is not for shared spaces, or anywhere where other people may be able to see the screen”

            UX is about empathy. Important to remember this. An empathetic approach is not “it’s their fault”. It is not their fault – the only means they have been offered to ensure a correct password is revealing it.

            I think this solution works better on devices such as mobile, where the mobile device can be tilted towards to user, and the screen can be hidden from view easier.

            I like the solution, and have seen it used for quite a while. But it is not full-proof like you want to believe.

            Think it is better if we take the challenges of this not being perfect, to create better solutions – rather than forcing something that has issues as a flawless solution.

            Maybe we should drop the password confirm field and fit all computers with review mirrors? 😉

  11. Kate Reply

    Usually when I give up on a signup, it’s because the feedback is terrible. If the error is not easily recognizable by red font/outlining and refocusing I have to scroll through the whole form looking for my mistake. It’s not so much a password mistake as any form mistake (required fields are the worst).

    Also, it appears, with this solution, I’d have to move my hand to a mouse and/or move the mouse to the show/hide toggle. That’s . . . probably just not going to happen.

    Furthermore, while my eyes can fairly easily catch a mistake when looking for English word misspellings, the chaos that is my password is harder to decipher. It’s much faster and more accurate for me to blindly type it.

    The last two points are probably my issues, or the issue of any keyboard-centric fast typist, but the first I imagine is universal.

    Regardless, I’m with John Baker. What’re the metrics? What is the scope of this study?

  12. Jorge del Casar Reply

    I made a web component for that one year ago and I migrate to Polymer 1.0 recently.

    http://jorgecasar.github.io/input-password/

  13. Jai Brinkofski Reply

    Question… which is better, higher form conversion with more junk accounts due to mistakes or lower conversion rates with less junk accounts because the system forced the user to confirm their input?

    I’m not sure there’s a “one size fits all” answer here. It depends on the business rules and what’s important to the client.

    And also, show me the data. I’m not arguing one side or the other on this… but the data needs to be shown, and the research done, on more than one site/context to be conclusive.

  14. AMG Reply

    I wonder about the accessibility of unmasking the password. It would have to be carefully coded to both prevent user mistakes and to allow use by folks with various disabilities. A non-visual person may not know their password is exposed. It may be more difficult for non-visual users to mask and unmask. If a mouse is required to expose the password, keyboard-only users who are physically unable to use a mouse would not be able to use it.

    • caroline Reply

      I’m dealing with this very thing at the moment. We’re pondering a timed show/hide where it would remain visible if clicked for 5 seconds, but I wonder if an aria-live could be used to inform the user that it is now hidden again. Then i just find myself asking Why, why now? So many fish and only 1 tiny pan. 😀

  15. Jon Green Reply

    The big question that’s hanging over this is…why? Why was it acceptable to have a confirm field, and now not?

    The answer is the prevalence of mobile access. With a physical keyboard, tapping the TAB key, and typing the password a second time is no big deal. But on a mobile device, with on-screen touch keyboards, and the many opportunities they offer to mis-key the digits, “special characters” and mixed-case that are becoming increasingly mandatory in passwords, typing passwords becomes a pain that users only want to suffer once.

    Perhaps it’s time to abandon passwords completely, as a rather keyboard-specific authenticator. You could use a grid of small graphics (randomly positioned each time), and have the user peck out four in a sequence of their choice. You could have a challenge-response system based upon something in the user’s unique knowledge. There are many other ways.

    One password field, plus a reveal button, is not the solution. It’s just mitigating the problem.

    Instead, fix the problem.

  16. David Millar Reply

    I’m curious as to the feelings of confirmation fields for other datapoints. For example, verifying an account number by having it typed twice, despite the field not having been masked, was part of a recent request. Are there better ways to ensure data entry besides having to type it twice. beyond simply having it visible? What are others’ experiences on the matter?

  17. paul Reply

    Why not do both? confirm field and have unmask option on both? one can make it easy on oneself by showing password in both, and the confirm still serves its purpose of alleviating possible mistypes in the password….but if in a crowded area, then leave both masked…

  18. vincent jouty Reply

    I agree but I also think it’s a little too soon.
    Because I’m not sure that every people will understand the meaning of the icon or the show/hide at first glance. (I do but I’m not every one).

  19. Jacob Jacobson Reply

    What’s bothering me most about this is that the show/hide link is confusing. It feels like a label that doesn’t match the current state of the field… Same applies to the icon version. I get what’s happening, but it’s confusing.

    Wouldn’t a checkbox underneath the field labelled “Show password” be a lot clearer?

  20. Jason Glaspey Reply

    The comments in this are pretty hilarious. As a very regular user of the Internet, and someone who signs up for things all day every day, I can say I would prefer the option to show/hide my password.

    I would assume that the vast majority of people using the Internet are not signing up in a public place with people standing behind them. I would also assume that people can type in their passwords correctly most of the time. However, when I type my passwords in, sometimes I hit the last digit or two and wonder, “Did I just fat-finger that and type the correct letter AND the letter next to it?” In those cases, a password reveal would be very quick, and very helpful. However, in the absolute worst situation, where there *is* someone standing right behind me (maybe a stranger, maybe a co-worker watching me pull up a report), all I would have to do is slow down and type in the password very carefully and purposefully and BAM! I can still login/register without revealing my password.

    I don’t see how giving people an option is a bad thing.

    However, there are also better ways to implement confirm passwords also. I’ve seen systems that don’t check it while you type, and you hit submit, and you get a random error and all fields are now blank — time to start completely over with the entire form. That’s terrible. I’ve also seen sites checking your fields for errors as you type, and you get those wonderful green checkboxes next to the field when it passes (email, phone, whatever). When you get to the password, typing it a second time shows immediately if it matches or not. That’s a a good system.

    I think in the end, it’s about testing for your audience. Some hyper-paranoid AOL user might want something very different than a Bay Area developer who knows how to type and knows what the choices are and can understand the tradeoffs.

  21. Snaily Reply

    I recently used this design pattern for a web application and was told by the stakeholders that this is better-suited for a mobile site than desktop. Thoughts?

    (Our application is desktop-only and I couldn’t really come up with a convincing defense. Had to include a confirm password field eventually.)

  22. Spoilt Reply

    When I fill a form, my hands are on my keyboard, not on my mouse. I’m pretty sure the password confirmation is at least as fast as the “unmask” pattern…

  23. Ann Wuyts Reply

    Rather than allowing for ‘show password’, the solution now often seen on mobile log-ins may be effective as well: show the character for a brief moment before rendering it as an asterix. Ok, this still allows for errors, but as a user you can ‘follow along’ and see if you are typing the right pass.

    (I’d only enable this for password creation, not for login, as an observant person looking over your shoulder could read along as well. Same risk as with the ‘show password’ though.)

  24. Stomme poes Reply

    I dunno about “average” users, but a lot of developer-types don’t type our passwords into the confirmation field. We select the first one, copy, and paste.

    If the passwords being hidden are the reason we’re forced to type them twice, why do we have to type our emails twice too? (and yeah, copy and paste again, unless some hater has disabled that)

  25. Xavier Reply

    Not sure about this pattern.

    First, as a user, i don’t want my password to be revealed by default when typed in (the option to reveal it on demand might be a nice-to-have).

    Second, as a user, i don’t believe that i make mistakes when typing in my password and want to get through the form as quickly as possible. I therefore won’t take the time to stop, decide to click the “unmask” button, check, then click the “mask” button.

    I will therefore submit the form, regardless of whether my password is right, which may or may not have a number of adverse consequences.

    Checking whether the password is correct is a system-centric requirement, not user-centric. The concept of double checking the accuracy of information (either through a “retype” field or a “review” page in a sales process for instance) is not something a user would naturally perform when not prompted to do so, as this is always handled by the system.

    If the system doesnt ask me to check, i wont do it. The unmask functionality has good intentions in theory, but i dont think would work in practice.

    • anthony Reply

      What you’re describing applies to login forms. I’m recommending this pattern for signup forms. Users do check their password on a signup form because they don’t want to lose their account. It’s the same as checking your shipping address when you buy a product online so you don’t lose your package. There’s an incentive to check when something of yours is on the line.

  26. Daniel Reply

    I understand that I am not an average user, but I feel a visceral feeling of wrongness and uncomfort when I don’t have a confirm password field. It is much harder for me to visually check a password then just to type it again.

  27. Klaus Reply

    I have been reading your (and others) blog posts about password masking and decided to do my own experiment. It confirm that the majority of the users prefer to unmask the password. I saw also another interesting pattern. About one fourth of the users entered the complete password, and only unmasked it to review the inout before the click on the “Login” Button. Here is a short summary of the experiment:

    https://medium.com/@quant_ux/how-people-unmask-passwords-102276c7d803#.jzuwry199

    Cheers,

    Klaus

  28. Nisha Taneja Reply

    O WOW! I never actually thought about that. I agree that it is really irritating to fill in so many fields at the time of sign up. After reading this article I really realized that there might be other alternative ways to get the same results you want.

  29. David Reply

    For me there is another UX aspect to consider…

    Many users distinguish between Login and Registration by the number of input boxes. It may be an anti-pattern but one that users have become very familiar with over the past two decades.

  30. agm Reply

    I just implemented this in a React app and its 1337% better. Thanks. I was actually Googling to find examples of password confirms because I am using email and password icons, and the password confirm was looking like it needed some kind of redundant icon, so I used your technique instead with the eyeball, and it came out deadly. I have lots of experience with UX as a QA engineer, and I totally agree the extra field is pointless if you can just expose the password. I’ve read many studies on how extra form fields increase bounce rates. No one likes a wall of text.

  31. Binh Bui Reply

    Really nice article. I completely agree with all the points you made there. Those passwords confirm fields have always annoyed me ever since.

    I wrote an article featuring some Polymer based password inputs web components. And I believe that it’s not a coincidence that 4 out of 5 does not have a password confirm field. For anyone who wants to read, here’s the link:

    https://vaadin.com/blog/top-five-web-components-for-password-inp-1

  32. bad attitude guy Reply

    Great example of when a UX team makes decisions without being informed by the tech. There are a large variety of reasons for implementing a confirm password that includes security and conversion rates while the thinking isn’t wrong it’s lacking other input on why these fields exist in the first place..

  33. Ayaz Ahmed Reply

    This is very well written. I just feel there might be cases where having a confirmation field would be necessary. Let me briefly explain below:

    1. Payment Apps
    One of the single biggest reason why people abandon payment apps is that they fail to remember their passwords / PINs. Hence, having them type in their password or MPIN twice is a good step to ensure that they get to ‘practice’ putting in their password.

    The check that the two entered password must be the same, also ensures that they consciously type in the password / know well what they are typing.

    2. Privacy
    Some users won’t be comfortable displaying their password for everyone to see. A confirmation password is great for them to type it in again without revealing it to anyone.

  34. Harry Reply

    It is true that there is a possibility that some users may not notice this show/hide feature. And that’s not “user’s fault”. And don’t notice an error in typing the password either.

  35. Nick Reply

    The research study you cite is actually a case study describing an experiment on a specific site. The case shows several changes made to a sign-up form, not just removing the ‘confirm’ field. We should be really careful quoting metrics and conclusions like this, it’s quite misleading.

  36. Kai Reply

    I’m surprised that no one seems to have mentioned the most obvious flaw with removing the password retype function.

    The password retype forces the computer to check the password, and will almost certainly catch any mistake. But the password reveal option only asks a user to check it. This means for a password to be checked the user will have to press an additional button and we are relying on them to spend the energy to do that, rather than rely on the computer to do the work for them.

    It’s not security that is the biggest issue. It’s that people won’t even use the check password feature unless they’re sure that they’ve made a mistake, and will frequently sign up with accounts with incorrect passwords, causing a worse and more tiresome loop to happen when they try to log in rather than when they first sign up and it’s easier to solve.

    And while on the front end it may seem that we lose less people because the account got created, what’s the point of a user having created an account if they can’t access it afterward? Where’s the data to support the users that create an account with this method are signing in even once? Where’s the data to support that users aren’t just having to go through the more cumbersome password reset loop and falling off there?

    Though the computer checking the password may create a tiresome loop for a user, the easiest way for us as devs to fix that loop is not to remove the password retype feature, but rather to add the view password button to the retype password feature, so a user can see where there mistake is and fix it, but it’s still primarily the computer checking to make sure it’s correct.

Leave a Reply to Xavier Cancel reply

Your email address will not be published. Required fields are marked *