Live data from Hacker News

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

id.uni-lj.si

101–110 of 254 posts

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

#101

Earlier quoted context omitted.

Presumably you would apply the same sanitizer at login time to whatever password the user enters. If the input is the same and the transform is the same then the output will be the same. Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.

This relies on a false assumption that the sanitizer is static.

If we're to continue with this thought experiment in doing the dumb thing. Clearly you would version your sanitizer and store which version you used when saving the password. That way you can ensure the same version is used against future user inputs.

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

#102

Earlier quoted context omitted.

Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though

Could you describe it conceptually how they do it?

The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main...

I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound

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

#103
post #88
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.

How could the validation layer be affected by the presence of these substrings?

https://xkcd.com/327/

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

#105

All five words are also common English words found in any major dictionary. If you're not actually doing anything stupid with the passwords, all you have to do is use that same diagnostic for that situation: "password may not contain dictionary words". Then you don't have a diagnostic which raises red flags. That the developer is not aware that their diagnostic raises a red flag itself raises a red flag. It doesn't o…

Except this restriction effectively bans xkcd passes (4 random dictionary words)

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

#106

Perhaps their system is fine but this is a way to filter out people who are likely to try breeching the Uni security so they know who to watch? Or there's a ctf challenge for local security agencies...

A more efficient way to do that would be to flag people doing that to admins, not to tell them not to do it

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

#107

Earlier quoted context omitted.

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.

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.

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

#108
post #64
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 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

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

#109

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 find this to be a common defense in depth trap. A lot of engineering effort get threw at the wrong layer, when the problem can be much more efficiently solved on another layer.

It renders the whole organization working in fear -- When you have to worry about the system inserting password in plaintext into a database table, there are also a million other terrible things that can go wrong in this system, like what if your DBA copy-paste a SQL from stackoverflow? There's just endless work.

If your org has incompetence engineers, then maybe just don't let them implement their own authentication system. Use popular open source frameworks and/or buy a commercial product.

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

#110
post #52

All five words are also common English words found in any major dictionary. If you're not actually doing anything stupid with the passwords, all you have to do is use that same diagnostic for that situation: "password may not contain dictionary words". Then you don't have a diagnostic which raises red flags. That the developer is not aware that their diagnostic raises a red flag itself raises a red flag. It doesn't o…

That's not a reasonable requirement at all. A common recommendation nowadays is to have passphrases..

You're right; if the pass phrase has twenty random words, some of which are select or insert, then that's a bad diagnostic.
Post reply on HN