> That's misunderstanding the nature of the vulnerability. No, they're 100% correct. If the password is properly stored, there's no possibility of injection, b

> That's misunderstanding the nature of the vulnerability. No, they're 100% correct. If the password is properly stored, there's no possibility of injection, because what gets sent to the database is something like a hex string, or just a bytestring, depending on reprsentation. > It's not about where the password is stored, but where it is entered. Before it can be salted & hashed, there's software that has to decide where the password input starts and ends. If it gets that wrong, that's how you get the vulnerability. ??? Where it is entered looks like this: <input type="password" name="password"> … the actual text of the password makes no appearances, ever. Whatever code you're using to generate HTML/DOM nodes, or SQL queries, should be parameterized and automatically escaping all inputs. If it isn't, that's the security issue, and trying to kludge around it with idiotic restrictions won't work. (Other commenters have already alluded to the problems with the OP's attempt.) But even then, a password should never hit either of those interfaces: there's no reason to render it into the DOM, or into SQL. (There are some other comments about this might be to help users work around failures in a WAF. That could be, but it's orthogonal.)