Hah, good point. Although I do have to wonder: When does it turn into filtering by force of habit? After all the legacy cruft has long been forgotten and is no longer maintained?
Because the other monkeys will chew you out if you start doing it differently all of a sudden. Nobody knows exactly why we're doing it the way we are doing it, but it is complex, and changing it might break something.
Let's use the "filtering chars from password" example above. You can't put some special chars in password field, and you want to change that so it's doing normal hashing where special chars don't matter.
In a larger org, even changing a practice like that so that it "makes more sense" can have a big ripple effect.
You have to
* explain to someone else on the team who came up with the original process that it's flawed (and why)
* explain to other dept that they need to update their testing process (and why)
* get support dept to change their language/process
* change outbound messaging in all affected places (perhaps with code you can't touch, involving other teams)
* possibly have a flag that deals with 2 versions of data
Even if your change brings you in to line with normal/safe practices, you may have to fight multiple inane battles, spend loads of time and political capital, and at the end of the day, you'll be able to also accept a !"@+'$ in a password field? Most people will not grasp the bigger issue at play.
At a small business convincing colleagues isn't that hard. At a larger corporation, getting the rest of the team on-board is the job of whoever is in charge of defining security policies and such. Not allowing characters present on all keyboards and input devices (!"@+'$) statistically increases the risk of people picking weaker passwords then possible, and he/she will guide that change through the proper processes, for example to make sure that any client software interacting with the backend is aware of the upcoming change. Same as with any security issue (e.g., the deprecation of SSLv3 ciphers in favour of newer TLS versions).
If a business can't handle a change like this, something is really broken in the development pipeline. Granted, that describes a lot of medium sized companies…
Take that one 'request' - possibly initiated by a jr-mid level developer - and stack it up against the 500 other todo items in the pipeline. You can make those arguments about "statistically increases the risk of people picking weaker passwords " - unless this increases a bottom line or comes out of someone else's budget, this sort of 'bug' is going to be really low down on the totem pole for all the reasons I mentioned, and a few others.
You can says "the process is broken" but it's also that same process that got people where they are, puts food on their table, pays for the lifestyle, and precious few people are willing to ever rock the boat at any company for anything.
Which gets back to some of the cargo cult thing too. It's not uncommon in a large enterprise to smack up against things like "Years ago we paid a highly trained Security Consultant a large amount of money to develop our Security Guidelines, who are you and where are your security credentials to tell us to do things differently?"
Even worse when that "Security Consultant" is still a retained coworker with a fiefdom to maintain by war at all costs, a wizened old greybeard whose seniority will always trump yours, and/or your boss.
