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

71–80 of 254 posts

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

#71

Post by oliwarner »

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.

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

#72

Post by AndroTux »

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?

Or anywhere else except a hash function for that matter?

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

#73

Post by d-z-m »

wongarsu wrote: post #63
hiatus wrote: post #41

Earlier quoted context omitted.

How would a WAF do its job if it can't see the request payload?

There are various schemes where the password is salted, hashed or prehashed on the client side, to various effectiveness. They have never been really popular and the advent of ubiquitous https probably made them even less common, but they do exist. They do help protect you from your own WAF though.

can you elaborate on this? Or link something that does? My intuition is that whatever gets sent over the wire is effectively the password. Not sure how the server could validate some rolling hash of the password (based on like a timestamp or something) without having to store the pre-image(i.e. the raw password).

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

#74

Post by wongarsu »

patrakov wrote: post #67
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…

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…

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.

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

#76

Post by jesprenj »

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.

WAF always sees unhashed passwords -- passwords are sent TLS encrypted in a POST body (unhashed) and are hashed by the server software -- and that's regardless of the password policy.

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

#77

Post by civilized »

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…

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?

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

#78

Post by civilized »

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.

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

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

#79

Post by anoopelias »

lucb1e wrote: post #54
dmd wrote: post #44

Earlier quoted context omitted.

Nope - that's not a valid ldap URL - or even a valid domain, for that matter. Domains can only contain the ascii leters a-z and the digits 0-9 -- asterisks are not permitted; the only symbol permitted is a hyphen (and it cannot start or end with one).

It's a log4shell reference

Plus the hunter2[1] reference too..

[1]https://www.reddit.com/r/OutOfTheLoop/comments/1zaefg/why_do...

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

#80

Post by _heimdall »

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…

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.

Post reply on HN