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

451–460 of 520 posts

Re: Don’t Get Clever with Login Forms

#451

Post by ozim »

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.

Blocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'. Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies.

Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...

Re: Don’t Get Clever with Login Forms

#452

Post by Benjamin_Dobell »

samatman wrote: post #423
contravariant wrote: post #376

Earlier quoted context omitted.

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.

Github does allow pasting though.

The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.

Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.

Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.

Re: Don’t Get Clever with Login Forms

#453

Post by smadge »

baddox wrote: post #450
smadge wrote: post #326

Earlier quoted context omitted.

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.

You could implement an upvote or like as a hyperlink or a form, then progressively enhance that feature to not initiate a full page reload (iirc this is how HN implements upvotes). Similarly expanding or collapsing an accordion menu could be a hyperlink which by default does request the additional content but which can be progressively enhanced to provide that feature with JavaScript for user agents that support it. As an added benefit to supporting more clients, I find it easier to reason about the state of the view when it is encoded entirely in the URL, and available state transitions being to be encoded using features of well known media types like html. This is one of the main benefits of REST: any user or user-agent which knows the media type knows how to interact with the application.

Re: Don’t Get Clever with Login Forms

#454

Post by alkonaut »

I think the Delta example looks pretty ok. If the user enters a number in a field a second field isn’t required. Then it shouldn’t be visible and enabled until we know that it’s needed.

We don’t make a worse UX for humans to make a better “api” for scripts.

There must be a way of satisfying both here without being worse for humans. If not: optimize for humans.

Re: Don’t Get Clever with Login Forms

#455

Post by usgmr »

MrStonedOne wrote: post #323
usgmr wrote: 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 you somewhat. I think my role as a developer/designer is to make sure that my forms work with pw managers. But I think encouraging users to use a manager should rest upon password managers. I can nudge them to use a secure password but the decision to write something like "please use a password manager" isn't usually my decision.

Also, let's admit it, unless you do something really crappy like remove copy-paste, forms don't exactly "not work" with managers. Most of the time, you don't have to do anything special and it would work. Some just take a bit more time because you have to cop-paste it and not autofill. But people who are already using pw managers don't just stop using it (or start memorizing their passwords) because one site can't be autofilled. They just copy paste it, at worst, they manually input it while looking at the password from their pw manager of choice.

My line about "supporting" it is a bit off. I used the wrong words. It goes to say that you should support it. Again, you have to do something really out of your way to completely block off password managers from your forms so really, I think the norm is that they support it. My thought goes more along the line of whether I should be the one to adjust when the form works on some pw manager but not on another or when the pw manager can handle other sites properly and not mine. "Working" and "handling" here means it can be autofilled (most of the time).

Re: Don’t Get Clever with Login Forms

#456

Post by alkonaut »

gesman wrote: post #418
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.

Banks do that when adding new credit cards or checking account numbers and so on. Presumably for making it more secure

Someone at my company suggested it (not an expert) when we discussed a new login UI. When I had a meltdown and asked WHY!? The response was “oh, I didn’t understand it was controversial and I thought everyone blocked paste for security”.

So that kind of explains why it’s done. It’s a misinformed cargo cult.

Re: Don’t Get Clever with Login Forms

#457

Post by alkonaut »

PunksATawnyFill wrote: post #430
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.

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

I prefer having to just hit “forgot password” over hitting first “forgot username” and then forgot password...

Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.

For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.

For category b) sites (say ten or something) I use long unique passwords and 2FA.

Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.

Re: Don’t Get Clever with Login Forms

#459

Post by Sacho »

ozim wrote: post #451
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.

Blocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'. Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies. Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no compl…

Keeping strong passwords in a plaintext file on your desktop seems like much better security given the most common threat model - compromised dbs leaking the weak password you reused on several sites.

Re: Don’t Get Clever with Login Forms

#460

Post by dooglius »

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.

And one that so many screw up: don't make scrolling anything other than a proportional shift in the page.
Post reply on HN