Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

51–60 of 520 posts

Re: Don’t Get Clever with Login Forms

#51

Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

One way I've seen sites mess this up is when they allow me to sign up using a Google account on my Android phone, but don't offer Google login on their web page. Makes for very confusing UX!

Re: Don’t Get Clever with Login Forms

#52

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…

Yes, splitting up auth flow allows you to query auth requirements, query apis for risk/security and more

Re: Don’t Get Clever with Login Forms

#53
post #10

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…

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 behavi…

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

It's not an issue if you let users pick their own username. There's simply no way to get around this (apart from assigning usernames). In other cases, usernames being publicly available is a desired feature.

[0] https://imgur.com/a/qCupYyQ

Re: Don’t Get Clever with Login Forms

#54
post #22

I agree with a lot of this but magic links are great and I love them. Don't take away my magic login emails.

I too like the magic links. I've been an advocate for them in our tech stack ever since the first one I used on Slack. Yes, it's a paradigm shift, but I don't think that's a reason to avoid using it.

My team is split on whether or not they are a good thing, but the main reason people usually give against magic links are it's too cumbersome to go find it in your email. Am I the only one who always has email open?

From an implementation standpoint has anyone seen a negative consequence of using magic links? I know password resets are always a portion of our customer service handling – is there an equivalent with magic links?

Re: Don’t Get Clever with Login Forms

#55
Here's another one - DON'T disable the submit button if the fields are empty since some native password managers like Chrome iOS will render as if they've filled the fields, but only provide the values on the user's first interaction on the page. A simple form doesn't have an issue with that.

Re: Don’t Get Clever with Login Forms

#57
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.

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

There's simply no way to get around this if users can pick their own usernames (other than assigning them in an unpredictable manner). In other cases, usernames being publicly available is a feature, not a bug.

[0] https://imgur.com/a/qCupYyQ

Re: Don’t Get Clever with Login Forms

#58
post #11

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. 3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code 4. If you login to any 3rd…

> 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code.

I can't tell you how many sites won't allow passwords with quotes, apostrophes, or colons. (too concerned about SQL injection, are we?) And too many don't like high ASCII characters in passwords; no one's going to guess something like úú©íWq¿S®&ßþDx¼åi4ÒÀÛ'ÓªýS.¾¥ùìbÓöð

Re: Don’t Get Clever with Login Forms

#59

Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

It's convenient at signup and every login, and with a company Google Apps account, especially convenient when a person joins or leaves!
Post reply on HN