Live data from Hacker News

Don't fuck with paste

github.com

301–310 of 397 posts

Re: Don't fuck with paste

#301

By disabling user input the application security actually gets worse. Users that can’t copy e.g. passwords will use less complex passwords to overcome the trouble of typing in their initially good passwords. But also user experience is degrading when applications enforce complex input and users generate that input like a chad as they should. But now they cannot paste…

I'll add to that systems that require particular characters to be used, like "must use capital, number and special character". I prefer to generate longer passwords but using only regular characters because I find it easier to type on the occasions I do have to do that. Even worse, there are some that restrict what kind of special character you can use. So even when I've generated one I still have to edit to remove o…

All I ask is that the same restrictions are also displayed again whenever I have to enter my password for login.

Re: Don't fuck with paste

#302
post #300

Earlier quoted context omitted.

I'll add to that systems that require particular characters to be used, like "must use capital, number and special character". I prefer to generate longer passwords but using only regular characters because I find it easier to type on the occasions I do have to do that. Even worse, there are some that restrict what kind of special character you can use. So even when I've generated one I still have to edit to remove o…

You want to have weird password rules? Fine. Please make some standardized meta tags my password manager can find so it generates perfect passwords every time. Bonus points for a well-known URI facilitating touchless password rotation.

> You want to have weird password rules? Fine.

I'd be fine with storing the password policy in the password manager, and having it generate based on that policy next time.

And having all sorts of weird stuff in a password isn't necessary, so neither is the policy. To top it all off, many of the sites obsessed with password quality actually limit password length. Why?! You are comparing passwords hashes and storing them as hashes, right? So the length shouldn't matter.

Allow passwords of effectively unbounded length, set a reasonable minimum length, and don't obsess about password 'complexity'.

And for the love of all that is good, don't eff with paste.

Re: Don't fuck with paste

#303
post #253

In case of not being able to past I normally right click -> inspect element and in the console write $0.value="value from clipboard". Works almost everywhere. Tampering with paste is kinda is like turning of autofill and the HTML5 standard is pretty clear when it should only be turned of: ".. particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused…

That plainly seems like a mistake in the standard that harms security. What's the reasoning there? That somehow human fingers are less prone to error than password managers?

The only thing I can think of is malware changing the value of the clipboard to fool someone into pasting the wrong thing - but if you open that scenario then you've got all kinds of ways malware could mess with a manually typed field too.

Re: Don't fuck with paste

#305
post #263

Earlier quoted context omitted.

Limiting characters can also be a feature, so users can't use emojis in their password (this is so fun), to realize later they can't login, because they don't know how to input emojis from their desktop computer. Hopefully passwords will be gone soon (at least that's my hope).

There's only so much user hand holding you can do.

With how ubiquitous Apple is, introducing a small limitation to prevent user error can make a huge difference in reducing support requests.

Re: Don't fuck with paste

#306
post #267

Earlier quoted context omitted.

Even worse, when on top of all these they add an arbitrary length requirement: It can't be less than 8 letters OR more than 12. :|

Several comments mention passwords getting silently truncated by input maxlength. FWIW my extension provides a visible warning when this occurs: https://underpassapp.com/StopTheMadness/

I love this extension so much. Nothing satisfies me more than forcing stupid websites into cooperation.

Re: Don't fuck with paste

#307
My HMO does this, and I've complained year after year.

They also specify a limit of 15 characters in the text above the "change your password" field, but it actually is limited to 14 characters.

Imagine the frustration when you type in a 15-character randomly generated (from a password generator) password twice, and then have the system reject it because it is too long!

If I ever have any extra time, I'll see if I can sue Sutter Health for an "ADA" or similar violation over this.

Re: Don't fuck with paste

#308
post #266
post #239

Earlier quoted context omitted.

For my own applications I typically require only three rules to be kept, two of which most users will never even encounter, the password must: 1. be long enough (e.g. 8 characters or more) 2. not be in the list of 10k most used passwords 3. not simply reuse words present in the username, email, birthday (if my application knows about it) This keeps it open and only interferes with truly stupid (aka insecure) password…

Good, except min 8 chars is not safe at all. Don't approach any semblance of security before min 12 chars. Min 14 is when you get into real security. The increase in entropy is exponential with password length, so security increases quickly after this.

All that users do when they get hit with restrictions like that is repeat their password again, or fill it out with exclamation points. Not a lot of entropy getting added.

Re: Don't fuck with paste

#309
post #298
post #153

Earlier quoted context omitted.

> This is a bit cynical isn't it (...) No, it's called security. Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. What leads you to believe that good intentions are enough?

> Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. Following this logic, we should all stop using any and all software for which we haven't personally inspected the full source code for, since this could happen to any of them.

That's the extreme end, sure.

A more reasonable take would be to assess your risk tolerance and the possible benefit for each piece of software you install, and then make the best decision for yourself based on that assessment.

For some people, that means not running an extension that provides minor quality of life improvements due to the possibility of it turning malicious further down the road. For other people, it means the opposite.

Not sure why every security-related conversation devolves into one extreme vs. another extreme. Security must be appropriately balanced against risk tolerance, inconvenience, and a number of individual concerns and preferences.

Post reply on HN