3 ms·

I'd love best practices around, say, login forms, e.g.: - use standard input field names password managers recognize - disable autocompletion and autocapitaliz

by fmajid 5mo ago

I'd love best practices around, say, login forms, e.g.: - use standard input field names password managers recognize - disable autocompletion and autocapitalization on the login field - if it's an email, use the correct HTML5 input type - don't have a form with just a login email and force the user to click to enter the password - follow NIST SP 800-53, e.g. no SMS 2FA and no arbitrary password rotation and composition rules Or how many sites that have a form with only one input don't automatically focus on it.

notpushkin 5mo ago
Evil Martians have a nice write-up on the login forms: https://evilmartians.com/chronicles/html-best-practices-for-login-and-signup-forms https://evilmartians.com/chronicles/html-best-practices-for-...
quirino 5mo ago
I've had good fun reading about best practices for forms in Adam Silver's blog. https://adamsilver.io/blog/form-design-from-zero-to-hero-all-in-one-blog-post/ https://adamsilver.io/blog/form-design-from-zero-to-hero-all... He has posted many new things since. Probably one of the best UX resources on the web.
xg15 5mo ago
> don't have a form with just a login email and force the user to click to enter the password I was noticing that this kind of login forms seems to be proliferating, especially on "big tech" sites. (And personally, I also find it annoying) Always assumed there was some reason why sites are switching to this pattern, e.g. better bot protection. Does anyone know more about this?
- jurf 5mo ago
  I always assumed it was because of SSO redirects
- mpetrovich 5mo ago
  I suspect they ask for email first in order to determine whether to log you in via SSO vs. require a password.
  - xg15 5mo ago
    Ah, that would make sense.
  - 9dev 5mo ago
    As someone who's built just that, can confirm. If users have SSO configured, or a Passkey, or any other policies apply, you first need to identify the account to be able to determine which options to offer - maybe they don't even have a password in the first place, so displaying the field would cause confusion. As a side effect, this also conveniently allows to check for blocked accounts.
  - johannes1234321 5mo ago
    I think it started with somebody like Yahoo!, who said that they that way could show your profile image or something and thus verify to you that this isn't a scam phishing site. I don't remember the complete argument, though. But yeah, nowadays it's mostly SSO, I assume. Which is still annoying as on the SSO site I have to enter my mail address again (or rather: have my password manager doing it ;) ), which is an inconvenience and where I wonder how much of that is to collect data about companies where employees would like to use the service for having sales reaching out. In many places (like Slack or Zoom) company is picked by domain name (yourcompany.slack.com etc.) and then leading to the right SSO.
xg15 5mo ago
> Or how many sites that have a form with only one input don't automatically focus on it. That's one example where the "web stack" expects every single website to implement things manually that were standard in native UI toolkits. Then of course the majority of websites will not deem it a priority or not realize it's a thing to consider at all - and we end up in a situation like this.
singpolyma3 5mo ago
> don't have a form with just a login email and force the user to click to enter the password This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.
- qup 5mo ago
  So what if we don't know? We can find out at the same time. We're trying to authenticate a pair: user/pass.
  - extra88 5mo ago
    There is no pair for the enterprise users signing in with their company's SSO or those using Passkey. I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.
    - luckylion 5mo ago
      Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?
      - extra88 5mo ago
        How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.
        8organicbits 5mo ago
        If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist. Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts. It's very low on my list of concerns though, usually there's much worse problems when I pentest.
extra88 5mo ago
> many sites that have a form with only one input don't automatically focus on it. That's reasonable to do when that form is the reason a page exists but otherwise it's best to not mess with the user's focus.
Pay08 5mo ago
> use standard input field names password managers recognize - disable autocompletion and autocapitalization on the login field Alternatively, have different predefined types of input fields, like they already do with accepted inputs.
culi 5mo ago
I've used frontendchecklist for a few years now and it has a collection of rules and best practices kinda like this. Unforunately it seems the website has recently been updated to embrace "ai-readiness". But the rules are still there https://frontendchecklist.io/rules/html/input-types https://frontendchecklist.io/rules/html/input-types When I build UI components from scratch I really like this site: https://component.gallery/ https://component.gallery/ It links to components across many different design systems. Many of these design systems include in-depth accessibility, i18n, etc guidelines. Some standouts in terms of documentation are Salesforce's Lightning Designs System and StackOverflow's Stacks https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-carousel/b/74d5d4 https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car... https://stackoverflow.design/system/forms/checkbox https://stackoverflow.design/system/forms/checkbox
Vinnl 5mo ago
> - don't have a form with just a login email and force the user to click to enter the password That can be valid, but often it will also cause screen reader users to miss context.

by fmajid 5mo ago

notpushkin 5mo ago

Evil Martians have a nice write-up on the login forms: https://evilmartians.com/chronicles/html-best-practices-for-login-and-signup-forms https://evilmartians.com/chronicles/html-best-practices-for-...

quirino 5mo ago

I've had good fun reading about best practices for forms in Adam Silver's blog. https://adamsilver.io/blog/form-design-from-zero-to-hero-all-in-one-blog-post/ https://adamsilver.io/blog/form-design-from-zero-to-hero-all... He has posted many new things since. Probably one of the best UX resources on the web.

xg15 5mo ago

> don't have a form with just a login email and force the user to click to enter the password I was noticing that this kind of login forms seems to be proliferating, especially on "big tech" sites. (And personally, I also find it annoying) Always assumed there was some reason why sites are switching to this pattern, e.g. better bot protection. Does anyone know more about this?

jurf 5mo ago
I always assumed it was because of SSO redirects
mpetrovich 5mo ago
I suspect they ask for email first in order to determine whether to log you in via SSO vs. require a password.
- xg15 5mo ago
  Ah, that would make sense.
- 9dev 5mo ago
  As someone who's built just that, can confirm. If users have SSO configured, or a Passkey, or any other policies apply, you first need to identify the account to be able to determine which options to offer - maybe they don't even have a password in the first place, so displaying the field would cause confusion. As a side effect, this also conveniently allows to check for blocked accounts.
- johannes1234321 5mo ago
  I think it started with somebody like Yahoo!, who said that they that way could show your profile image or something and thus verify to you that this isn't a scam phishing site. I don't remember the complete argument, though. But yeah, nowadays it's mostly SSO, I assume. Which is still annoying as on the SSO site I have to enter my mail address again (or rather: have my password manager doing it ;) ), which is an inconvenience and where I wonder how much of that is to collect data about companies where employees would like to use the service for having sales reaching out. In many places (like Slack or Zoom) company is picked by domain name (yourcompany.slack.com etc.) and then leading to the right SSO.

xg15 5mo ago

> Or how many sites that have a form with only one input don't automatically focus on it. That's one example where the "web stack" expects every single website to implement things manually that were standard in native UI toolkits. Then of course the majority of websites will not deem it a priority or not realize it's a thing to consider at all - and we end up in a situation like this.

singpolyma3 5mo ago

> don't have a form with just a login email and force the user to click to enter the password This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.

qup 5mo ago
So what if we don't know? We can find out at the same time. We're trying to authenticate a pair: user/pass.
- extra88 5mo ago
  There is no pair for the enterprise users signing in with their company's SSO or those using Passkey. I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.
  - luckylion 5mo ago
    Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?
    - extra88 5mo ago
      How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.
      - 8organicbits 5mo ago
        If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist. Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts. It's very low on my list of concerns though, usually there's much worse problems when I pentest.

extra88 5mo ago

> many sites that have a form with only one input don't automatically focus on it. That's reasonable to do when that form is the reason a page exists but otherwise it's best to not mess with the user's focus.

Pay08 5mo ago

> use standard input field names password managers recognize - disable autocompletion and autocapitalization on the login field Alternatively, have different predefined types of input fields, like they already do with accepted inputs.

culi 5mo ago

I've used frontendchecklist for a few years now and it has a collection of rules and best practices kinda like this. Unforunately it seems the website has recently been updated to embrace "ai-readiness". But the rules are still there https://frontendchecklist.io/rules/html/input-types https://frontendchecklist.io/rules/html/input-types When I build UI components from scratch I really like this site: https://component.gallery/ https://component.gallery/ It links to components across many different design systems. Many of these design systems include in-depth accessibility, i18n, etc guidelines. Some standouts in terms of documentation are Salesforce's Lightning Designs System and StackOverflow's Stacks https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-carousel/b/74d5d4 https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car... https://stackoverflow.design/system/forms/checkbox https://stackoverflow.design/system/forms/checkbox

Vinnl 5mo ago

> - don't have a form with just a login email and force the user to click to enter the password That can be valid, but often it will also cause screen reader users to miss context.