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

441–450 of 520 posts

Re: Don’t Get Clever with Login Forms

#441

Post by usr1106 »

01100011 wrote: post #426
joshuaheard wrote: post #272

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.

One more reason to love Linux and X Windows: highlight password, middle-click into the field. You can take away ctrl-v, but you can't take away my X Windows clipboard.

Highlight and middle click is the X11 primary selection. In my experience Firefox (and Emacs) do not always play well.

Re: Don’t Get Clever with Login Forms

#442

Post by dustinmoris »

I agree with the many points but it's worth noting that login forms are made for humans to identify themselves with a service and all his suggestions are designed to make it as easy as possible for a bot/machine to identify as the human. There is always another side to the story and whilst password managers are one type of machine for which this becomes useful, it's not the only one.

Re: Don’t Get Clever with Login Forms

#443

Post by varjolintu »

Semaphor wrote: post #192
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.

While it can't handle the email part, at least mine nowadays handles the password field. I use KeePassXC-Browser (connecting to KeePass despite the name) and it recognizes the password field even if I entered the email in an (annoying) extra step.

Actually it can handle the email part also. You just have to add the site URL to Site Preferences in the extension's settings and enable Username-only detection. It's a necessary extra step so the credentials wouldn't be filled to search fields or to other single input fields. It's quite hard to detect if an input field is actually a username field.

Re: Don’t Get Clever with Login Forms

#444

Post by krferriter »

tomc1985 wrote: post #47
amaccuish wrote: post #3

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…

Pretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen. Pisses me off too

You can do this without it being two separate views. Send a request on lose focus of the username field to check if the account is from a federated service.

Re: Don’t Get Clever with Login Forms

#445

Post by krferriter »

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.

Why is it a requirement to have two separate views? Why not just do the check when the user leaves the username textbox. I don't see the reason for the other page to be displayed separately.

Re: Don’t Get Clever with Login Forms

#446

Post by scarejunba »

dbdjfjrjvebd wrote: post #436
scarejunba wrote: post #164

Earlier quoted context omitted.

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?

You just breach someone with a lot of them.

Re: Don’t Get Clever with Login Forms

#447

Post by dingaling »

tedmiston wrote: post #404
joshuaheard wrote: post #272

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.

Most sites that hijack and block pasting via JavaScript are easily circumvented by pasting somewhere else nearby, such as the location bar (without hitting return), then dragging and dropping that value onto the field of interest.

A clever hack but perhaps not one to use in browsers like Chrome which do dynamic search lookups.

Re: Don’t Get Clever with Login Forms

#448

Post by dingaling »

kijin wrote: post #431
PunksATawnyFill wrote: post #430

Earlier quoted context omitted.

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.

Many years ago I used a forum that autogenerated usernames from a hash of responses to questions ( player name, age, city etc ) in a similar manner to those 'porn name' algorithms. Which was quite a relief in place of the usual 'invent a unique name' mindblank I often suffer.

Similarly my banks issue me my website user strings.

Why do so many website permit users to choose? Forcing the user to write-down their assigned designator might lead to better security, too, since they would seem at that point more open to writing-down a strong password.

Re: Don’t Get Clever with Login Forms

#449

Post by pjc50 »

siedes wrote: post #347
nojvek wrote: 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.

All extensions with access to the DOM can steal passwords. That's the argument used for restricting sideloading, etc.

(Can they steal Basic-auth passwords, though?)

Re: Don’t Get Clever with Login Forms

#450

Post by baddox »

smadge wrote: post #326
da_chicken wrote: post #316

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 have any application state transitions that are not hyperlinks or a forms.

Hmm, what about upvoting or liking a post? Or do you consider an AJAX POST request a “form?”

There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.

Post reply on HN