Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

1–10 of 520 posts

Re: Don’t Get Clever with Login Forms

#3

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.

I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.

Re: Don’t Get Clever with Login Forms

#4

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

Twilio does this and LastPass can work with it if you type your email address in the first screen, it will fill the password.

Re: Don’t Get Clever with Login Forms

#5

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in friction.

Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.

Re: Don’t Get Clever with Login Forms

#6

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password. I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had…

Yeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.

Re: Don’t Get Clever with Login Forms

#8
I would go further than this: don't get clever with logging in. Here's a list of "don't"s:

- DON'T arbitrarily restrict my password from being too long

- DON'T arbitrarily restrict me from using special characters

- DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/)

- (this is a big one) DON'T TRY AND STOP ME PASTING MY PASSWORD. I can't tell you how infuriating this is.

Login forms aren't hard yet the desire to "add value" with little restrictions and tweaks (because security) is maddening.

Re: Don’t Get Clever with Login Forms

#9

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in f…

Is there no longer a panic over letting an attacker know that an account does exist?

I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.

Re: Don’t Get Clever with Login Forms

#10

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in f…

That's a security failing - you shouldn't let the website user know that a given account exists.

The right way to do this is have a log in form (one or two pages - doesn't matter) and a separate create account form. You can try to log into a non-existant account, which will fail in exactly the same way as a wrong password. You can try to create an already existing account, which will result in exactly the same behaviour to the webpage user as creating a non-existing account - a page saying "An email has been sent to the email address ".

Post reply on HN