Tips for Better Signup / Login UX
learnui.design
learnui.design
I've seen so many permutations of garbage UX:
* the 2FA flow trying to save your password * credit card inputs not having any labels, only having some labels, or having wrong labels * credit card inputs doing some javascript bullshit like manually autotyping a space to simulate the groupings of the card numerals, which inevitably breaks in many comical ways when the browser sets it. My favorite it when the grouping code conflicts with the "don't type too many numbers" validation code and results in only 3/4ths of the number being inputted. * things not labelling login forms properly so that mobile browsers pick up the hint to offer you to open your password manager * websites having a million similar domains they own and copiously link between, so that you end up trying to log in to like, citicards.com but your passwords is only saved for something.citibank.com or whatever.
I know it's a cliche but I'm commonly wondering: have any of these people even tried using their own website even once???? I know that if I owned a company and the way that people give me money was so comically broken, I would be sending Bezos-style ? emails to the teams responsible.
In one especially bad case I encountered, the tab key after the username would focus on a "clear username" button which appears after entering the first character of the username. So the auto-typing of the password manager would enter the username, tab to the button, enter a password into the void and then click the username reset button, leaving the login form empty. Who needs a button to clear the username field in the first place? That's seems so useless to me.
That is done by evernote IIRC. Why? Just show me both fields.
'john@doe.com '
resulting in errors like 'invalid email'. Since whitespaces are invisible to users, they can't figure out what's wrong.
While it technically might make passwords very slightly less secure, it makes life much easier for users, so I personally think it's worth the cost.
basically the hashing algorithm they use strips out certain information, which means that e.g.
"PaSSWord123" "pAsswORD123" "PaSSWord123 " etc
all hash to the same value, and so are equivalent.
Wow - non-case-sensitive passwords seem like a bad idea...
How is "flipping all the character's case" different from case-insensitive?
So, if your password was:
fishCAT
They would accept fishCAT, and also FISHcat and FishCAT, and that's it.
We also implemented it at Pinterest, I think it's a pretty good idea for a few common cases, especially for users typing their password on mobile.
Before doing this though, you want to make sure you have rate limits in place against brute force password checks for account takeover.
1) Do not limit the length of the password to some arbitrarily small number.
2) Do not validate email beyond the simplest, "includes an @ and a period. Email is validated by sending a confirmation link.
3) Don't get so stupid with the "secure password" special character crap. Some of us use super long, but memorable passwords, which are more secure than your bull#@!+&$
Sharing details, as many “sacred cows” are slain:
- User-generated passwords should be at least 8 characters in length
- Machine-generated passwords should be at least 6 characters in length
- Users should be able to create passwords up to at least 64 characters
- All ASCII/Unicode characters should be allowed, including emojis and spaces
- Stored passwords should be hashed and salted, and never truncated
- Prospective passwords should be compared against password breach databases and rejected if there’s a match
- Passwords should not expire
- Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters
- Two-factor authentication (2FA) should not use SMS for codes
- Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used
- Users should be allowed 10 failed password attempts before being locked out of a system or service
- Passwords should not have hints
- Complexity requirements should not be used, ex. requiring special characters, numbers, uppercase, etc.
- Context-specific words, such as the name of the service, the user’s username, etc. should not be permitted
- Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters
This one can be counterproductive for the same reasons as the complexity requirements that this list prohibits. It reduces the space of available passwords and might block a strong but memorable password that coincidentally has an invalid subsequence somewhere in it.
- Two-factor authentication (2FA) should not use SMS for codes
This has its problems but depending on the situation you might have few alternatives available and some form of 2FA might still be much better than none. Apparently my government, my bank, and several well-known online services all share this view.
Most likely, the bank is doing it wrong because of bad old policies and lack of security education in the security and risk groups. The well known online services use your number to tie to data broker feeds. Not sure about your government, but likely inertia and misinformation.
Disclosure/disclaimer: megabank CTO opinions are my own
As of today, probably 3/4 or more of the online services I use that have serious security requirements are favouring SMS-based 2FA over just using ID and password as they used to. This can get a bit annoying, but it's obviously more secure than not doing it.
On the other hand, while it's definitely feasible to take a wordlist and make random permutations of sticking words together, I think in general that sort of password is used less often.
100% Agree password managers are the way to go, but for people that aren't using them I would definitely suggest long/multiple random words together over short LEETspeek with special char number tacked onto the end style password.
https://github.com/NotSoSecure/password_cracking_rules https://github.com/praetorian-inc/Hob0Rules
We're excited for other factors to gain more prominence (e.g TOTP, face id, touch id), but in the current world it's hard to recommend against a password factor, as long as you're following NIST guidelines to compare against password breach corpuses.
I think in general the advice is that there should not be any limitations on special characters anywhere in the tech stack at all. (Including a broken UI that won't let you input special characters.)
The situation you described sounds more to me like a very poorly written application.
I got bit by this recently.
I decided to update my Bank of America password, and so generated a 30-character password.
Bank of America's password change page accepted the 30 character password. But then I couldn't log in because Bank of America's login page won't allow passwords longer than 20 characters.
I ended up having to call Bank of America on the phone and the rude web site tech guy said that he's been there 10 years, and 20 characters has always been the limit.
1 - If that's true, then don't let me change my password to 30 characters.
2 - Why would a bank insist on a password scheme that is clearly LESS secure than a reasonable alternative.
Full stop. Require email confirmation to complete signup. If the address can receive email, it's valid, it doesn't matter what's in it.
Periods are not required, either!
This is done by HTML by default, if you use the for="" attribute or nest the input in the label.
> No user should have to guess at what the password requirements are. Show them when they’re relevant (P.S. And remove them when they’re not).
Or, just always show them. It's hard to make them accessible if you can only see them when the field is focused.
> Let users see their password
This is arguably an antipattern. If this was a best practice, it would be baked into the browser. Encouraging password manager use (every browser comes with one built in!) is what we should be aiming for. "Confirm password" fields prevent the problem that the post tries to avoid, and it's really not "onerous". Or, use something like WebAuthn.
Edge already support it for any password input. Yes it's better to be supported by browser, but it not mean not good to be implemented by website. How "Confirm password" solution better? It's completely redundant for password manager user. It also won't help from CAPSLOCK.
Caps lock is a problem even with the ability for a user to see their own password, because they need to take an additional action to unhide their password. Most users won't check, they'll just hit enter. And again, this is something the browser can (and depending on what you're using, already does) do—browsers have shown an icon or tooltip.
On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop.
And even in the very rare case where you goof with caps lock, there's a forgot password flow that lets you (hopefully) reset your password with the same number of steps as a good OTP flow (which is literally what password reset is). In almost all cases, this is even preferable to adding the complexity (accessibility, L10n, etc) of a "reveal password" toggle OR a confirm password field, because properly implemented it gives the user the chance to use a password manager a second time.
It's absolutely bizarre to expect every single web developer to need to know and implement every possible best practice around password handling of this sort, when it could be handled by the (already semantically annotated) GUI control that the user agent implements.
I should against it. On mobile device, anyway we use software keyboard to input so we must hide display from others when input password. So displaying last character is harmless. OTOH desktop users sometimes can't hide their display from others, and they type via keyboard. So always displaying last character isn't good for security. Eye button for selectively showing password field is fine.
Yes Caps is still problem if user never checked by clicking eye button, but still what's the point to adopt confirm field?
I agree that ideally most developer don't have to care about that but browser should.
Validate that your passwords match immediately, yes, but be aware that the password fields may be filled in / altered by a process other than typing a character! How do you describe to a non tech user that the only reason the new password and confirm password fields are actually the same (even though there’s an error) and to proceed your only option is to hit space bar in one of those fields and blindly delete it. Then it updates the validation and you can proceed?
Along the same lines- sites that don’t let you paste in your password from a password manager. What’s worse - not letting you paste in only to “confirm” your password. What’s the point of that?
Just finding the account page to change your password is super confusing. There’s typically a little user icon in the top right so I have shown them that. But after that, sometimes it’s in “profile” - other times “security” - and other times it’s hidden under a few levels of menus. Some sites call the password a “passcode” - and on and on.
Password complexity requirements have gotten out of hand. “At least one symbol but not more than four, two of which can repeat - and only the symbols @ and ! Allowed”. Really?? Now I have to specially tweak the password automatically generated by 1password to match. Again, explain that to your grandma.
SMS/2fa prompts using a password field - whenever you fill one in, it prompts 1password to helpfully remember that password for you. Super confusing for a non tech person! Now they’re potentially adding a ton of new “passwords” for this website into the password manager, and they have no idea which one to use when logging in again.
Email “validation” - I gave up using my personal non gmail address for sites as most of them claim that the non standard tld I used was not “valid”.
For the password requirements, I would actually always show them as a list of bullet points (length, casing, special character, number, no name…) which would validate on change, from a list of red crosses to a list of green checks.
One thing that hasn’t been mentioned in the article is l, if you’re doing online validation (on change, on blur, and on focus), if the submit button of the form should be disabled as long as the form isn’t completely valid.
I see this so often, and it adds no security, and bewilders the user.
When someone clicks through from an invite email, you can assume that they have control of that email so slip email verification, and just ask them for their password.
We modified keycloak to do this and it greatly reduced support calls. It's a mystery to me why it's not out of the box behavior.
Password reset emails usually expire after a short time for security reasons. Maybe the extra verification step when accepting the invite is for similar reasons when the invitation isn't accepted quickly? Unlike for password reset emails, you can't assume invitation emails are likely to be opened soon after being sent either.
The difference with a password reset email though is that it unlocks all of the user's existing data - posts, images, contacts, whatever.
For our invite emails, there is no user data yet, since we are inviting them to join as a new user (in our system - HR SaaS - they are actually a candidate). So there is no exposure in having invite links that work for a week or longer.
In some other use cases, yes a new user will see some sensitive data, e.g. their teammates contact details. In that situation there is a case for very short-lived invite links (just as for password resets).
But still we could do so much better than making them enter the email address again.
I think this is an underdeveloped area of usability in auth systems (that I'm familiar with anyway).
For example, in my last (extremely large) company, IT would helpfully create multiple email addresses for us (UUID plus firstname.lastname) and you could also ask them to create one that you're used to using. So if someone emailed me at work, it was not obvious which email they used and if I then needed to use those credentials to login on a different device, I wouldn't know what to use.
I'll admit I'm not familiar with the sort of email system you are talking about, nor the benefits it might provide.
No different from any other signup email in that sense.
You could certainly sign someone up for mailing lists that send them a lot of messages that they have no interest in and don't want. It might not be "spam" in the sense of ads, but it's unwanted.
OTH I see this more with SPAs, because there's not really a "page" to redirect back to, just a bunch of browser-local React state that shouldn't be trusted across authentication boundaries.
I feel browsers should do "6. Let users see their password", not the Web app.
Could probably be improved by https://html.spec.whatwg.org/#autofilling-form-controls:-the...
Some simple HTML on display would be nice.
This! I spent 1s for every Sign In because I'm non native.
Also add: 0. Don't obscure login path. Some websites shows big sign up form or link on top page, but shows small login link.
While this sounds great advice for telephone numbers in theory, but in practice browsers on Android replace the normal keyboard with a big number keyboard without any "autocomplete".
So the end result is when a designer makes input(type=num) I actually have to fill in my whole phone number by hand as opposed to using the autocomplete which shows my phone number as soon as I enter the first 2 digits. I guess it's partly android's keyboard fault for hiding autocomplete suggestions on whim.
In the end, we choose the [day][month][year] dropdown set because it was the only one that didn't drive our users crazy. I really loved the iOS control though.
That's the one UI control I hate the most. Please don't do that. It replaces 3 seconds of typing 1 (tap) 15 (tap) 1969 into a tedious thumb game, especially if you have to scroll through three decades of years. Even Apple recently replaced it (https://www.idownloadblog.com/2020/08/12/redesigned-date-tim...), thank god.
Pleeeeeeeeease don't do that. The dropdowns are fine, and much superior.
I realize this isn't data. What you call "awesome" I call "nightmarish". I would love to see actual research on the usability of that particular date picker scroll widget... maybe most users prefer it? I dunno.
With our [day][month][year] dropdowns we have no more complaints on picking date times. But I have a feeling the iOS experience took a hit. Again, this is personal and not backed by data (because we simply have no more birthday picking complaints).
The reason we do it, is to show the MFA textbox, if and only if they have MFA setup.
However, there are some accessibility concerns. Screenreader users may be dumped into a form field without context and/or explanatory content, which may have preceded the form field and may be essential. Sometimes it's still best to let users decide, when they are ready for a specific interaction.
[1] https://medium.com/@gavyn/til-autofocus-inputs-are-an-access...
[2] https://brucelawson.co.uk/2009/the-accessibility-of-html-5-a...
That screenreaders are crap doesn't excuse breaking flow for 99.9% of users. Autofocus is essential for the ergonomy of all single-purpose forms, be it a search form, login form or order form. The first form field a user will interact with NEEDS autofocus.
Also, as always with minorities, the 99% argument isn't of concern. We, as a society, have decided to provide for accessibility requirements. In many countries it's a legal requirement for years to built websites accordingly. As a designer, you're liable. That's it.
P.S.: It really depends (quite literary) on context: if you open a modal pop-up on a specific user request (e.g, a button click/press) and users know what to expect and you provide appropriately labeled fields, autofocus is fine and helpful. However, if you open your page with the usual "subscribe!" overlay and autofocus, it's pure evil.
On the context, we do agree however, autofocus should only ever be used on pages that are single-purpose. And no matter what the marketing department says, getting newsletter readers is never the single purpose of any page except for the plain "subscribe to this newsletter" page you might have hidden somewhere.
You can, and probably should, go one step further and serve the same HTTP-response (size in bytes and response time) as well.
I am 35, not 8. Just say "This is not a valid email address".
Failed login should not say anything more than necessary. If the user enters a valid email and the wrong password, just say "invalid login". If you're going to display the password requirements, do so always, or don't do it at all.
The problem is that a malicious party could try usernames until they get "the password is incorrect for that user", and now they have a valid login. This is especially bad if the login is email, because now they have a valid email address to spam, and possibly phish the password.
Sometimes being too helpful is bad security. It's always a tradeoff, but something as simple as not giving away information protects both the user and the service way more than a bit of confusion.
That said, fast.co does this to streamline their flows.
If on such a form you output something like, "a user with this email address already exists", bots with targeted email could scan for site accounts.
On the other hand on a separate login form, you can always output "invalid credentials" on non matching email or password.
Indeed. A good login form will give away nothing about whether or not the attempt failed because the username doesn't exist or because the password was wrong, or anything that leaks to a malicious party information. There's always a balance between security and convenience, and where that balance lies is determined by your threat model. It's almost universally an anti-pattern to respond in a way that lets a potential attacker that they've found a valid username for your site.
I really wish this one would catch on, it's such an obvious and easy feature
Also if you're app is sending reset passwords emails to emails that don't exist, that's a bigger issue.
If I accidentally put my email and password in the "Sign up" form instead of the "Sign in" form, just sign me in.
I don't need to know that a user with this name already exists and have to go looking for your sign-in form to enter everything again.
What a nightmare for UX are those, I have a experience to share.
On a client product that I was working as UX designer they have implemented the Google Sign Up option, and a huge problem is that by design, the Login button also works as a Sign Up button.
And a common user case was that people initially create their account with email/password, and later in the login page seeing the "Login with Google" button chooses to use it (even if is below the email/password form), and in many cases you got users that create secondary accounts accidentally. Is frequent that people have multiple emails accounts, even Google accounts, you never know.
My client have many support tickets from people mad because they think that his accounts was wiped because was empty.
I try to get the developers find a way to make that the Login With Google button didn't create an account, just check if an account was already created and then login, if not, show a message that an account with this Google account does not exist (like when you put a wrong email in the email/pass form!). But they told me that looking in the Google documentation was not possible (maybe it was).
Now I always try to avoid use third party logins because of that experience.
Of course this is besides the privacy concerns (logged in, Google can track your users) and the dependency problem (if your users Google account is deleted or they lost access, they lost access to the account on your product).
We've implemented a convoluted solution for this where - if the OAuth user does not exist but the OAuth email is in use by a password-based user - the following happens.
1. We prompt user to authenticate with their password.
2. Once successfully authenticated, we link the OAuth auth method to their user to be used in parallel with a password-based login.
Not every Auth provider might support linking multiple Auth methods to a single user, we use Firebase Auth and for us this works fine. We even support multiple OAuth options (FB, Google) and do the same matching between the providers.
My favorite offender: Twitter. On the front page, sign-up is the first, optically more pronounced option with a blue button, while log-in is a considerably light-weighted runner up with a white button. (Which makes sense, since practically no one visiting this obscure service ever considered to create an account. At least, this must be the way of thinking behind this.*) However, when interacting with the site while not logged-in already, it's the other way round, now log-in ist the more prominent blue button and sign-up the white runner-up.
Short version: users are not allowed to learn the ways of the interface, but have to ready themselves to encounter the unknown on every step.
*) This is by far not unique. E.g., Google Adsense makes you search for ways to enter the site, if you are not totally new to the platform. Best practice is apparently to never let pass an opportunity to punish recurring customers. /s
Also 80% of users still don’t use a password manager, which means they’re probably using Password1! on every site.
That's a random figure to preach, but okay. I refuse to use a password manager and nor is my password "Password1!". Each password is different for each system ranging from 7-9 characters.
Do people really struggle to recall their passwords that they need a password manager?
If you only use 2 or 3 systems, probably not. I recall the passwords for my desktop and work laptop easily, even though I change those every few months.
But if we’re talking about passwords on each apps/website, then yes, yes I do struggle to recall those. Especially websites that don’t require me to log in every day, or websites I don’s use on a daily basis.
Thinking of websites I accessed over the weeked, I have a couple of work accounts, a personal email, 3 social media sites and at least three sites where I buy things. That's 9 passwords for sites I use frequently, and there will be a couple of dozen more sites I don't use frequently. No way I can remember that many passwords.
I can recall each one with no problem, no matter how long it's been. Only one password has a close match to any of the others.
I can easily recall the passwords for these that I used frequently. But not the ones I don't use normally.
Validating the input password on the login page should expose exactly the same amount of information as validating it on your signup page.
A remotely-motivated attacker will harvest all the constraints he can from your signup page.
Trying to hide them on the login page buys you nothing.
Author isn’t saying “password = hunter2, guess = hunter3, hint = you got the number wrong”
It’s more like “guess = hunter3, hint = passwords must be at least 10 characters”
You’re not revealing anything about the actual password that you wouldn’t know by reading the password rules on the registration page.
More likely a hashed table gets leaked and they just compare it with existing rainbow tables. Password hints do nothing to protect against that, while inconveniencing your real users.
For a real user trying to guess their password, providing hints (that already match your signup rules) might take them down from 10 wrong guesses to 2 or 3, a huge improvement. For brute-forcing bots, it might take them from 5 years to 4.5 years per password. So what?
If it's another human trying to guess someone's password, again, the requirements are already there in the sign up screen. Also, it's probably easier just to spearphish them with a fake email or try to answer their (not-so) secret questions based on public records and whatnot.
<input type="email" autocomplete="username email" required ...>
and if you also have username:
<input type="username" autocomplete="off" required ...>
I wish to read more about non-password use cases.
Also, fwiw, modern browsers support various form of validations, so maybe these rules should be adapted to reflect that, instead of re-implementing the wheel with client-side js.
<input type="password" placeholder="Enter your password" minlength="8" autocomplete="new-password" required ...>
Username should be 1, password 2, login-button 3.
The common pattern I hate though is when you have the password field focused and switch out of your browser to your password manager to look it up, only to get a jarring message (or worse, a modal popup) admonishing you or having "too few" characters in your password. Seems like some sensible logic could obviate that a bit.
Happened at least once with a large broadband provider in the UK where I was able to sign up with a password but never able to log in due to stricter validation on login!