4 ms·
Optimistically, perhaps this requirement stems from an overzealous WAF
by Retr0id 3y ago
Optimistically, perhaps this requirement stems from an overzealous WAF
- berkes 3y agoThat, 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.
- junon 3y agoI mean, this is a gross misunderstanding of how user input makes its way into a database safely. If you're putting out error messages like this it's a giant red flag.
- mikkom 3y agoAnd top of that, password should NEVER be stored to database
- junon 3y agoWell, not in plaintext.
- klyrs 3y agoThat's why you hash the password with an SQL built-in hash function. For security! But the password is still in plaintext inside the query so you can retrieve it from the logs for... security? (I joke, but 20 years younger me, self-teaching php and security etc? Who knows what she'd think of this)
- eddd-ddde 3y agoIt's normal for them to make it to an executed SQL query.
- duskwuff 3y agoNo, 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.
- Wingy 3y agoHashing 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.
- duskwuff 3y ago> 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 parameter in a process list. Worse, a stored procedure can potentially be covertly modified to store or exfiltrate the password while hashing it.
- junon 3y agoTo be clear, this only improves security if the user reuses passwords.
- Wingy 3y agoThat'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.
- graemep 3y agoIt is also very common not to do things right. https://www.bbc.com/future/article/20160325-the-names-that-break-computer-systems 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.
- deleted 3y ago[deleted]
- junon 3y agoRight but that's not really an excuse not to do them right.
- pixl97 3y agoYou'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.
- junon 3y agoEDIT: 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.
- deleted 3y ago[deleted]
- cookiengineer 3y agoYou 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.
- berkes 3y agoYrs. 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.
- g4zj 3y agoWhat does WAF stand for?
- dharmab 3y agoWeb Application Firewall
- amiljkovic 3y agoWeb Application Firewall
- thedougd 3y agoWeb application firewall It’s a reverse proxy that inspects requests for bad stuff like sql injection.
- deleted 3y ago[deleted]
- travoc 3y agoOne of the things that devs can blame when our app doesn’t work in production.
- turminal 3y agoThat would imply WAF gets to see unhashed passwords, so not good at all.
- hiatus 3y agoHow would a WAF do its job if it can't see the request payload?
- wongarsu 3y agoThere 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.
- d-z-m 3y agocan 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).
- wongarsu 3y agoYes, that's the common counter argument. Your hash has now just become the password, and no amount of clever salting really solves that. It still prevents the server (and any proxies, MitM attackers, etc) from seeing the plain-text password, which can help protect the user if they reused the password somewhere else. Assuming the client wasn't also compromised, which is very likely in web applications but maybe a valid scenario in apps and desktop applications. The other imho valid idea is that you can run a key derivation function client-side (e.g. salted with the user-name), in addition to running your normal best-practice setup server side. This can allow you to run more expensive key derivation which provides more protection if your database is leaked, while also making dictionary attacks on your authentication endpoints less viable.