Tips for Better Signup / Login UX(learnui.design)
learnui.design
Tips for Better Signup / Login UX
https://learnui.design/blog/tips-signup-login-ux.html
132 comments
This is a nice list, but it misses one of the most important features in my opinion: Allow users to paste username/password. This seems like such an obvious thing, and it's also the default behavior. But for some inexplicable reason, some product managers seem to be under the assumption that disallowing pasting of passwords enhances security. This is obviously false, and will just lead to your users choosing worse passwords.
And make it possible to have password managers auto-type the username and password. Some sites don't focus the password field after the username field and so the "username -> tab -> password -> enter" auto-typing breaks.
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.
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.
KeepassXC lets you specify a custom key/field sequence for each site, which makes it a little less painful.
Thanks for the info, didn't know that! I'm actually using KeePassXC.
and label the fields properly so that password managers know where to put the things. Strange how many login forms don't do this.
i agree with this. many sites these days have 2FA/OTP in the login flow and they that box is marked as password, and everytime the browser asks "do you want to update your password?" maha irritating experience.
My #1 biggest pet peeve with the web right now is that nobody labels their form fields either correctly or at all, for any kind of field. And more generally just doing tons of stupid garbage that obviously breaks browsers.
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.
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.
This is also hostile to accessibility.
This should be more like "don't prevent users from pasting into password fields" because, sadly, this is genius management doing
One thing that I have seen as a trend on some websites that I hate is when they first show you the Email field, and you have to press next, and then they ask you for the password.
That is done by evernote IIRC. Why? Just show me both fields.
That is done by evernote IIRC. Why? Just show me both fields.
Shout out to the "Don't Fuck With Paste" browser extension, which allows disabling this user-hostile behavior in a site-by-site basis.
I run a company offering form analytics [0] so I have seen plenty of real data on how people use forms. One stupid issue I've seen over and over again is a lack of trimming of email/username/password strings, say:
'[email protected] '
resulting in errors like 'invalid email'. Since whitespaces are invisible to users, they can't figure out what's wrong.
[0] https://www.useitbetter.com/features/form-analytics/
'[email protected] '
resulting in errors like 'invalid email'. Since whitespaces are invisible to users, they can't figure out what's wrong.
[0] https://www.useitbetter.com/features/form-analytics/
One thing I read (and checked, this was in the past) Facebook did was even do simple white stripping on passwords, as well as checking with caps-lock switched on.
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.
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.
See "pASSWORD tYPOS and How to Correct Them Securely" by Dropbox: https://ieeexplore.ieee.org/abstract/document/7546536
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.
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.
Wouldn't that interfere with a password manager that auto-saves?
no
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.
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.
>> "PaSSWord123" "pAsswORD123"
Wow - non-case-sensitive passwords seem like a bad idea...
Wow - non-case-sensitive passwords seem like a bad idea...
Not it's still case sensitive, you can just flip all the character's case. You are only losing "one bit" of password information.
> it's still case sensitive, you can just flip all the character's case.
How is "flipping all the character's case" different from case-insensitive?
How is "flipping all the character's case" different from case-insensitive?
They flip all character's case in one go, and also capitalise just the first character.
So, if your password was:
fishCAT
They would accept fishCAT, and also FISHcat and FishCAT, and that's it.
So, if your password was:
fishCAT
They would accept fishCAT, and also FISHcat and FishCAT, and that's it.
Pretty sure they don't do that for authentication.
They do, you can see a discussion here: https://security.stackexchange.com/questions/68013/facebook-...
I didn't know it's still possible for Facebook to disappoint me.
A couple more:
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#@!+&$
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#@!+&$
Also, don't restrict allowed characters unnecessarily. It's just stupid to have "Use special characters, but only !$() and _ are allowed!". God, why?
Also, do restrict allowed characters when necessary. If one of your apps doesn't allow me to input a particular special character in the password field, don't allow me to have that character in my password.
What kind of situation occurs where you can't input special characters in a password field?
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 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.
There's one restriction you should do, trim spaces from the start and end of a password (or any input field, for that matter, unless there's a good reason not to). People copy/pasting from emails or Word documents are good at accidentally picking up spaces.
Sometimes the device you're logging in with doesn't have the full range of character sets available. This has happened to me with set-top boxes in the past.
In some cases it's laziness, but in some cases it's because you're looking at the frontend to a legacy system. Especially if it's a bank or other finance site, there is a good chance it fronts a system from the 70s that can only take 8 character passwords and special characters blow it up.
Oracle allows (not sure if still true) alphanumerics and _, $, and #, and some websites just mirrored those rules. Oh and by alphanumerics I'm not even sure that includes anything outside of 7-bit ASCII.
I’ve always assumed this was a reserved character escaping issue that a dev didn’t want to tackle.
PCI DSS compliance is shit at this. Enforced 90 day cycles, mixed casing, alpha, numeric, and "special" characters. The only halfway sane policies they enforce are must not match username, and mustn't be a dictionary word (singular), and minimum length of 7.
Push back on PCI DSS by showing you’re NIST compliant, which is generally considered higher grade and acceptable.
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
https://pages.nist.gov/800-63-3/sp800-63b.html
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
https://pages.nist.gov/800-63-3/sp800-63b.html
That's not a bad list and for regulatory purposes maybe it makes sense to use it, but it has its own limitations.
- 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.
- 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.
Apparently doesn’t mean secure.
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
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
The question isn't whether it's secure. Complete security is a work of fiction anyway. The real question is whether it's significantly more secure.
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.
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.
Simple solution: have a password but allow your users to login via TOTP only.
1) Do not limit the length of the password to some arbitrarily small number.
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.
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.
I at least need a reminder of what your specific special character and length requirements on the login page.
> Do not validate email
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.
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.
There was a django security issue where password length lead to a possible DOS attack against the server. So now they limit passwords rather arbitrarily to 4096 bytes.
https://www.djangoproject.com/weblog/2013/sep/15/security/
https://www.djangoproject.com/weblog/2013/sep/15/security/
To expand on 3), if you really need it, make sure your rule works with Chrome/Safari autogenerated passwords.
> "includes an @ and a period ...
Periods are not required, either!
Periods are not required, either!
3) obligatory xkcd https://xkcd.com/936/
That's one of the worst comics they have. Even though they might be correct with the theoretical entropy, but I doubt that Tr0ub4dor&3 is much easier to crack than correcthorsebatterystaple since dictionary attacks exist. Why not make it long AND hard (h3h3h3h3^_^xD)? Password managers are easy to use and very comfortable. If you want to go further get a Yubikey. I love keepassxc
I don't think correcthorsebatterystaple is easier to crack than the Troubador variation. Hash cracking often includes the use of a wordlist and a ruleset which builds variations on the words from a wordlist. Some common ones I use for my job are
OneRule and Hob0Rules. Notably I did run the word "troubador" through these and did not get the final result of "Tr0ub4dor&3" but they did both produce "Tr0ub4dor". These rulesets both produce > 50k passwords from a single word to guess so it's not outside the realm of possibility to have more/better rulesets that are used.
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
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
Better, dont use passwords at all.
As a counterpoint here, email- or sms-based passwordless flows can be quite slow to complete. We (clerk.dev) are seeing ~35 seconds for passwordless, ~8 for passwords, ~5 for Social Sign In:
https://www.clerk.dev/blog/designing-fast-sign-in-forms
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.
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.
> Every single labelled text input you ever create should have clickable labels. It’s a wonder this isn’t done by HTML by default
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.
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.
> If this was a best practice, it would be baked into the browser.
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.
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.
Password managers are already aware of confirm password fields. There's even an autocomplete attribute to annotate them (use autocomplete="new-password" twice).
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.
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.
> On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop.
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.
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.
There are so many fails when it comes to signup/password change/logon UI that I’ve become acutely aware of after sitting next to an elderly couple trying to implement 1password.
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”.
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”.
This is actually a pretty decent list.
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.
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 don't think the bulletpoint list of requirements is that relevant anymore; instead, I'd give a live updating password strength indicator and reject anything "weak" or "medium". That way, the user can themselves decide on symbols and letters or length. A check on commonly used passwords should also be included of course.
Well I think if you have such rules in place you should always indicate what rules are not satisfied by a password- and not only after hitting submit!
Agreed. And even if you're only going to judge the strength, at least show what the user can continue to do or has already done to strengthen their password.
I wrote documentation for software that replaced set rules with a library that would determine the 'strength' of a password and only accept strong passwords. My feedback was 'this is bullshit, I've have 40 passwords rejected and I don't know why. How is the non-technical user supposed to pick a password when the rules and tests are secret and the doc person themselves can't use it?'
My nomination - when someone has been invited by email to join the site (e.g in a saas system, one user invites someone else to join their team), then don't make them verify their email!
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.
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.
Ehhhh, that may not be the email address that the invited user prefers to use (or may not even know what email it was).
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.
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.
In my experience, most companies want it the other way - they don't want you to be able to choose e.g. a personal email address.
I'll admit I'm not familiar with the sort of email system you are talking about, nor the benefits it might provide.
I'll admit I'm not familiar with the sort of email system you are talking about, nor the benefits it might provide.
> My nomination - when someone has been invited by email to join the site (e.g in a saas system, one user invites someone else to join their team), then don't make them verify their email!
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.
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.
That's a good point.
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).
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).
Hmm, but what if I generated a signup email in your name and signed you up for something you didn't want. Seems like a good way to enable harassment and spam.
It's not a spam vector, as you can't control the content.
No different from any other signup email in that sense.
No different from any other signup email in that sense.
> It's not a spam vector
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.
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.
Tip from me: If the user tries to visit a specific URL and they have to log in first, redirect the user back to the original URL once they've logged in instead of sending them to some generic account page. It's super annoying and disorientating otherwise.
Oh I worked at a company where the primary B2B website was like that. The login had been created in PHP by some folks who were really good at the relatively complex business domain, but thought "just throw a login screen up" was good enough security. For services where the customers spend hundreds of thousands of dollars. There were a handful of predetermined landing pages, depending on what "type" of user you were, and deep linking generally didn't work.
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.
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.
Just be careful where you redirect the user to. Redirects without validating the destination may be used for malicious purposes.
Ideally the site should store the destination in something like redis or memcached and hand the browser an endpoint with an opaque token for the redirect. After login the endpoint gets the token, looks up the actual destination, and does a final redirect. The bonus to this method is that the site can store more than just the destination, but keep useful state, as long as that state is safe across authentication boundaries.
"2. Use specialized mobile keyboards" is a bit confusing. Should be type=email of course for email, which should by default sort out "3. Validate fields immediately"
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.
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.
> 7. Use different terms for “sign in” and “sign up”
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.
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.
It would be really good to see RFC 5233 local-part filtering characters (e.g. '+') being permitted in the validation for email addresses on this list. It's much less of a problem these days, but the number of times a sign up form has flat out refused to accept these as valid - or worse the sign up process accepted it, but the login simply doesn't work!
Many of these sites, such as your bank, or telco, if you talk to a human using a terminal screen, the human can type in the + symbol for you.
> Note: also applies to telephone numbers (type=tel), URLs (type=url), and numbers (type=num) in your signup flow
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.
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.
I've had terrible results with using an <input type='date' ... /> for choosing the birth date of users on a registration form. iOS would make this awesome control where I could scroll and choose the date in a nice way, but on Android, the control was just horrible and we kept getting complaints.
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.
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.
You mean the horribly imprecise date wheel of doom thing? https://i.stack.imgur.com/ms5tX.png
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.
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.
No idea to be honest. I rather like it as an iOS user and our iOS users never - and I do mean 0 times - complained, while our ticketing system was full of Android users complaining about picking their birthday.
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).
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).
What's so weird about that is that Android HAS that control. I was making an app for myself recently, and I needed a datepicker too, and I found a widget that is an exact replica of the iOS "spinners".
Does anyone know why certain sites e.g. Amazon, split their username and password forms into two differe pages. It makes it a bit more annoying to use something like KeePass.
It handles cases where Single Sign On is supported. User enters their email and then is redirected to their company’s login provider to complete the login.
The other 2 comments are true and for another:
The reason we do it, is to show the MFA textbox, if and only if they have MFA setup.
The reason we do it, is to show the MFA textbox, if and only if they have MFA setup.
So they can show a sign up form in case there is no account for the given email
> 1. Autofocus on the first field
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...
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...
No, it isn't for the users to decide, if they are already on a login page they will fill the login field first in nearly all cases.
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.
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.
On the other hand, it's always just a hit of the tab-key away.
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.
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.
Accessibility as a legal or moral requirement doesn't mean that anything that someone imagines could be better on some utterly broken screenreader needs to be implemented. I'm sick of this neverending "but broken screenreaders" song. The legal requirement is fulfilled when the page has proper semantic markup, is standards compliant and fulfills the usual non-syntactic stuff like "each img with alt text". Morally I also do not feel obligated to support any old and broken crap, same as I don't support IE.
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.
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.
12. Get rid of it. Just automatically create an account and let me attach it to an email later if it's something I care about.
On 11.: also prevent leaking the account’s existence when someone requests a password reset. Otherwise it’s a great way of finding out who has accounts where if you know their email. Use the same text as receipt to the user after form submission.
You can, and probably should, go one step further and serve the same HTTP-response (size in bytes and response time) as well.
You can, and probably should, go one step further and serve the same HTTP-response (size in bytes and response time) as well.
#9 in particular. One would think that after a week or two of dealing with all the problems related to a username (having to be unique across all users, having to have a forgot username form, etc.), one would realize the value in a naturally unique and easy to understand value like an email address. But in spite of this, the use of usernames abound.
I don't want to be forced to give an email to every website out there. Give me the option of making my login name whatever I want it. See, for example, HN.
I don't see the HN example. It has my email address. The only sites/apps/services that would apply here are those that could get by with zero ability to communicate with you outside the site. For instance, if they don't have either your phone or your email, how would you reset your password? How would your identity be verified, assuming other parts of your identity mattered. There may be a use case for what you're saying, but it seems like an extreme corner case.
On "3. Validate fields immediately", please do not tell me "Uh oh - this email address looks wrong".
I am 35, not 8. Just say "This is not a valid email address".
I am 35, not 8. Just say "This is not a valid email address".
He points out that this should probably be done on blur which means after you’ve left that input it’ll validate. This is much better than waiting until you submit.
#10, If the user guesses an invalid password, say why it’s invalid.
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.
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.
I've always wondered why there is even a distinction between Log in and Sign up at all. Surely if the user is logging in with their email address, the app can decide whether they're new or existing? What benefit does splitting it into two identical-looking forms provide?
Depends how you handle existing users.
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.
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.
> bots with targeted email could scan for site accounts
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.
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.
Existing users could end up accidentally creating a new account?
That said, fast.co does this to streamline their flows.
That said, fast.co does this to streamline their flows.
> 11. The “reset password” screen should remember which email you already entered
I really wish this one would catch on, it's such an obvious and easy feature
I really wish this one would catch on, it's such an obvious and easy feature
Except for a couple of things. One it assumes that the email used for login and the actual user's email are identical, which isn't always true, and two, if a user mistypes their email and doesn't realize it, then hitting "reset password" will send email to the wrong address.
While that's true. If the email is wrong, password reset isn't going to work for them anyways right? So may as well fix it for the majority of users who do know their email and typed it correctly but forgot their password. Usually even a "sorry that email address is not found" message is frowned upon in terms of security.
Also if you're app is sending reset passwords emails to emails that don't exist, that's a bigger issue.
Also if you're app is sending reset passwords emails to emails that don't exist, that's a bigger issue.
Here is one more:
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.
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.
Not mentioned on the article but present on the screenshots are the Login/Sign Up with Google buttons.
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).
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).
This.
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.
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.
I honestly don’t care much for the signup/login page, I only have one must to have requirement : keep it simple and make password managers work, please !!!!
Also, be consistent with log-in vs sig-up.
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
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
Do password requirements even matter? I get having a minimum length, but many sites still require specific characters to be present.
Not really. Length is the most important thing, and forcing capitals and weird characters and numbers is much harder to remember than a 12 letter lowercase passphrase.
Also 80% of users still don’t use a password manager, which means they’re probably using Password1! on every site.
Also 80% of users still don’t use a password manager, which means they’re probably using Password1! on every site.
My company also enforces some pretty strict rules; no repeating combinations, or things like “1234” or “abcd”. I suspect most people now have to write down their passwords, making it less safe.
> 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?
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?
I have over 100 documented accounts between work, personal, and shared with my family. There is absolutely no way I am going to be able to manage all of those in my head forever.
I can easily recall the passwords for these that I used frequently. But not the ones I don't use normally.
I can easily recall the passwords for these that I used frequently. But not the ones I don't use normally.
> 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.
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.
How many passwords do you have?
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.
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.
Interesting. I have around eight. Work laptop decryption password, Work Email, Work VPN, SSH Key Cert Password,Personal Email, HN, Reddit, bank card and then a generic password for other trash which I don't really care if gets leaked. The passwords contain special characters too.
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 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 suppose if you don't have PayPal, Amazon, eBay, or any other online shop that would be ok -- but I wouldn't call any of those "trash", as they often remember my banking details, or at least have my purchase history + address, which I'd prefer not leaking.
Be sure to use the appropriate autocomplete attributes to help password managers https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
About "10. If the user guesses an invalid password, say why it’s invalid", it's terrible from a security perspective.
If the password is wrong, it is wrong. A potential attacker must have no clue of what he guessed.
I think the intention is to impose the same restrictions on the "login" password field as on the "sign in" password field. This gives a hint to users as to why their entered password is incorrect, and does not slow down an attacker. This is particularly important for systems with unusually restrictive password fields.
I think that suggestion is purely UX upside with no additional security risk.
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.
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.
If someone is going to naively brute-force your login screen, it's safe to assume they're going to look at the sign-up password requirements anyway. Nobody is just going to throw the whole unicode character set at your password field and go from 1 to infinity characters in order to guess your passwords.
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.
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.
I think there might be a misunderstanding here.
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.
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.
Cool list, my fav is "9. Log in with email, not username", that can be achieved with:
<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 ...>
<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 ...>
I thought that was a pretty good list apart from the missing "Allow users to paste their username/password into a field".
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.
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.
Another one, ensure the password validation on sign up and login are the same.
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!
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!
The more annoying your sign up process is for me to access your website, the more vulgar I make the fake email for your database.
Technically, email addresses don't need a ".", apparently you can have MX records on a TLD.