Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

21–30 of 520 posts

Re: Don’t Get Clever with Login Forms

#21
post #12

Could web developers and password manager developers get together and develop a standard web API for authenticating with a website? I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.

Ditto for a standard API for updates. That way you could have your password manager automatically rotate your password, either on a schedule or in response to a known breach. Hell we should have an API or machine readable stream for breaches too.

Re: Don’t Get Clever with Login Forms

#23
post #12

Could web developers and password manager developers get together and develop a standard web API for authenticating with a website? I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.

There was this HN post a bit ago:

Relevant Link: https://wicg.github.io/change-password-url/index.html

HN comments: https://news.ycombinator.com/item?id=18618193

Re: Don’t Get Clever with Login Forms

#25
post #9

Earlier quoted context omitted.

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.

I haven't heard an update on that front for many years, so I'd assume it should still be a concern.

Many of the same sites that do this will also have a recovery form that refuses to leak information.

Re: Don’t Get Clever with Login Forms

#26
post #9

Earlier quoted context omitted.

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.

It's still a concern, but often forgotten.

Re: Don’t Get Clever with Login Forms

#27
post #20

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.

1Password handles this just fine. You just have to hit the button twice.

Sure, but it's definitely YMMV.

Re: Don’t Get Clever with Login Forms

#28
post #20

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.

1Password handles this just fine. You just have to hit the button twice.

Came here to say the same. This absolutely works with 1Password, even if you have multiple accounts for a single site (eg Google, or multiple test accounts for a site you run).

Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.

Re: Don’t Get Clever with Login Forms

#29

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.

If your platform supports 2FA, differing authentication mechanisms, or really anything that can make one accounts login process different to another, splitting it into 2 steps allows you to request the user ID first, then show the appropriate auth form for the second step.

I agree you can achieve this by other means, but services may have their own reasons for doing it this way.

Post reply on HN