Hacker News new | past | comments | ask | show | jobs | submit login

I would love to hear anyone defend the practice of disabling paste on password fields.

I run into it relatively frequently and it both angers me and blows my mind that some developer or team thought this made sense




I’ve had very expensive pen testers tell me to do this as recently as last year. They folded instantly at the first sign of pushback, so it seemed to me something that had been sitting in a checklist for years without anybody questioning it, making every website and app they audited worse.


That's awful. It's such a security antipattern, obvious as soon as you take into account, you know, _Humans_...

Site: Please make a password

Human: 7#hs&_suiE2KcS0

Site: No copy and pasting

Human: mydogisagoodboy123

Site: Needs special characters

Human: Pa$$w0rd12345

Site: Looks great thanks


Its like those policies where the password needs to change every 60 days that was found to actually reduce security because of the count-up-by-one passwords people would use. For places where that's been a rule forever it is really get it removed.


I don't agree with it either, but the reasoning i've always seen has been along the lines of, "it prevents people from putting passwords into the clipboard which can be stolen by other programs", and then similarly for disabling browser or password manager autofill "because it prevents people from making a mistake and letting a field get filled with a password when it shouldn't". Basically leading to "users should just manually type in and remember all their passwords" at the extreme end of the reasoning.


That doesn't make sense. If I wanted to type a password into some other program for whatever reason I wouldn't find out that I can't paste into the password field until I had already tried.


I know it's not your argument but that doesn't make sense either. Processes on desktop OSes can read each other's memory anyway if they're being run by the same user.


> "it prevents people from putting passwords into the clipboard which can be stolen by other programs"

But how does this logic work when a keylogger can basically do the same thing to a typed password?


That and overly restrictive password rules. I often generate passwords using a PRNG or hash function that I know are pretty strong, even if it didn’t actually pick a number.

Most common are the passwords that don’t allow certain characters which leaves me thinking: (1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords. Either way it’s a clear confession of malpractice.

A weird one in that example is that you aren’t allowed to use any trigraph that appears in your email. I find it amusing because last month I was working on an application that has a large number of autocomplete boxes that start showing options when you enter the first three characters and I must have filled out the form hundreds or not thousands of times so I wrote a little Python script that would compute the trigraph frequencies for any set of names. I found out the most common trigraph in country names is “and” for instance.


>(1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords.

Actually, one I've run into is web-framework-level security systems that are hard to disable. Stuff that prevents users from keying in, like XSS attacks. It's not that the password field is being used unsafely, it's that the web framework they're stuck on makes disabling security on a certain text field more complicated than it needs to be and telling the users "screw it, don't use this character in that password" is easier than figuring out how to get the Rube Goldberg machine to do what you actually want. Back-end languages aren't hot garbage like html+js+css so usually it's normal proper BCrypt in the back.

Obviously a modern web framework won't have this problem, but a lot of sites are old and still running on messy cobbled-together piles of JQuery.


I had that problem with ASP.NET back in the day. The creators seemed to think it was impossible to properly escape user HTML against Javascript injections and sometimes you just had to destroy bad strings completely.

It was trashing API keys and passwords which is a problem when "the customer can't log in". I didn't have a hard time disabling this behavior at all though. My feeling is that it is impossible to "live with it" because I didn't know exactly what rules I had to follow to not get strings corrupted.


There's also the chance that this is because "security made me".

More than a few times I've written properly sanitized and parameterized applications, and security came along after the fact and told me we had to prevent input of certain characters. Didn't matter that we handled it just fine, didn't matter that it was safe to put it in. Security's argument was that some other team, some where, at some future time might somehow reuse our data and not follow the same best practices.

So no special characters in your password because some engineer in the future might possibly introduce a bug.


You know you should memorize all your passwords? And have a unique one for every website? All 100+ of them?


What about all these sites now only showing you login input boxes one by one, what’s up with that???

Enter username, click, now enter password is revealed.

Some sites, password manager manages to do both even if only one is shown but usually not.

It’s a common known fact that every person is born with a certain max number of clicks and taps. We all only have so many clicks left in our lives, that’s one less click that I’ll be able to use doing what makes me happy like doom scrolling Twitter. Dammit.


The single username and password fields usually allow the site to determine whether some sort of federated login is in place for your domain.


Thank you to everyone for explaining it. I figured there was a reason but mostly just settled on being annoyed. Human nature and I am very human.


For many it's to support SSO. so if you put in an email ending in `@company.com` and Company signs in to that site with SSO they direct you to the right place.


Aside from SSO, it allows them to check if the username exists before even attempting to login with it


You should check out the government's website for buying treasury bonds. Paste and keyboard inputs are disabled, you HAVE to click on an on screen keyboard to enter your password.


I'm with you...THAT is the worst website!


I honestly thought it was some kind of parody when I saw this. I clicked out and checked the link again just to be sure I was on the right site. Fortunately, I believe they have changed this now


Email or other "ID" fields as well. I use 1password, and besides the password part, it's nice to just click on a field and copy/paste knowing you wont make a typo.


I hate it too, the reason might be that there are vulnerabilities where the virus hijacks the clipboard




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: