Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password may not contain: select, insert, update, delete, drop

id.uni-lj.si

Post reply on HN
Print view View original

131–140 of 254 posts

Re: Password may not contain: select, insert, update, delete, drop

#131

Post by SoftTalker »

Falmarri wrote: post #120
chasil wrote: post #10

Did someone have a Bobby Tables moment? https://bobby-tables.com/ In Oracle, you can't use a bind variable in setting a password on an account, so SQL injection is a more significant risk. I wrote some JavaScript and pl/sql to address that.

Do you mean setting a database user account? As in the oracle user? Why is that exposed over the web?

There is/was a school of thought that each user should have their own database account, and the application should connect to the database as that user. The advantage being you can use the database's built-in user and role management and privileges instead of having to invent your own. I have admittedly not seen this done much, but there is a certain appeal to it.

Re: Password may not contain: select, insert, update, delete, drop

#132

Post by wkat4242 »

civilized wrote: post #77
wongarsu wrote: post #46

Earlier quoted context omitted.

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…

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?

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

Re: Password may not contain: select, insert, update, delete, drop

#133

Post by x0x0 »

civilized wrote: post #78
oliwarner wrote: post #71

Earlier quoted context omitted.

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.

Many people in positions of great responsibility don't do what they should. What do we do about that?

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.

Re: Password may not contain: select, insert, update, delete, drop

#134

Post by wkat4242 »

turminal wrote: post #36
Retr0id wrote: post #3

Optimistically, perhaps this requirement stems from an overzealous WAF

That would imply WAF gets to see unhashed passwords, so not good at all.

These are SQL commands. The WAF would see the password unless you pre-hash it on the client side in JavaScript (not a bad idea). But the database really should never ever see the plaintext password. If it does you're doing a lot more wrong than just being open to SQL injection.

Re: Password may not contain: select, insert, update, delete, drop

#135

Post by tkems »

This sounds like a hold-over from an older system. I've heard stories of certain universities and banks using old mainframe systems for central authentication. In one instance I've heard that passwords were stored in plaintext and truncated to 8 characters, uppercase only.

The main reason, that I've heard at least, for not upgrading these systems is cost and complexity. Why upgrade a system that is working for $$$$ when we can restrict passwords and add some basic 'security' for $.

Re: Password may not contain: select, insert, update, delete, drop

#137

Post by duskwuff »

eddd-ddde wrote: post #94
mikkom wrote: post #26

Earlier quoted context omitted.

And top of that, password should NEVER be stored to database

It's normal for them to make it to an executed SQL query.

No, it isn't.

If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.

Re: Password may not contain: select, insert, update, delete, drop

#138

Post by oliwarner »

civilized wrote: post #114
oliwarner wrote: post #107

Earlier quoted context omitted.

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…

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?

Re: Password may not contain: select, insert, update, delete, drop

#139

Post by duskwuff »

Falmarri wrote: post #121
dragonmost wrote: post #108

Earlier quoted context omitted.

The server shouldn't even be able to know that a password is being reused as it should be hashed and salted there is no situation where this would be acceptable

You can hash them without a salt and store them in a set of passwords not associated to user accounts to enforce uniqueness without having to actually know the passwords

That still introduces a fairly serious vulnerability. The lack of salting on the "password uniqueness" database makes it a juicy target; an attacker with access to the database can attack those passwords, then try the ones which are known to be valid from there against the salted passwords in the user database.

Re: Password may not contain: select, insert, update, delete, drop

#140

Post by civilized »

jchw wrote: post #129
civilized wrote: post #118

Earlier quoted context omitted.

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.

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 p…

I agree with you about security theater. The only reason I'm favorable to this approach is because it seems to provide accountable harm reduction in this case. It would stop many typical attacks while being very easy for any random government bureaucrat to test compliance with.
Post reply on HN