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.
Don’t Get Clever with Login Forms
51–60 of 520 posts
Re: Don’t Get Clever with Login Forms
#52There'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…
Re: Don’t Get Clever with Login Forms
#53Earlier 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…
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.
Re: Don’t Get Clever with Login Forms
#54I agree with a lot of this but magic links are great and I love them. Don't take away my magic login emails.
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
#55Re: Don’t Get Clever with Login Forms
#56Wait, why are password managers terrible? That's not an opinion I see much, can you explain why you say that?
Re: Don’t Get Clever with Login Forms
#57Earlier 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.
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.
Re: Don’t Get Clever with Login Forms
#58My 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…
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
#59Imo 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.