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

151–160 of 254 posts

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

#151

Post by cbsmith »

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…

It's okay to demand competence, but I wouldn't expect competence to materialize overnight.

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

#152

Post by danesparza »

wkat4242 wrote: post #132
civilized wrote: post #77

Earlier quoted context omitted.

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.

It's a university

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

#154

Post by runlaszlorun »

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.

That’s hilarious. And why I love HN.

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

#155

Post by cookiengineer »

berkes wrote: post #9
Retr0id wrote: post #3

Optimistically, perhaps this requirement stems from an overzealous WAF

That, or some poorly architectured "framework" or toolkit. Others in the comments see this as "proof" that the application has poor security. I don't think we can draw that conclusion. We can, however, draw the conclusion that some part of the stack is poorly implemented.

You can just try out some || concated strings and an or statement to verify the lack of security. It's not like it's a secret how to do SQL injections in 2024.

Bypassing this kind of filter is literally the second picoCTF SQL injection level, which is intended for high school STEM students.

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

#156

Post by oliwarner »

cbsmith wrote: post #150
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.

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

It might be a method to avoid trigger an overenthusiastic WAF, but these are all SQL tokens and keywords. It seems far more likely that they've blocked them in a desperate effort to catch injection attacks.

There might not be an actual attack vector, they might block these words in all inputs. It just smells like incompetence.

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

#157

Post by actuallyalys »

lucb1e wrote: post #64
amne wrote: post #33

still better than "password used by another account"

Not sure if serious. We need this. If you can guess someone else's password by accident, both of you need a password reset and that password needs to go on the denylist. Modern advice for strong passwords is having a length requirement and checking the input against a list of known passwords, for example using the HIBP partial hash API. (Any time you see forced expiration or complexity requirements, you're dealing wi…

The safe way to do this is to check a password against a list of common passwords, as Jeff Atwood suggests [0] rather than against your other passwords. As other replies point out, you shouldn’t be able to compare your passwords’ plaintext to each other like you’re proposing[1].

[0]: https://blog.codinghorror.com/the-god-login/

[1]: I suppose you could salt and hash the user’s password against every other user’s password and their salt, but if you chose an appropriate password hash function and parameters, that would take infeasibly long.

Edit: I missed that you essentially suggested this already. Sorry about that. However, I think the way Atwood explains it is useful.

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

#158

Post by MathMonkeyMan »

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…

At work, we were discussing how to serialize some structured data as an HTTP request header value. I reflexively said "ascii subset of JSON without newlines," but that was rejected for some reasons (maybe too much punctuation, verbose for Chinese...). Someone came up with pipe-separated fields, but then that was rejected too. The reason was something like "some customers used to have proxies that would reject any headers that include a pipe character."

My point is that voodoo programming isn't always due to lack of due diligence. It's due to knowing that something went wrong with something in the past, but for which there is no evidence, and about which you would be able to do nothing.

My preference is to deploy it anyway, see if it breaks, and if necessary work it out with the customer after the fact. That's unpopular for good and obvious reasons, so no pipe characters.

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

#159

Post by hamburglar »

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…

You realize, don’t you, that the fact that this made the front page tells us that you are explaining things that are obvious to this audience?

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

#160

Post by actuallyalys »

duskwuff wrote: post #139
Falmarri wrote: post #121

Earlier quoted context omitted.

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.

I wonder if there’s some way to mitigate this by either only keeping the uniqueness database long enough to identify duplicates and then deleting it or by using this on lower priority systems that people may reuse passwords from for your higher security one. In either case, the small number of bad passwords you would identify that you couldn’t come up with yourself or find on common password lists probably makes this a bad tradeoff.
Post reply on HN