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

241–250 of 254 posts

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

#241

Post by pixl97 »

junon wrote: post #32
graemep wrote: post #27

Earlier quoted context omitted.

It is also very common not to do things right. https://www.bbc.com/future/article/20160325-the-names-that-b... That article is a few years old now and things should have got better, but even by 2016 everyone should have known properly sanitising inputs was critical for a decade or two.

Right but that's not really an excuse not to do them right.

You're working at the premise backwards...

One of the systems is already wrong. The excuse not to do the system right is monetary cost of fixing the broken system.

Out of all the excuses in the world, money wins.

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

#242

Post by pixl97 »

donohoe wrote: post #53

Would be better if they provided a drop-down list of safe passwords to use. A pre-defined choice of 12 should be enough.

Heh, reminds me of the kid safe chats that used to exist more in the past where you could only select from a limited dictionary of words to make sentences. People still found a way to say some pretty terrible things.

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

#244

Post by junon »

pixl97 wrote: post #241
junon wrote: post #32

Earlier quoted context omitted.

Right but that's not really an excuse not to do them right.

You're working at the premise backwards... One of the systems is already wrong. The excuse not to do the system right is monetary cost of fixing the broken system. Out of all the excuses in the world, money wins.

EDIT: responded to the wrong comment, apologies.

I really don't understand your point. If I hash on the browser the hash is still being sent to the server. A MitM or sniffing attack can just send the hash and log in. It doesn't actually protect the user at all unless they're re-using the password elsewhere. This also assumes that you're using a seeded hash of some sort, or a multi-round hasher with settings unique to every other website. Otherwise you're still going to run into stuffing and collisions.

So for sites where the plaintext password is sensitive (password managers etc) that's important. For most sites, it's not inherently wrong not to hash passwords in the browser, though it does protect against password reuse.

I'm not saying you're wrong, I just don't think you're accurately portraying the problem you're fixing.

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

#245

Post by Wingy »

duskwuff wrote: post #171
Wingy wrote: post #167

Earlier quoted context omitted.

Hashing can be done in a stored procedure. Maybe the organization decided that it's better for the DBA to handle hashing. Nonstandard maybe but not necessarily bad.

> Hashing can be done in a stored procedure. [...] Nonstandard maybe but not necessarily bad. No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the pa…

That's true, the hashing should definitely be done as early as possible.

"As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash digests are) character strings on the server as a password equivalent. This would also protect from a misconfigured or malicious server logging unhashed passwords.

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

#246

Post by duskwuff »

Wingy wrote: post #245
duskwuff wrote: post #171

Earlier quoted context omitted.

> Hashing can be done in a stored procedure. [...] Nonstandard maybe but not necessarily bad. No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the pa…

That's true, the hashing should definitely be done as early as possible. "As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash dige…

> It could be done on the client

No, that's actually too early -- if you let the client hash the password, you're vulnerable to a "pass-the-hash" attack where the client submits a hash without knowing the password.

There are protocols like SRP and other PAKEs which allow this to be done securely, but it's uncommon for them to be used in web applications.

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

#247

Post by Wingy »

duskwuff wrote: post #246
Wingy wrote: post #245

Earlier quoted context omitted.

That's true, the hashing should definitely be done as early as possible. "As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash dige…

> It could be done on the client No, that's actually too early -- if you let the client hash the password, you're vulnerable to a "pass-the-hash" attack where the client submits a hash without knowing the password. There are protocols like SRP and other PAKEs which allow this to be done securely, but it's uncommon for them to be used in web applications.

My reasoning was that if you can capture the hash, you could have also captured the password but that doesn't account for a situation where the database is compromised.

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

#248

Post by berkes »

cookiengineer wrote: post #155
berkes wrote: post #9

Earlier quoted context omitted.

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.

Yrs. But you presume that these password rules are there for security. I'm saying they are there because some part of the stack is stupid.

I'm quite certain you cannot breach security like that, but that some (ancient) piece of the stack has some hardwired rules, which, at some point, might indeed be a "defence against injection". But this is no proof that this is still the case.

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

#249

Post by berkes »

duskwuff wrote: post #137
eddd-ddde wrote: post #94

Earlier quoted context omitted.

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

No, it isn't. If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.

Hashing is hardly ever done client side. Most often server side, which is fine, because it's not the same as "storing plain text".

In fact, if you rely on client side hashing, you are not only making the app a lot less accessible (it will only work with JS enabled), the security is worse, because now you are publishing a salt to the client. Or you are working with unsalted hashes which is hardly better than just plain text.

SSL is what protects passwords in transit. Not some JavaScript client side hashing DIY.

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

#250

Post by thebiss »

selcuka wrote: post #205
nijave wrote: post #201

Earlier quoted context omitted.

Surely if you've resorted to blocking random SQL keywords you've already lost. SQL has a pretty big dialect not to mention arbitrary functions and procedures that might exist. For instance, TRUNCATE isn't even in the list

In real world, as a developer you can't control what IT uses for WAF, so you may have to work around it as much as you can. At a previous job the IT set up a spam filter which used a keyword list (dumb attempt anyway), but it also searched the email headers (not only the body). As a result, we weren't able to receive email if one of the SMTP hops was named, say, smtp.essex.company.com.

The infamous Scunthorpe problem.

https://en.wikipedia.org/wiki/Scunthorpe_problem

Post reply on HN