[HN Gopher] Tips for Better Signup / Login UX
___________________________________________________________________
Tips for Better Signup / Login UX
Author : mooreds
Score : 180 points
Date : 2021-06-27 21:05 UTC (1 days ago)
(HTM) web link (learnui.design)
(TXT) w3m dump (learnui.design)
| robertoandred wrote:
| Be sure to use the appropriate autocomplete attributes to help
| password managers https://developer.mozilla.org/en-
| US/docs/Web/HTML/Attributes...
| MeinBlutIstBlau wrote:
| 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.
| abraae wrote:
| 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.
| seanwilson wrote:
| > 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.
| abraae wrote:
| 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).
| cratermoon wrote:
| 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.
| abraae wrote:
| It's not a spam vector, as you can't control the content.
|
| No different from any other signup email in that sense.
| cratermoon wrote:
| > 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.
| sib wrote:
| 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.
| abraae wrote:
| 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.
| ecesena wrote:
| 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 ...>
| bbx wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| verinus wrote:
| 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!
| andrewstuart2 wrote:
| 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.
| masswerk wrote:
| > 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...
| corty wrote:
| 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.
| masswerk wrote:
| 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.
| corty wrote:
| 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.
| fomine3 wrote:
| > 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.
| sakarisson wrote:
| 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.
| alexaholic wrote:
| This should be more like "don't prevent users from pasting into
| password fields" because, sadly, this is genius management
| doing
| marcus_holmes wrote:
| and label the fields properly so that password managers know
| where to put the things. Strange how many login forms don't do
| this.
| tsjq wrote:
| 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.
| plainnoodles wrote:
| 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.
| cratermoon wrote:
| This is also hostile to accessibility.
| mixedCase wrote:
| Shout out to the "Don't Fuck With Paste" browser extension,
| which allows disabling this user-hostile behavior in a site-by-
| site basis.
| dthul wrote:
| 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.
| cbm-vic-20 wrote:
| KeepassXC lets you specify a custom key/field sequence for
| each site, which makes it a little less painful.
| dthul wrote:
| Thanks for the info, didn't know that! I'm actually using
| KeePassXC.
| lbayes wrote:
| 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#@!+&$
| jmilloy wrote:
| I at _least_ need a reminder of what your specific special
| character and length requirements on the login page.
| Jenk wrote:
| 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.
| Terretta wrote:
| 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
| Silhouette wrote:
| 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.
| gjvnq wrote:
| Simple solution: have a password but allow your users to
| login via TOTP only.
| quesera wrote:
| > "includes an @ and a period ...
|
| Periods are not required, either!
| ecesena wrote:
| To expand on 3), if you really need it, make sure your rule
| works with Chrome/Safari autogenerated passwords.
| cnlevy wrote:
| 3) obligatory xkcd https://xkcd.com/936/
| 026bfdf903b15 wrote:
| 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
| dogface01 wrote:
| We must secure the existence of our people and a future for
| white children.
| InitialBP wrote:
| 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
| GrumpyNl wrote:
| Better, dont use passwords at all.
| colinclerk wrote:
| 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.
| shezi wrote:
| 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/
| reaperducer wrote:
| _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.
| cratermoon wrote:
| > 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.
| _0ffh wrote:
| Also, don't restrict allowed characters unnecessarily. It's
| just stupid to have "Use special characters, but only !$() and
| _ are allowed!". God, why?
| daveFNbuck wrote:
| 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.
| InitialBP wrote:
| 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.
| unilynx wrote:
| 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.
| technotarek wrote:
| I've always assumed this was a reserved character escaping
| issue that a dev didn't want to tackle.
| jedberg wrote:
| 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.
| cratermoon wrote:
| 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.
| bastawhiz wrote:
| > 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.
| fomine3 wrote:
| > 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.
| bastawhiz wrote:
| 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.
| fomine3 wrote:
| > 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.
| ipython wrote:
| 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".
| woutr_be wrote:
| Do password requirements even matter? I get having a minimum
| length, but many sites still require specific characters to be
| present.
| pembrook wrote:
| 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.
| doublerabbit wrote:
| > 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?
| CJefferson wrote:
| 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.
| doublerabbit wrote:
| 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.
| CJefferson wrote:
| 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.
| woutr_be wrote:
| > 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.
| Zachery wrote:
| 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.
| woutr_be wrote:
| 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.
| corty wrote:
| In addition to the autofocus: Use tabindex!
|
| Username should be 1, password 2, login-button 3.
| rhizome wrote:
| And _only_ those. I 've seen a lot of tabs land on form field
| labels.
| superasn wrote:
| > 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.
| ThalesX wrote:
| 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.
| unknown_error wrote:
| 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.
| bussierem wrote:
| 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".
| adamdoran wrote:
| 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!
| Terretta wrote:
| 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.
| idownvoted wrote:
| Nice List!
|
| I'd add: "Use browser-native autocomplete features for both
| 'email' and 'password'"
|
| Also you can go pretty wild with a sign-up form's password field
| validation, because you may want to indicate to the user:
|
| - how strong his PW is
|
| - what seperate requirements are currently fulfilled (e.g. 1
| number: yes, 1 special character: no, ...)
|
| - if he needs to pass all requirements or not (and if not: how
| many he still needs to fulfill)
|
| - if his password contains strings from other input fields you
| may deem insecure to be part of a PW
|
| - generally more than just an error-state, but also a valid-
| state, or even a warning-state
| eightysixfour wrote:
| Technically, email addresses don't need a ".", apparently you can
| have MX records on a TLD.
| Kiro wrote:
| 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.
| callumprentice wrote:
| 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.
| conductr wrote:
| > 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
| cratermoon wrote:
| 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.
| mbostleman wrote:
| #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.
| cratermoon wrote:
| 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.
| mbostleman wrote:
| 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.
| thomasahle wrote:
| 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.
| leokennis wrote:
| 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".
| dinkleberg wrote:
| 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.
| scaglio wrote:
| 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.
| NateEag wrote:
| 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.
| johnday wrote:
| 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.
| mlex wrote:
| 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.
| unknown_error wrote:
| 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.
| hendry wrote:
| "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.
| henrikwm wrote:
| 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.
| cratermoon wrote:
| #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.
| seanwilson wrote:
| 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.
| cratermoon wrote:
| 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.
| jpalomaki wrote:
| Just be careful where you redirect the user to. Redirects
| without validating the destination may be used for malicious
| purposes.
| cratermoon wrote:
| 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.
| raspyberr wrote:
| 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.
| ec109685 wrote:
| 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.
| zie wrote:
| 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.
| endless1234 wrote:
| So they can show a sign up form in case there is no account for
| the given email
| bttrfl wrote:
| 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:
|
| 'john@doe.com '
|
| 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/
| CJefferson wrote:
| 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.
| mtoddsmith wrote:
| Wouldn't that interfere with a password manager that auto-
| saves?
| shawabawa3 wrote:
| 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.
| sib wrote:
| >> "PaSSWord123" "pAsswORD123"
|
| Wow - non-case-sensitive passwords seem like a bad
| idea...
| CJefferson wrote:
| Not it's still case sensitive, you can just flip all the
| character's case. You are only losing "one bit" of
| password information.
| cratermoon wrote:
| > 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?
| CJefferson wrote:
| 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.
| anoncake wrote:
| Pretty sure they don't do that for authentication.
| CJefferson wrote:
| They do, you can see a discussion here: https://security.
| stackexchange.com/questions/68013/facebook-...
| ecesena wrote:
| 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.
| masswerk wrote:
| 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
| jamescun wrote:
| 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!
| g105b wrote:
| 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?
| ec109685 wrote:
| Existing users could end up accidentally creating a new
| account?
|
| That said, fast.co does this to streamline their flows.
| mhitza wrote:
| 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.
| cratermoon wrote:
| > 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.
| tibiahurried wrote:
| 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 !!!!
___________________________________________________________________
(page generated 2021-06-28 23:03 UTC)