Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

Post reply on HN
Print view View original

221–230 of 520 posts

Re: Don’t Get Clever with Login Forms

#221

Post by hombre_fatal »

gammateam wrote: post #216
colinramsay wrote: post #2

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.

This was my first thought too I saw it on Expensify yesterday Doesn't this break a best practice? If you input an email address it tells you whethere there IS or ISN'T a user, and if there IS it asks you for their password. I thought the best practice was to make it unclear whether an email or username is in the system, which would make this a huge regression

It doesn't change anything. If the email doesn't exist, you can always redirect to the password form.

If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.

Re: Don’t Get Clever with Login Forms

#222

Post by icebraining »

tylerl wrote: post #210
colinramsay wrote: post #2

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.

Actually this is necessary in order to support federated auth. Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.

Yeah, haven't had problems with Firefox's manager either.

Re: Don’t Get Clever with Login Forms

#223

Post by astine »

Is there any technical reason that a password manager cannot be made to work with split logins or hidden fields? Shouldn't they have access to the same web browser that user does? I'd think that could be scripted to handle these things. Obviously this makes it more complex for password managers to auto-enter passwords, different websites will have different scripts but I see no reason for this to be an insurmountable issue.

Re: Don’t Get Clever with Login Forms

#225

Post by icebraining »

FabHK wrote: post #112
jakelazaroff wrote: post #100

Earlier quoted context omitted.

What's the benefit of doing it that way?

Your web browser doesn't have any connection to your password manager. Who knows what your web browser is doing, why would you give it any access to your credentials?

How can you not give your browser your credentials? Do you login on a site using curl and manually copy session cookies?

Re: Don’t Get Clever with Login Forms

#226

Post by 0xCMP »

gruez wrote: post #175
scarejunba wrote: post #162

Earlier quoted context omitted.

That allows federated login. You can federate Google login to Okta etc.

Paypal and iCloud have 2 step logins as well. It doesn't seem likely that they would need to support federated logins.

And yet they most likely do.

Re: Don’t Get Clever with Login Forms

#227

Post by [deleted] »

tylerl wrote: post #210
colinramsay wrote: post #2

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.

Actually this is necessary in order to support federated auth. Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.

[deleted]

Re: Don’t Get Clever with Login Forms

#228

Post by ben_jones »

humblebee wrote: post #198
Apylon777 wrote: post #63

The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords. Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect

> A virtual keyboard, with keys that display in random order, is available to deter others from learning your password. This is a weird way to describe keyloggers if that is actually what they are talking about. The random order I don't understand either unless the "keylogger" is also recording mouse positions. Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effec…

The irony is that if someone managed to install a keylogger, they could've installed any other RATing tool such that the machine itself and everything it touches it completely compromised.

Re: Don’t Get Clever with Login Forms

#229

Post by alanh »

I have seen some sites that only show a username field but nevertheless are compatible with my password manager (1Password). What I suspect is going on is that the password field is present but visually hidden (not missing and probably not with display: none, but perhaps by being placed in an overflow: hidden box with a height of zero or a similar technique).

I haven't confirmed this hunch as to the technique but it seems like a good compromise if there is a good reason to hide the password field initially. And I think there are some such good reasons. For example, if you are Google: Not everyone logs in to Google with a password. I have to log in to my work account using our company's SSO provider, so that Google account has no password. In this case, I shouldn't see a password field, as its presence will be more confusing than helpful. Still, a hidden-but-present password field would allow my password manager to work in the case that my Google account does in fact take a password. (Presumably care should be taken to avoid adding extra confusion to users of assistive technology.)

Re: Don’t Get Clever with Login Forms

#230

Post by fivre »

djsumdog wrote: post #200
jillesvangurp wrote: post #84

It's 2019 and we're still doing email based signups, by default. What's wrong with this industry? OpenId was a pretty neat idea twelve years ago. And given the amount of password databases getting compromised, quite many websites would have been better off federating identity with a competent provider. But no, world plus dog still outsources security to email providers like hotmail, gmail, or worse. Basically comprom…

I recent did a write up on the decline of OpenID: https://penguindreams.org/blog/the-decline-of-openid/ It use to use my own identity provider quite a bit, but every website that use to take OpenID no longer does. OpenID Connect is just a modified OAuth and even fewer website that custom OpenID Connect. Stackoverflow dropping it pretty much put a nail in the coffin.

OpenID may not be particularly common in consumer-facing services, but it is very much still in use for business applications. Almost every web application I use for work handles authentication through my G Suite account.

This is probably easier for the business case, where you can guarantee that everyone has an account from the same provider. Less so when some of your users want to use a Google account, some want to use Facebook (which isn't actually OIDC and requires its own separate implementation), some want to use Microsoft, etc. Like any complex open standard, the completeness and correctness of implementations vary widely, and supporting many different implementations is a pain even if 90% is the same. I'm reminded of my time working with different IPSec implementations.

Post reply on HN