3 ms·

>Your password should not go anywhere near a database. > > It should be salted and hashed a few hundred thousand times and that compared to the salted, hashed

>Your password should not go anywhere near a database. > > It should be salted and hashed a few hundred thousand times and that compared to the salted, hashed version stored on file. > > If you can't even manage that, you have no business writing software that can store credentials That's misunderstanding the nature of the vulnerability. 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. It's not even clear that there is a vulnerability problem here, though there is obviously a usability/UI problem. It could very well be that having those words in your password doesn't compromise security anywhere, but some systems might reject the password before even attempting to authenticate with it.

oliwarner 3y ago
It might be a method to avoid trigger an overenthusiastic WAF, but these are all SQL tokens and keywords. It seems far more likely that they've blocked them in a desperate effort to catch injection attacks. There might not be an actual attack vector, they might block these words in all inputs. It just smells like incompetence.
- pixl97 3y ago
  WAFs commonly block SQL keywords to prevent SQL injection, so it still holds that the WAF could do it.
8note 3y ago
> but where it is entered. Hmm. This strongly reminds me of gpt promt injection. I guess why they're both called injection attacks
deathanatos 3y ago
> 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.)

oliwarner 3y ago

It might be a method to avoid trigger an overenthusiastic WAF, but these are all SQL tokens and keywords. It seems far more likely that they've blocked them in a desperate effort to catch injection attacks. There might not be an actual attack vector, they might block these words in all inputs. It just smells like incompetence.

pixl97 3y ago
WAFs commonly block SQL keywords to prevent SQL injection, so it still holds that the WAF could do it.

8note 3y ago

> but where it is entered. Hmm. This strongly reminds me of gpt promt injection. I guess why they're both called injection attacks

deathanatos 3y ago

> 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.)