Hacker News Reader

Comment by airstrike | Hacker News Reader

I would think management can't be that adamant about not letting users copy-and-paste... I would also think front end folks should try saying "no" to at least some of those silly requests

View on HN

Large corporate/government IT lives on another plane of existence. Rules are made in some far-flung office and enforced through edicts that can't be challenged, partly because nobody knows exactly who created them, partly because nobody wants to stand out, and partly because yes-men surround the upper levels of management.

Anyway, somebody somewhere about a decade ago seems to have injected into the heads of such rule-makers that users who paste their password confirmations defeat the purpose of the confirmation mechanism, which was leading to excess support requests for forgotten passwords. So, therefore, pasting into the confirmation box (or even better, both boxes) should be disabled.

Never mind that password rules have gotten more complex, that allowing users to temporarily preview their passwords instead is now recommended, or that the use of password managers and online password resets means even if the original concern were valid, it's now moot. The rule exists, and so it must be followed.

At some point these corporations do lurch forward (or die), so eventually this will get changed, but it'll happen way slower than it should.

Honestly, 1Password (& co.) should have an option to "Type password" next to "Paste password".

Prevent that, you stupid website, I dare you!

Fwiw keepass and keepassxc allow you to do this.

It does, actually. (At least the old self-hosted version that I still use does. Don't know about the newer one.)

1password can do that

Disabling copy-paste is exactly the kind of thing that a higher-level manager sees on some website, decides immediately that it’s very important for content protection and IP and trade secrets and whatnot, then emails a middle manager to have this implemented ASAP. A week later the request has filtered into a ticket that lands in the front-end developer’s inbox.

What should the developer do exactly? Ignore the ticket? Educate the manager who’s perhaps three steps up in the hierarchy and doesn’t even know the person’s name who is charged with implementing the misfeature? Neither would go down well.

No reason to ignore it, but it's pretty easy to argue against. I realise in some places you'd not be talking directly to the person it came from, but if the person you _are_ able to talk to says "That all may be true, but just do it", it's time for a new job.

I do some front end work. I push back on things and win some battles re-directing them, but ultimately if the client pays to do a stupid thing, they get the stupid thing. It is their website, not mine.

This shit is usually from "security" which, in corps, is just endless list of boxes that you need to check and are handed over manager to manager. Everyone is scared to actually remove anything from the list because nobody knows who is actually responsible for maintaining it; getting through the hierarchy to even find such a person would take a month; if you find him, he will tell you "oh it's for compliance with <some mysterious government/iso/owasp document that's 20 years out of date>, safer to keep it there"

Exactly, good luck convincing management not to do something that the infosec team suggested even though it provides an insignificant amount of security. The hackers you really have to worry about aren't using your front end, they're submitting directly to your endpoint to bypass exactly these kinds of things.

This is the imbecile's solution to people pasting in their passwords from a text file. Except some people paste them in from their password manager.

Also, the error he got when he tried to put in the password the first time is likely because there's a mismatch between what it claims the password rules are, and what they really are. He might have exceeded the maximum password size (yes, I know they're supposed to be salted in the backend, and maybe then even are, but you still run into this). Or it might be that he used disallowed punctuation (some sites seem to dislike anything other than question marks and the ones over the 1-2-3 keys... I've personally seen the percent sign and ampersand both cause problems.

If there were some little embedded xml file that my password manager could pull from the page automatically that would tell it what the rules are, then I wouldn't have to debug your shitty account creation systems, nameless developer drones out there working for big companies! Not that you care.

Not in my experience, and not for trivial things like this. I'm sure this varies widely with employer, location and life situation, but generally these kinds of annoyances are both far from the worst that people need to do / tolerate, and that they don't have any say in what goes into the product, they either implement it, or someone else implements it and they can go work at someplace else if they don't like it.

That one may be coming from the InfoSec guys.

"Infosec mill agency that looks for easy wins to justify the high price tag they charge enterprise clients like Broadcom"

FTFY.

It absolutely can be, and can even go higher. Recently the Reserve Bank of India updated rules around what is considered security, many banks interpreted them to mean copy and paste into /any/ field is not allowed. Yes, you have to fully type in account numbers etc.

I can't imagine any front end person spending extra time blocking the paste function when nobody asked them to do that. This may also come as a surprise, but sadly management and infosec doesn't always take advice from the front end developers.

This isn’t a front end dev problem.

You can say no but management isn’t under any obligation to capitulate, and often won’t.

More over, it’s often solutioneering as a result to some other management identified issue that devs have pushed back on.

Reply on news.ycombinator.com