5 ms·

I expect this will attract a lot of criticism, but I actually think it's a good idea, at least in some cases. There are a lot of people writing bad code and ba

I expect this will attract a lot of criticism, but I actually think it's a good idea, at least in some cases. There are a lot of people writing bad code and bad system architectures for their organizations. There are not enough people with the competence, organizational power, and time to catch what's bad and force change in those organizations. In the US you are probably forced to do business via many such terribly coded websites, e.g. your local healthcare provider. In such cases, it might be better if we assumed the implementation might be as awful as it commonly is, and recommended mitigations based on that. It's also easy for people to test if the website actually allows the nominally prohibited password patterns and complain to some oversight authority if so. Whereas it's not so easy to test, from the outside, whether it's really been done the right way. It's inelegant and tragic, but in the end it might be a good idea to accept that things are often done poorly and without adequate oversight, and consider what mitigations can prevent the worst outcomes in these cases.

wongarsu 3y ago
If an organization has such a password policy, that can be interpreted as the person in charge of setting this policy thinks their organization doesn't have enough people with the competence and organizational power to prevent SQL injection vulnerabilities. Which would reflect poorly on any institution, but especially a university (which should be a bastion of people with competence and organizational power). As for common password advise, my take on your argument would be that we should all be using these keywords in our passwords to quickly surface these bugs, lest they be hidden and only used by attackers.
- patrakov 3y ago
  It can be interpreted as you suggest, but does not necessarily come from the person in charge. It might mean that auditors forced the installation of a WAF because of $REGULATIONS (irrespective of the actual code quality) and refused to allow weakening the rules for password fields. EDIT: as they don't actually check for all the banned strings, the "auditor + mandatory misconfigured WAF" hypothesis expressed above is not valid in this case. But let it stay as an otherwise-plausible explanation, or maybe something that was valid in the past.
  - wongarsu 3y ago
    The WAF hypothesis still holds if you assume the password change page is governed by the same WAF. The WAF would reject any new password it finds offensive, and the "rule" about not using certain SQL keywords just matches people's fuzzy understanding of why these passwords are rejected. It was probably even true, a couple WAF rule updates ago.
- civilized 3y ago
  Counterpoint - however pathetic it may be, it's better that they publicly owned up to their lack of confidence in this way. The question is, what do we do about it once we see something like that?
  - wkat4242 3y ago
    > The question is, what do we do about it once we see something like that? Run away and stay as far away from their products and services as possible.
    - danesparza 3y ago
      It's a university
      - wkat4242 3y ago
        Ok don't go there to study CS :)
- SoftTalker 3y ago
  > especially a university (which should be a bastion of people with competence and organizational power) Generally the opposite. University staff positions pay pretty poorly compared to what the most competent people can earn elsewhere. There are some bright staff people at universities who are there for other reasons besides the pay, but the competence of an average university staff software developer is not great. This is also why over the past two decades universities have trended to SaaS subscriptions rather than building software in-house
  - cbsmith 3y ago
    Yeah, there's very much a "cobbler's children have the worst shoes" aspect of this that some people don't get.
- mkl 3y ago
  > especially a university (which should be a bastion of people with competence and organizational power). Those people are not the ones running the IT systems. Even the software engineering and information systems departments have no say. IME university IT are understaffed, outsource a lot (often without a choice), and often have to follow decrees from higher management that don't seem to have been thought through.
ipython 3y ago
But why would you ever send a plaintext password into a sql query?
- civilized 3y ago
  Because you are lazy, irresponsible, and/or incompetent.
- AndroTux 3y ago
  Or anywhere else except a hash function for that matter?
- petee 3y ago
  Since being clever is often a footgun, I'll admit to one idea I had years ago; I never really gave it the smell test, and it only existed for a personal project. But if one person thought of it, others may have as well. I was learning to write sqlite C functions for fun, and thought since storing plain passwords has been such an issue, why not offload the responsibility from the programmer and let the db handle it fully -- consume plaintext, salt, hash, etc, and could transparently upgrade algorithms when necessary. Luckily I've learned enough to recognize that my skillset is not of the level necessary to fully evaluate the risks. Today the idea makes me feel uncomfortable.
  - paulmd 3y ago
    one general problem with this (and also audit logging) is making sure that such changes can't be rolled back. I think the consensus the last time I looked at it was to do it in a separate connection or batched at the end of the main transaction. but audit logging is just such a tremendous pain in general and everyone's got their own specific requirements. I think in general you would not want to do this in the database anyway (definitely not unless it's sharded and not really even then). You are taking that hashing load off your application servers and moving it inside the DB after all. When your DB is out of CPU, it's out, they're tough to scale. And in SQLite you are holding the DB write lock for longer, which serializes every other thread that needs to write. That's also true of holding connections/resources in traditional DBs. It's notionally fine for toy problems and you can probably do "clever" shit like sharding uuids across multiple files by hash to scale a bit further. But increasingly, even as someone who likes the idea of a "richer" interface to RDBMS, and doesn't mind writing SQL functions/triggers/views where it makes sense, I think the database really just not is the place for unnecessary gizmos on performance grounds either. Don't put hashing in your DB.
oliwarner 3y ago
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. And I mean that. Software security starts with acknowledging that data is toxic and will bankrupt you if you refuse to respect it.
- civilized 3y ago
  Many people in positions of great responsibility don't do what they should. What do we do about that?
  - oliwarner 3y ago
    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.
    - civilized 3y ago
      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.
      - oliwarner 3y ago
        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.
_heimdall 3y ago
What is the attack vector this protects against though? If the authentication flow is doing anything other than salting/hashing the password and then throwing away the original plaintext password, the entire system really shouldn't be used at all.
- civilized 3y ago
  It (partially) protects against the attack vector in which the system was badly coded and simply does not do what everyone with basic competency insists all systems must do. I strongly suspect that this is the most common attack vector in cybersecurity.
jchw 3y ago
I disagree. It may seem good on paper, but it gives you too much of a false sense of security. Security measures like this often seem to work, but they are papering over a deeper problem. Usually this is being done because user input is not being handled carefully, and if so, the assumption that blocking some keywords "defangs" potential exploits is usually easy to prove false. Consider the case of eBay and JSFuck[1]. I dislike the mentality that leads to this; WAFs, lazy pentesting and compliance checkboxes have created a substantial body of absolute bullshit security theater and I have absolutely zero doubt that this has convinced companies it's "safe" to put insanely poorly written software partially out on the open internet and that they've "done their due diligence" so to speak. And then I get a letter in the mail apologizing that my most confidential information has yet again been leaked by some company I barely or didn't have any real choice to give my data to. I'm sure they all care deeply about my data and that's why it was stolen using decades-old Java serialization library vulnerabilities. [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-to-severe-vulnerability/ https://blog.checkpoint.com/research/ebay-platform-exposed-t...
- civilized 3y ago
  A lot of critical responses here are saying "this distracts from getting people to do the right thing". I'm open to that, but what is the plan for forcing organizations that are doing the wrong thing to do the right thing? We're talking about businesses that mismanage the sensitive data of millions of people. "They should be doing things right" doesn't seem like an adequate response to this situation.
  - jchw 3y ago
    Correct, we should be legally enforcing that they do the right thing, with legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers through sheer incompetence. The problem is that WAF-style security-theater is being enshrined as the industry standard instead, which means that we're just going to get more of these problems instead of less. In other words, a half-measure like this doesn't just distract from doing the right thing, it's actually literally useless for any real security, and instead it's more likely to allow serious security issues to go unnoticed for a much longer period of time.
zzyzxd 3y ago
I find this to be a common defense in depth trap. A lot of engineering effort get threw at the wrong layer, when the problem can be much more efficiently solved on another layer. It renders the whole organization working in fear -- When you have to worry about the system inserting password in plaintext into a database table, there are also a million other terrible things that can go wrong in this system, like what if your DBA copy-paste a SQL from stackoverflow? There's just endless work. If your org has incompetence engineers, then maybe just don't let them implement their own authentication system. Use popular open source frameworks and/or buy a commercial product.
jknoepfler 3y ago
An unhashed, unsalted password should literally never touch a database. Which is to say this kind of sanitization on passwords is meaningless if the barest of security standards are in place.
vldr 3y ago
https://xkcd.com/463/ https://xkcd.com/463/

wongarsu 3y ago

If an organization has such a password policy, that can be interpreted as the person in charge of setting this policy thinks their organization doesn't have enough people with the competence and organizational power to prevent SQL injection vulnerabilities. Which would reflect poorly on any institution, but especially a university (which should be a bastion of people with competence and organizational power). As for common password advise, my take on your argument would be that we should all be using these keywords in our passwords to quickly surface these bugs, lest they be hidden and only used by attackers.

patrakov 3y ago
It can be interpreted as you suggest, but does not necessarily come from the person in charge. It might mean that auditors forced the installation of a WAF because of $REGULATIONS (irrespective of the actual code quality) and refused to allow weakening the rules for password fields. EDIT: as they don't actually check for all the banned strings, the "auditor + mandatory misconfigured WAF" hypothesis expressed above is not valid in this case. But let it stay as an otherwise-plausible explanation, or maybe something that was valid in the past.
- wongarsu 3y ago
  The WAF hypothesis still holds if you assume the password change page is governed by the same WAF. The WAF would reject any new password it finds offensive, and the "rule" about not using certain SQL keywords just matches people's fuzzy understanding of why these passwords are rejected. It was probably even true, a couple WAF rule updates ago.
civilized 3y ago
Counterpoint - however pathetic it may be, it's better that they publicly owned up to their lack of confidence in this way. The question is, what do we do about it once we see something like that?
- wkat4242 3y ago
  > The question is, what do we do about it once we see something like that? Run away and stay as far away from their products and services as possible.
  - danesparza 3y ago
    It's a university
    - wkat4242 3y ago
      Ok don't go there to study CS :)
SoftTalker 3y ago
> especially a university (which should be a bastion of people with competence and organizational power) Generally the opposite. University staff positions pay pretty poorly compared to what the most competent people can earn elsewhere. There are some bright staff people at universities who are there for other reasons besides the pay, but the competence of an average university staff software developer is not great. This is also why over the past two decades universities have trended to SaaS subscriptions rather than building software in-house
- cbsmith 3y ago
  Yeah, there's very much a "cobbler's children have the worst shoes" aspect of this that some people don't get.
mkl 3y ago
> especially a university (which should be a bastion of people with competence and organizational power). Those people are not the ones running the IT systems. Even the software engineering and information systems departments have no say. IME university IT are understaffed, outsource a lot (often without a choice), and often have to follow decrees from higher management that don't seem to have been thought through.

ipython 3y ago

But why would you ever send a plaintext password into a sql query?

civilized 3y ago
Because you are lazy, irresponsible, and/or incompetent.
AndroTux 3y ago
Or anywhere else except a hash function for that matter?
petee 3y ago
Since being clever is often a footgun, I'll admit to one idea I had years ago; I never really gave it the smell test, and it only existed for a personal project. But if one person thought of it, others may have as well. I was learning to write sqlite C functions for fun, and thought since storing plain passwords has been such an issue, why not offload the responsibility from the programmer and let the db handle it fully -- consume plaintext, salt, hash, etc, and could transparently upgrade algorithms when necessary. Luckily I've learned enough to recognize that my skillset is not of the level necessary to fully evaluate the risks. Today the idea makes me feel uncomfortable.
- paulmd 3y ago
  one general problem with this (and also audit logging) is making sure that such changes can't be rolled back. I think the consensus the last time I looked at it was to do it in a separate connection or batched at the end of the main transaction. but audit logging is just such a tremendous pain in general and everyone's got their own specific requirements. I think in general you would not want to do this in the database anyway (definitely not unless it's sharded and not really even then). You are taking that hashing load off your application servers and moving it inside the DB after all. When your DB is out of CPU, it's out, they're tough to scale. And in SQLite you are holding the DB write lock for longer, which serializes every other thread that needs to write. That's also true of holding connections/resources in traditional DBs. It's notionally fine for toy problems and you can probably do "clever" shit like sharding uuids across multiple files by hash to scale a bit further. But increasingly, even as someone who likes the idea of a "richer" interface to RDBMS, and doesn't mind writing SQL functions/triggers/views where it makes sense, I think the database really just not is the place for unnecessary gizmos on performance grounds either. Don't put hashing in your DB.

oliwarner 3y ago

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. And I mean that. Software security starts with acknowledging that data is toxic and will bankrupt you if you refuse to respect it.

civilized 3y ago
Many people in positions of great responsibility don't do what they should. What do we do about that?
- oliwarner 3y ago
  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.
  - civilized 3y ago
    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.
    - oliwarner 3y ago
      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.

_heimdall 3y ago

What is the attack vector this protects against though? If the authentication flow is doing anything other than salting/hashing the password and then throwing away the original plaintext password, the entire system really shouldn't be used at all.

civilized 3y ago
It (partially) protects against the attack vector in which the system was badly coded and simply does not do what everyone with basic competency insists all systems must do. I strongly suspect that this is the most common attack vector in cybersecurity.

jchw 3y ago

I disagree. It may seem good on paper, but it gives you too much of a false sense of security. Security measures like this often seem to work, but they are papering over a deeper problem. Usually this is being done because user input is not being handled carefully, and if so, the assumption that blocking some keywords "defangs" potential exploits is usually easy to prove false. Consider the case of eBay and JSFuck[1]. I dislike the mentality that leads to this; WAFs, lazy pentesting and compliance checkboxes have created a substantial body of absolute bullshit security theater and I have absolutely zero doubt that this has convinced companies it's "safe" to put insanely poorly written software partially out on the open internet and that they've "done their due diligence" so to speak. And then I get a letter in the mail apologizing that my most confidential information has yet again been leaked by some company I barely or didn't have any real choice to give my data to. I'm sure they all care deeply about my data and that's why it was stolen using decades-old Java serialization library vulnerabilities. [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-to-severe-vulnerability/ https://blog.checkpoint.com/research/ebay-platform-exposed-t...

civilized 3y ago
A lot of critical responses here are saying "this distracts from getting people to do the right thing". I'm open to that, but what is the plan for forcing organizations that are doing the wrong thing to do the right thing? We're talking about businesses that mismanage the sensitive data of millions of people. "They should be doing things right" doesn't seem like an adequate response to this situation.
- jchw 3y ago
  Correct, we should be legally enforcing that they do the right thing, with legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers through sheer incompetence. The problem is that WAF-style security-theater is being enshrined as the industry standard instead, which means that we're just going to get more of these problems instead of less. In other words, a half-measure like this doesn't just distract from doing the right thing, it's actually literally useless for any real security, and instead it's more likely to allow serious security issues to go unnoticed for a much longer period of time.

zzyzxd 3y ago

I find this to be a common defense in depth trap. A lot of engineering effort get threw at the wrong layer, when the problem can be much more efficiently solved on another layer. It renders the whole organization working in fear -- When you have to worry about the system inserting password in plaintext into a database table, there are also a million other terrible things that can go wrong in this system, like what if your DBA copy-paste a SQL from stackoverflow? There's just endless work. If your org has incompetence engineers, then maybe just don't let them implement their own authentication system. Use popular open source frameworks and/or buy a commercial product.

jknoepfler 3y ago

An unhashed, unsalted password should literally never touch a database. Which is to say this kind of sanitization on passwords is meaningless if the barest of security standards are in place.

vldr 3y ago

https://xkcd.com/463/ https://xkcd.com/463/