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

141–150 of 254 posts

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

#141

Post by civilized »

oliwarner wrote: post #138
civilized wrote: post #114

Earlier quoted context omitted.

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

It's not that I think it's acceptable. I'm thinking about how to reduce the harm of people doing unacceptable things that we can't stop them from doing. I would be very transparent about this. I would say this is harm reduction for people who are doing the wrong thing and is a waste of everyone else's time, but we have to do it anyway because software engineering has failed to govern itself as a profession and the government has failed to hold it accountable for its disasters.

The key thing is that it's both easy to test and would stop many attacks. Anyone can check whether the password field will take these forbidden keywords and patterns.

No question it's a pathetic thing to have to resort to, but pathetic is where things are at right now.

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

#143

Post by jrockway »

wkat4242 wrote: post #127

Instead of making sure SQL injection is not possible at all by using proper stored procedures and other techniques, they just limit a few keywords and hope hackers don't come up with something that they haven't thought of like some escaping trick. Yeah that would probably work for a while. Until someone proves it doesn't :P It's not really rocket science anymore to make sure user input doesn't mix with your SQL. This…

I think it was early 2005 when I wrote my first database app, and I didn't find it that hard to not mix user data with SQL. (I think I even ran my CGI script in "taint mode". Remember that!?)

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

#145

Post by account-5 »

matsemann wrote: post #56

Can not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..

That's easy, they should have just removed the angle brackets, job done.

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

#146

Post by cbsmith »

matejn wrote: post #85

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management. I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

I love that you actually posted here.

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

#147

Post by cbsmith »

SoftTalker wrote: post #128
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…

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

Yeah, there's very much a "cobbler's children have the worst shoes" aspect of this that some people don't get.

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

#149

Post by mkl »

wongarsu wrote: post #46
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…

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…

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

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

#150

Post by cbsmith »

oliwarner wrote: post #71
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…

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.

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

Post reply on HN