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 run into it relatively frequently and it both angers me and blows my mind that some developer or team thought this made sense
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
But how does this logic work when a keylogger can basically do the same thing to a typed password?
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.
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.
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.
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.
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.