Earlier quoted context omitted.
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.
Don’t Get Clever with Login Forms
151–160 of 520 posts
Re: Don’t Get Clever with Login Forms
#152Earlier quoted context omitted.
What's the benefit of doing it that way?
He gets to have the added insecurity if putting it on his clipboard for other programs to see on the way by. /s I actually can't imagine how it could be safer than having the password manager do it directly.
Re: Don’t Get Clever with Login Forms
#153Earlier quoted context omitted.
> 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Óöð
Or god forbid you try and use a non-English password... Unicode exists for a reason.
Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
Re: Don’t Get Clever with Login Forms
#154My 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).
There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
Re: Don’t Get Clever with Login Forms
#155There'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.
The few times I've seen this (Google and Amazon I think), my password manager (Lastpass) has had no problem, but I've run into several sites where simple two input and a button login forms don't autofill correctly. Usually the username field will get cleared when the password gets autofilled, so I have to manually paste the username. I wish password managers would become popular with non-tech people already. I can't…
It doesn’t do well with banks that think they are being clever though.
Re: Don’t Get Clever with Login Forms
#156Earlier quoted context omitted.
It's actually even worse than that: they keys on the virtual keyboard are displayed in a random order instead of QWERTY.
Well, that's better though. So even if there's a key logger and mouse click recorder on your machine, one cannot recover your password. Though, if your machine is that compromised, might as well have a screen recorder, too. Though that would create more outgoing traffic.
this technique is actually good if implemented correctly -- with secure display where the host OS cannot read the image data. some predecessor to SGX whose name I don't recall had this feature. the idea is to enter a PIN though, not a friggin password.
treasurydirect seems to have only taken away the trivial aspect of it without understanding the underlying reasons and details. you know, like what most companies do with Agile.
Re: Don’t Get Clever with Login Forms
#157> don’t put logins in modals LastPass fills out my username and password on modals just fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no? Why should a site bother with a slower page load when an instant modal works just fine, as long as it's properly implemented? > don’t split login across multiple pages I've never seen this done except when it's necessary be…
Re: Don’t Get Clever with Login Forms
#158> don’t put logins in modals LastPass fills out my username and password on modals just fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no? Why should a site bother with a slower page load when an instant modal works just fine, as long as it's properly implemented? > don’t split login across multiple pages I've never seen this done except when it's necessary be…
>I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.
I've actually noticed this becoming more common and I find it super annoying when there's no obvious need for it. Even Google does this now:
Re: Don’t Get Clever with Login Forms
#159Earlier quoted context omitted.
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
#160Earlier quoted context omitted.
Lots of dev tools do this with github, too. The idea of a web-wide sso is a bad one.
I don't think that's true, it's just never been implemented in a way that wasn't bad. You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.
My traveler self hates the idea, because I can't read my emails from my friend's phone when my phone is broken during our 6 month trek.