I wouldn't be telling anyone to implement crappy password policies as a workaround.
I'd tell them to do it properly or not at all, and remind them that in many jurisdictions, knowingly implementing poor data controls earns you some actionable liability. PII is no joke.
This isn't controversial when you're telling people you can't do your own gas work without certification, or electrics without experience. It's okay to demand competence.
What you're recommending is the status quo. The status quo has led to me receiving regular letters informing of massive security breaches where all my PII is disclosed and I have no recourse of any kind, other than possibly spending my life fighting a giant company in a class action lawsuit when I have no time or skill set to do so.
What I'm recommending is just part of the bare minimum security requirement for an authentication system. SQL parameterisation, transport encryption, input validation (and more) are all as important.
Stopping SQL keywords is a distraction dressed up like security. It's harmful.
> Stopping SQL keywords is a distraction dressed up like security. It's harmful.
We are talking about how to mitigate harm from people who are already doing the wrong thing. Saying that this distracts from doing the right thing misses the point. They are already doing the wrong thing. You saying they should not do the wrong thing does not stop them from doing the wrong thing. Once again, your proposal is the failing status quo.
I'm really trying to meet you halfway here but I can't imagine a scenario where I had such low confidence in a third party application that I'd wrap it in input-filtering cotton wool and feel like that was safe enough.
A project that both stores plaintext passwords and fails to use parametrisation (something that's been standard practice for over two decades) is untrustable. It's an untenable liability.
Maybe I'm wrong. Could you explain when you think this would be acceptable?
It's not that I think it's acceptable. I'm thinking about how to reduce the harm of people doing unacceptable things that we can't stop them from doing. I would be very transparent about this. I would say this is harm reduction for people who are doing the wrong thing and is a waste of everyone else's time, but we have to do it anyway because software engineering has failed to govern itself as a profession and the government has failed to hold it accountable for its disasters.
The key thing is that it's both easy to test and would stop many attacks. Anyone can check whether the password field will take these forbidden keywords and patterns.
No question it's a pathetic thing to have to resort to, but pathetic is where things are at right now.
If they're storing raw data without parameters, you can't have any confidence they do that with every other SQL query. You'd have to block every SQL token from every input.
Imagining we're happy to sacrifice these words to the gods of security theatre, what layer are you suggesting this goes? Browser level just means hackers can make raw requests. HTTPDS could block it, like an overzealous WAF, but that still needs implementing. Service providers shouldn't be able to see this stuff because of transport layer security.
There's no sensible way to make this make sense.
I do agree that a lot of entities are not adequately prosecuted for their incompetent data handling but fixing that seems far more realistic than banning the word "drop", everywhere.
Does it really reduce harm? Bypassing something like this should be, like, one checkbox in metasploit. It's like requiring all walls to be wallpapered to make sure no-one spots any cracks in the walls.
Most software you use is untrustable. You get a binary and you pray the vendor isn't an idiot. Even if you watch all the SQL commands it does in normal operations, you can't be sure an attacker cannot send some operation you don't know about and do a regular SQL command.
Do what we've successfully done for hundreds of years: Fine and potentially prosecute them. Stop pretending software engineers are special snowflakes, and apply the same standards we use for bridges, roads, etc. None of those are perfect, but they do manage to do things like stop using known-bad materials, which is broadly equivalent to allowing script injection via password fields.
