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

91–100 of 254 posts

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

#91

Post by petee »

ipython wrote: post #61
civilized wrote: post #35

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…

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

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.

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

#92

Post by avgcorrection »

lucb1e wrote: post #58
wmil wrote: post #38

Earlier quoted context omitted.

They'll probably use the disclamer as an excuse to blame you if something breaks.

"... killed, or worse, expelled!" ( https://www.quotes.net/mquote/41411 ) Seriously though, I doubt there would be any consequences even if some BOFH tried to blame you

I had a pause when saw that the TLD is `si`. But then I found out that it’s just Slovenia.

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

#93

Post by simion314 »

bazzargh wrote: post #45
simion314 wrote: post #8

A few years ago I was working on some app that would use Wordpress API to post stuff. The customers had their own WP installation on various hosting with various "security" features. We had bug reports where posting to the blog failed and would post empty content, this security plugins would scan a big blog post and if it would find something like ".... select from " it would replace that POST parameter with an empty…

we had one a while back where a small number of requests were failing for a particular set of pages. We first spotted that all the urls contained 'select' (generally as part of a parameter name, like itemselect), so I went digging for WAF-like filters anywhere in the stack. I found that we had some ancient config in a proxy server from before we used a commercial waf that looked for `SELECT.*UNION` ... flicked back t…

Yeah, the hard part is when you do not control the server, so you need to tell your customer to contact their costing and fix the issue, sometimes we got the id of the security rule that triggered the issue but not all the time.

This security products feel like a scam.

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

#94

Post by eddd-ddde »

mikkom wrote: post #26
junon wrote: post #13

Earlier quoted context omitted.

I mean, this is a gross misunderstanding of how user input makes its way into a database safely. If you're putting out error messages like this it's a giant red flag.

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

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

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

#95

Post by oliwarner »

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?

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.

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

#98

Post by civilized »

oliwarner wrote: post #95
civilized wrote: post #78

Earlier quoted context omitted.

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

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

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.

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

#99

Post by hn_acker »

sevensevennine wrote: post #20
ajross wrote: post #7

Earlier quoted context omitted.

> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.

Don't hash the password on the client. That just changes the password to the hash of the password. Parameterize the SQL on the server instead of concatenating strings.

If you're using a third-party reverse proxy, then the third party will have access to the user's password. What's the simplest way to prevent the third-party from knowing the password? Would adding an encryption layer between the user and the actual website owner be both feasible and sufficient for the average website owner?

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

#100

Post by jchw »

civilized wrote: post #35

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…

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

Post reply on HN