Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

431–440 of 520 posts

Re: Don’t Get Clever with Login Forms

#431

Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

Another rule: DON'T FORCE PEOPLE TO USE AN E-MAIL ADDRESS AS THEIR USER ID. Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...

People use the same user ID all over the place anyway. That includes the part before the "@" in their email address. If any one of those credentials is leaked, the damage is the same.

At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.

Re: Don’t Get Clever with Login Forms

#433

Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

Another rule: DON'T FORCE PEOPLE TO USE AN E-MAIL ADDRESS AS THEIR USER ID. Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...

That's not at all convincing. A username+password is probably more likely to be reused than email+password.

Re: Don’t Get Clever with Login Forms

#434
post #177

Earlier quoted context omitted.

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.

> He gets to have the added insecurity if putting it on his clipboard for other programs to see on the way by. If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here. If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password…

Unless you're running a clipboard history program. I know at least two people that user such software; it basically saves the past 10 or so clipboard contents for later use.

Re: Don’t Get Clever with Login Forms

#435

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…

Dropbox does an AJAX request when you enter your username, and it's fast enough that when you get to the password field it's already greyed out if you use SSO.

HelpScout's login is anothrt good example! Definitely echoing other's thoughts that it's the correct way to handle it

Re: Don’t Get Clever with Login Forms

#436

Earlier quoted context omitted.

I wonder if that's a way for spammers to harvest known good e-mail addresses.

Those are available for free on the internet dude. This is a non-concern. The bad guys don't listen to GDPR. There are entire email lists available.

And how are such lists constructed?

Re: Don’t Get Clever with Login Forms

#437
post #39

Earlier quoted context omitted.

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

As a web designer, your goal wrt security should be to make your site only work with password managers, and never work with manually entered passwords. Password managers aren't "Another thing to support" but "The only secure way to do passwords" If your user can remember their password, they also likely: reused it elsewhere, have some pattern to it or minor changes that could be figured out from a email search in any…

I agree with this — I’ve “helped” a few friends transition their lives to password managers (basically just sat with them and kept suggesting sites they probably use that they might want to go change their password for — after they’ve done 5 or 6, they understand how to do it and are very likely to keep using it going forward).

I think this has to be highest benefit easy-ish thing you can do for someone to aid their computing lives in 2019 ...

Everything sites can do to help users undergo this transition would help them in the long run ...

The big password manager implementations need to do better as well — I don’t understand why iCloud Keychain doesn’t support generating random passwords that conform to the (horrific) password complexity checks you see out there in the world sometimes ... those sites are wrong to have such a broken feature but there are enough such broken sites out there that a clean workaround is needed on the password manager side ...

It would also be nice to have a solution for security questions built in — my solution is an OpenSSL command line for the random password generation and shared notes in which I record security questions and answers for sites. It’s better than actually providing real answers to security questions at least ... support for this functionality should really just be built into my password manager — the alternative likely thing is that a user will use actual answers to security questions for password reset all across the internet and this is not a thing the password managers should support their customers doing ...

Re: Don’t Get Clever with Login Forms

#438

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.

>Password managers can't deal with this, unsurprisingly Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form. Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)

> Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.

Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.

Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.

This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.

Re: Don’t Get Clever with Login Forms

#439
The reason password entry is sometimes split to two forms is because of SSO logins. The alternative is what Microsoft does which is to dynamically check the email after filling it and passing on to the password field and quickly redirecting if needed which is also weird. That’s also why Google does it.

Re: Don’t Get Clever with Login Forms

#440

Earlier quoted context omitted.

Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one? It frustrated everyone. Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, a…

The way google does auth is also two screened, email -> next -> password But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.

Yeah, google might do it technically smart.

But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.

Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.

Post reply on HN