Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

421–430 of 520 posts

Re: Don’t Get Clever with Login Forms

#421
post #121

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.

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…

I'm honestly not sure why the password managers don't offer federated login (with SSO helped out by their browser extension). As a website owner, I'd love to be able to throw a "login with lastpass" link on the sign in page.

Re: Don’t Get Clever with Login Forms

#422
post #324

> don’t split login across multiple pages This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts? Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, an…

Companies should be making this easier by giving their users URLs that redirect to cloud services using their company's SSO service.

For example, employees access their email on office 365 via https://example.com/email which redirects to outlook.office365.com/?realm=example.com.

Re: Don’t Get Clever with Login Forms

#423

Earlier quoted context omitted.

A use case where disabling paste events makes sense: You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars. Text specifying what they're doing is insufficient, as us…

Disabling copy paste on the field that specifies the resource isn't a solution though, as that only increases the risk of typos.

An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.

Re: Don’t Get Clever with Login Forms

#424
post #233

Magic links are a valid method of login that is "right" for many users who end up resetting their accounts anyways. It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an…

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.

Medium does this for me. I created an account with email. I don't have a medium password. I have to request a magic link any time I'm accessing the site after clearing cookies/accessing from a new device.

Re: Don’t Get Clever with Login Forms

#425
post #347

Earlier quoted context omitted.

Someone debunk this so I can sleep at night.

Another trick you can do is change the field type from password to text in the web inspector, which will also reveal the password in plaintext.

Even simpler, a bookmarklet (untested) for those who can't (or shouldn't be allowed to) use devtools: ``` document.getElementsByTagName('input').forEach(function(e){if(e.type.toLowerCase()=='password'){e.type=text}}) ```

This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark

Re: Don’t Get Clever with Login Forms

#426

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.

Re: Don’t Get Clever with Login Forms

#427
post #336

Earlier quoted context omitted.

It's easier to just hack the HTML IME. If pasting is blocked in JS, and the site has a (probably ancient) version of jQuery installed, just throw this in the console: $('*').unbind('paste');

In Firefox you can disable this stuff by setting dom.event.clipboardevents.enabled to false.

This will also break stuff like pasting an image via Ctrl-V if it's in your clipboard buffer, though. Be warned.

Re: Don’t Get Clever with Login Forms

#428

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.

They do this to thwart hackers, for example to prevent a script that inputs the same password across many accounts. It’s terrible UX for sure.

More like “protect against ‘hackers’” they invited into their site via all the insane 3rd party tracker scripts they embed on the page ...

I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.

There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...

Re: Don’t Get Clever with Login Forms

#429

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.

One possible solution is to allow a url or query param to load a full auth form for each supported provider, in addition to the default stepped screen. That would allow a user to bookmark the form relevant to their auth method.

Re: Don’t Get Clever with Login Forms

#430

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

Post reply on HN