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

351–360 of 520 posts

Re: Don’t Get Clever with Login Forms

#351

Post by Wowfunhappy »

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.

I think this is the same thing my javascript bookmarklet does automatically to reveal saved passwords (when I can’t remember them). The bookmarklet works everywhere I’ve ever tried it, and was super useful before I switched to a real password manager.

So, consider this an anti-debunk.

Re: Don’t Get Clever with Login Forms

#352

Post by freewilly1040 »

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

Whoa that's bad!

"Does your account number begin with a [letter]?",

Where letter is a link. It's like a riddle.

Re: Don’t Get Clever with Login Forms

#354

Post by eastendguy »

argd678 wrote: post #328
013a wrote: 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…

There needs to be a standard or something here to facilitate password mangers. Everyone should be using one and not reusing the same password.

What I do is to combine the password manager (to store the passwords) with a web macro tool (kantu) to automate the clicks through the pages. I can trigger the kantu macro from a bookmark.

Re: Don’t Get Clever with Login Forms

#355

Post by geofft »

nojvek wrote: post #337
argd678 wrote: post #328

Earlier quoted context omitted.

There needs to be a standard or something here to facilitate password mangers. Everyone should be using one and not reusing the same password.

I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction. I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.

The trick is to install a password manager browser extension, not to use a password manager that operates as an isolated app / CLI tool / website / etc. Then you unlock it once at the beginning of your session (or whatever frequency you feel like) and it will fill in passwords for you when you click, without having to copy/paste them. It's about as easy as external login / login with Google.

(inb4 "but password manager extensions have bugs that cause them to fill in the password on the wrong site": get one that doesn't. https://news.ycombinator.com/item?id=18984582)

Re: Don’t Get Clever with Login Forms

#356

Post by scarmig »

da_chicken wrote: post #316
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.

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.

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 users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.

Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.

Re: Don’t Get Clever with Login Forms

#357

Post by dfabulich »

013a wrote: 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…

The built-in browser password managers (Chrome, iOS Safari, Firefox) are pretty popular.

But I agree that the real moral of this story is: test your login page with browser password managers. They all support multi-page login flows if you tag them correctly. (Google uses one, so they can't just ignore this problem.)

If your login page works with the built-in password managers in Chrome, Firefox, and Safari, it will also work with LastPass and 1Password, too. And you're done!

Re: Don’t Get Clever with Login Forms

#358

Post by tialaramex »

013a wrote: 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…

> Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.

I'm not so sure you're right in the general case, modern password managers are aimed at fairly normal people, there may very well be millions of password manager users.

Nevertheless, even if we're a "rounding error" we are often decision makers. So deliberately not supporting our workflow may make it surprisingly hard to get us on board, or to keep us from recommending one of your competitors just because it annoyed us to use your workflow instead of ours.

Several people below have suggested tricks that preserve your desired behaviour (people don't go down rabbit holes for other auth methods that weren't for them anyway) while making password managers still work. Those are better than what you do now, so, do that.

Re: Don’t Get Clever with Login Forms

#359

Post by jeffmk »

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…

I'm also curious how this is more effective at stopping a keylogger than copy/pasting from a password manager, or auto-logging in via one.

Unless it's common for keyloggers to monitor the clipboard?

In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.

I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.

Re: Don’t Get Clever with Login Forms

#360

Post by tialaramex »

geofft wrote: post #355
nojvek wrote: post #337

Earlier quoted context omitted.

I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction. I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.

The trick is to install a password manager browser extension, not to use a password manager that operates as an isolated app / CLI tool / website / etc. Then you unlock it once at the beginning of your session (or whatever frequency you feel like) and it will fill in passwords for you when you click, without having to copy/paste them. It's about as easy as external login / login with Google. (inb4 "but password manag…

Having auto-fill may be rather dangerous even if your password manager extension has no bugs whatsoever. I would not recommend this configuration.

Having one touch form fill for credentials is good enough. It adds one touch to every intended login, but deletes the risk of credentials being captured when you weren't actually even trying to log in.

Post reply on HN