Don’t Get Clever with Login Forms
41–50 of 520 posts
Re: Don’t Get Clever with Login Forms
#42I 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 PASTIN…
Passwords need to be at least 8 characters in length and must contain at least 3 of the following 4 types of characters: uppercase letter, lowercase letter, number or symbol.
The blocking of copy/paste in particular was irksome, but the whole thing is almost every bad security practice all rolled into one.Re: Don’t Get Clever with Login Forms
#43Earlier quoted context omitted.
It is funny how trends shift. A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead. Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.
So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.
As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is really, really old. A surprising number of breaches come via an email address I was only signing up for accounts on more than six or seven years ago.
Furthermore, most of your accounts don't matter. Things like your email, your bank, your web hosting, need to be secured well. An account you used once to sign up for a newsletter does not. Don't save your credit card info in every single web store you log into, and your security on those accounts don't matter either.
Focus your security and your password uniqueness and complexity on accounts that matter, and stop caring about ones that don't. People have reached security overload after being told all of their accounts must be secured, and then offloaded the problem to a bad solution.
Re: Don’t Get Clever with Login Forms
#44Re: Don’t Get Clever with Login Forms
#45Earlier 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.
https://security.stackexchange.com/questions/158075/is-it-un...
Re: Don’t Get Clever with Login Forms
#46There'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.
>Password managers can't deal with this, unsurprisingly. I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager? In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browse…
Re: Don’t Get Clever with Login Forms
#47There'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…
Pisses me off too
Re: Don’t Get Clever with Login Forms
#48My 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…
My biggest one is... Requiring users to login with a username or customer id. (instead of email).
Re: Don’t Get Clever with Login Forms
#49Imo 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.
Re: Don’t Get Clever with Login Forms
#50The background to the modal gives the context to 'where the login is happening'.
If there is no context then it can have it's own screen.
The absolute worst is when you're doing a bunch of stuff, you login, and the app does not forward you on to 'that thing' you were trying to do, rather, you just get to the home page after login and have to re-search etc..