Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

411–420 of 520 posts

Re: Don’t Get Clever with Login Forms

#411
post #347
post #338

Earlier quoted context omitted.

Ha. Right click -> inspect element. In dev tools console. $0.value =“password”. I use that in reverse when I can’t remember a password. Get the value from input element gives the browser remembered passwords. Works on other peoples machines too. If you wanna steal remembered passwords. That’s how chrome extensions steal passwords. Just sayin.

Someone debunk this so I can sleep at night.

I just stole all 4 of my banking passwords this way :/

Re: Don’t Get Clever with Login Forms

#412

Earlier quoted context omitted.

This should be the answer. As soon as the user enters a valid email (regex test) send a request to server to figure out what path they need to go down in the “federated flow”. What we shouldn’t do is diminish the experience for some because the flow for some others is different.

It should be onblur, otherwise you'd send requests for: - me@example.c - me@example.co - me@example.co. - me@example.co.u - me@example.co.uk And you'd have to account for all those tricky race conditions happening there

And me@example.co could be the email of another user, so you'll never be able to login with yours.

Re: Don’t Get Clever with Login Forms

#414
post #11

My 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 ire is when a password manager generated password has too many special characters, is too long, or any number of trash restrictions that ultimately cause me to use a manually generated password to get around the restrictions.

Re: Don’t Get Clever with Login Forms

#415

Earlier quoted context omitted.

I like the magic links, but more as a secondary option or at least an equal option to a password. I have yet to see a site completely depend on the magic links and I hope that doesn't become a thing. I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.

>I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote. I hate this with a passion. I'm all comfy in my chair, ready to watch something, and I get the message that I have to get up and go to my computer and do stuff when all I want to do is watch TV. So I watch something else that doesn't…

Have you considered using your smartphone, which is right next to you and already configured with your email and a web browser? That was probably the intended use case anyways.

Re: Don’t Get Clever with Login Forms

#417

Earlier quoted context omitted.

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

> Don't break the back button. Can someone please tell SAP?

Add it to the giant list of suck.

Re: Don’t Get Clever with Login Forms

#418

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.

Banks do that when adding new credit cards or checking account numbers and so on.

Presumably for making it more secure

Re: Don’t Get Clever with Login Forms

#419

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.

I would love Apple to add this to their app review process, as some apps also disable pasting. In addition, force all apps to allow password managers.

In a sense Apple has ended up fairly close to this by providing native integration between the system keyboard and password managers.

Re: Don’t Get Clever with Login Forms

#420
post #346

Earlier quoted context omitted.

Maybe I'm not following things right, but instead of doing it this way, why not have the screen with email and password (and whatever else - forgot password, submit button, etc) - but have the screen do the check on the email - and if the flow is different, change the screen (remove fields, change labels, etc), or redirect to a new screen? That way, those that use password managers could still continue so (as it woul…

Imagine a real world equivalent: a store that loudly states "Membership card needed for purchase", but in actual fact have massive exceptions if you do try and purchase without a membership. This wouldn't be a smart business decision (how many non-members do you know who fill their prescriptions at Costco).

The password field in this scenario doesn't have to be visible. As long as it's attached to the DOM the password manager can still fill it. Then you make the password field visible if the email address doesn't match a known SSO integration.
Post reply on HN