16 ms·
Password may not contain: select, insert, update, delete, drop
- Retr0id 3y agoOptimistically, 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.
- mysterydip 3y agoObligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.
- tester756 3y agoActually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree composition
- skottk 3y agoParameterized SQL is your friend here.
- mysterydip 3y agoYeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.
- dylan604 3y agoBefore Parameterized SQL was a thing, sanitizing was the thing. There’s a lot of escape_string() type of methods out there.
- hobs 3y agoYou don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.
- tester756 3y ago
- seydor 3y agodrop database users; truncate table posts;
- moogly 3y agoThat's fine. I'll just use `truncate` instead.
- simion314 3y agoA few years ago I was working on some app that would use Wordpress API to post stuff. The customers had their own WP installation on various hosting with various "security" features. We had bug reports where posting to the blog failed and would post empty content, this security plugins would scan a big blog post and if it would find something like ".... select <a few paragraphs of text> from " it would replace that POST parameter with an empty string. Also seen similar stuff on a customer bug report, where request from our server containing html text inside a json field would get injected with some obfuscated javascript, I could not be sure if it was a "security" plugin or malware.
- bazzargh 3y agowe had one a while back where a small number of requests were failing for a particular set of pages. We first spotted that all the urls contained 'select' (generally as part of a parameter name, like itemselect), so I went digging for WAF-like filters anywhere in the stack. I found that we had some ancient config in a proxy server from before we used a commercial waf that looked for `SELECT.*UNION` ... flicked back to the URLs and found they'd all also all had a parameter like 'company=credit+union'. Facepalm, and ripped the code out, we had plenty of protection elsewhere
- simion314 3y agoYeah, the hard part is when you do not control the server, so you need to tell your customer to contact their costing and fix the issue, sometimes we got the id of the security rule that triggered the issue but not all the time. This security products feel like a scam.
- chasil 3y agoDid someone have a Bobby Tables moment? https://bobby-tables.com/ https://bobby-tables.com/ In Oracle, you can't use a bind variable in setting a password on an account, so SQL injection is a more significant risk. I wrote some JavaScript and pl/sql to address that.
- javitury 3y agoI hope that javascript filter runs on the server and not on the web browser...
- chasil 3y agoThe php runs on the server, and does the same thing. The JavaScript posts excessive status messages, and only allows a submit when all checks have passed.
- Falmarri 3y agoDo you mean setting a database user account? As in the oracle user? Why is that exposed over the web?
- SoftTalker 3y agoThere is/was a school of thought that each user should have their own database account, and the application should connect to the database as that user. The advantage being you can use the database's built-in user and role management and privileges instead of having to invent your own. I have admittedly not seen this done much, but there is a certain appeal to it.
- d0gsg0w00f 3y agoI work for a company that is trying to bolt this functionality onto all the AWS database products. At least at the IAM role level. As it stands now, no human can write to a DB in prod-- only service accounts.
- turminal 3y agoThe funniest part of this is that they don't even check for all of the banned strings. Source: I'm a student there and tried it out of curiosity.
- wmil 3y agoThey'll probably use the disclamer as an excuse to blame you if something breaks.
- lucb1e 3y ago"... killed, or worse, expelled!" (https://www.quotes.net/mquote/41411 https://www.quotes.net/mquote/41411) Seriously though, I doubt there would be any consequences even if some BOFH tried to blame you
- avgcorrection 3y agoI had a pause when saw that the TLD is `si`. But then I found out that it’s just Slovenia.
- elevatedastalt 3y agoIt's easy to ensure compliance when the risk of non-compliance is getting expelled.
- julienreszka 3y agoFor people wondering how to do this properly it's called parametrized queries.
- readthenotes1 3y agoYou mean storing plain text passwords in a database is safe?
- sevensevennine 3y agoAbsolutely right-- the warning is only necessary if they're not hashing the password before templating the string prior to storage.
- dylan604 3y agoNaturally. You just use a different name for that field than password, and the hackers will never know! /s
- da768 3y agoyou could still hope it's a WAF issue or they're hashing passwords through the database query, though both unlikely
- kazinator 3y agoAll 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 occur to them that a system which issues this diagnostic will be suspected of doing stupid things. That tends to betray a lack of sophistication in the area of security.
- ylyn 3y agoThat's not a reasonable requirement at all. A common recommendation nowadays is to have passphrases..
- kazinator 3y agoYou're right; if the pass phrase has twenty random words, some of which are select or insert, then that's a bad diagnostic.
- nephanth 3y agoExcept this restriction effectively bans xkcd passes (4 random dictionary words)
- amne 3y agostill better than "password used by another account"
- lucb1e 3y agoNot 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 with a legacy/cargocult system.)
- dragonmost 3y agoThe 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
- Falmarri 3y agoYou 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
- duskwuff 3y agoThat 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.
- actuallyalys 3y agoI 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.
- walrus01 3y agoUntil very recently the online banking password for a major (big-5) Canadian bank couldn't be longer than 9 characters or contain ANY special punctuation characters from the ASCII code set. It was very clear that they're storing them in plaintext in a database on some archaic mainframe somewhere.
- jesprenj 3y agoSlovenian bank (NKBM) only permits 6 digit passwords and nothing else -- probably so that users can dial them via DTMF when on the phone.
- civilized 3y agoI 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 coded websites, e.g. your local healthcare provider. In such cases, it might be better if we assumed the implementation might be as awful as it commonly is, and recommended mitigations based on that. It's also easy for people to test if the website actually allows the nominally prohibited password patterns and complain to some oversight authority if so. Whereas it's not so easy to test, from the outside, whether it's really been done the right way. It's inelegant and tragic, but in the end it might be a good idea to accept that things are often done poorly and without adequate oversight, and consider what mitigations can prevent the worst outcomes in these cases.
- wongarsu 3y agoIf 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 common password advise, my take on your argument would be that we should all be using these keywords in our passwords to quickly surface these bugs, lest they be hidden and only used by attackers.
- patrakov 3y agoIt 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 not valid in this case. But let it stay as an otherwise-plausible explanation, or maybe something that was valid in the past.
- ipython 3y agoPhew. They’ll never catch me. My password is ${jndi:ldap://hunter2.com/totallylegit}
- dmd 3y agoNope - 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).
- lucb1e 3y agoIt's a log4shell reference
- dmd 3y agoBut you missed the actual joke.
- lucb1e 3y agoIndeed. I wasn't sure if you weren't aware of the log4shell reference or if I was majorly missing your point. The latter, then!
- anoopelias 3y agoPlus the hunter2[1] reference too.. [1]https://www.reddit.com/r/OutOfTheLoop/comments/1zaefg/why_does_everyone_respond_hunter2_when_people/ https://www.reddit.com/r/OutOfTheLoop/comments/1zaefg/why_do...
- avgcorrection 3y agoI want more innovation in the password requirement genre: Your password must be valid SQL, Java, Go, or C++ string. Or a haiku about grocery shopping. This way it won’t look like a password in case we leak it.
- wongarsu 3y agoIt's pretty common to force usernames to be valid C or Pascal identifiers (only letters digits and underscores, first character can't be a digit). So why not extend the reasoning to passwords. /s
- donohoe 3y agoWould be better if they provided a drop-down list of safe passwords to use. A pre-defined choice of 12 should be enough.
- pixl97 3y agoHeh, 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.
- matsemann 3y agoCan not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including <script>. I instead wrote <scr<script>ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..
- i_k_k 3y agoWell, duh: they needed to make sure to run the script twice.
- ht85 3y agoMake it 3 times, you never know how clever those hackers folks could be!
- matheusmoreira 3y agoMake it infinite times and stop after the output stabilizes to a constant string!
- kevincox 3y agoI think this is actually a correct solution. Although not particularly elegant or efficient. If as long as if the string is unsafe the string will be modified. Then looping infinitely will never return an unsafe string. If it is also true that the modifications only delete characters then you will eventually arrive at a safe (or empty) string.
- qingcharles 3y agoLOL. I did the same thing with a Coca-Cola site and their MD wrote me a nasty letter and removed my account.
- alanfranz 3y agooldest injection trick ever :-)
- dathinab 3y agothe only place situation where such rules can matter is if you already _massively_ messed up security (most fundamental rule of handling passwords is to never store them anywhere, never log them either, b etc. they should go straight to the hashing function and no where else)
- strken 3y agoIt matters if your stupid WAF blocks anything that looks like SQL.
- pbhjpbhj 3y agoPerhaps 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...
- nephanth 3y agoA more efficient way to do that would be to flag people doing that to admins, not to tell them not to do it
- OscarCunningham 3y agoI've heard people being told 'sanitize your inputs!' too many times. The advice should be 'escape your outputs!'.
- JanisErdmanis 3y agoAlso, don’t use eval on your inputs, but instead make proper endpoints.
- matejn 3y agoOooh! 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.
- deleted 3y ago[deleted]
- cbsmith 3y agoI love that you actually posted here.
- runlaszlorun 3y agoThat’s hilarious. And why I love HN.
- 0x00_NULL 3y agoOn the contrary, make all of your passwords “DROP TABLE users;”. You’ll quickly sort out which passwords are being handled so insecurely by your vendors. This would mean they both don’t sanitize user input and don’t hash or otherwise obscure your password. They are a menace to society.
- jesprenj 3y agoAFAIUC, the reason for the word blacklist here lies in the fact that some applications have WAFs or similar software that detect malicious requests and since passwords are sent in plaintext to the WAF, they are detected as malicious exploitation attempts, if they imitate SQL injections, although your parent comment did not give any concrete examples.
- iforgotpassword 3y ago"malicious" requests in this case. I actually dealt with a contact form of a health insurance company that had something like this going on, but there wasn't any error page showing up, you just got a blank page after submit if something resembled SQL. In my case it was the words "select" and "from" too close to each other in a sentence.
- beardyw 3y agoThis admits they are updating the database wrong and storing the password wrong.
- KevinMS 3y agomaybe they just got sick of script kiddies bloating their users table with lame hacking attempts. This might discourage them.
- josephcsible 3y agoApparently someone read https://thedailywtf.com/articles/Injection_Rejection https://thedailywtf.com/articles/Injection_Rejection and didn't realize that it wasn't a best practice.
- amluto 3y agoOff the top of my head, they forgot MERGE INTO, which is supported by several major databases. Also ALTER, GRANT, SET, and probably many others. This particular variant of defense in depth is also rather missing the point: this field is a password. The question isn’t “did everyone remember to properly escape the password or properly use parameter binding” — the question is “did everyone remember not to store the plaintext password?” By the time someone does: Execute(“UPDATE xyz SET abc = ?”, password) Or however your database API spells it, you have already messed up massively.
- dboreham 3y agoAnd definitely don't register the vanity vehicle license plate "NULL".
- wkat4242 3y agoInstead 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 is not 2005. And really if this works in the first place you're storing the passwords unhashed which was even a dumb thing in 2005. If the same applies to the username or other user input fields it would make a bit more sense but passwords should never enter the database like that.
- jrockway 3y agoI think it was early 2005 when I wrote my first database app, and I didn't find it that hard to not mix user data with SQL. (I think I even ran my CGI script in "taint mode". Remember that!?)
- MathMonkeyMan 3y agoAt 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.
- hamburglar 3y agoYou 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?
- 3y ago
- neom 3y agoFor those who don't feel like clicking around to learn more: It's the student identity management portal for the University of Ljubljana in Slovenia.
- tkems 3y agoThis sounds like a hold-over from an older system. I've heard stories of certain universities and banks using old mainframe systems for central authentication. In one instance I've heard that passwords were stored in plaintext and truncated to 8 characters, uppercase only. The main reason, that I've heard at least, for not upgrading these systems is cost and complexity. Why upgrade a system that is working for $$$$ when we can restrict passwords and add some basic 'security' for $.
- jrockway 3y agoGood thing my password is ROLLBACK.
- Syzygies 3y agoA legendary xkcd: "Did you really name your son Robert'); DROP TABLE Students;-- ? https://xkcd.com/327/ https://xkcd.com/327/
- danesparza 3y agoAwww ... little Bobby tables!
- bitwize 3y agoBobby Tables: "Drat, foiled again!"
- throwawaaarrgh 3y agoWorked on a system like this once. Nobody wanted to fix the actual backend problem so this limitation was a requirement. But I figured that advertising these little "quirks" in the login flow would give hackers ideas, so instead I just added a function to transform the "bad input" into an alternative set of characters that wouldn't have a negative effect on upstream. Since you couldn't view the saved password, nobody realized they were being transformed behind the scenes. Stupid yet effective.
- knallfrosch 3y agoUntil someone builds out your transform
- kstrauser 3y agoI once couldn't register for a website because my last name contained the word "user". Yes, it does. Given the choice between changing my name, lying about my name, or signing up with a competitor instead, I chose the dignified option.
- cco 3y agoI work at an auth company (Stytch) and sometimes developers ask me about input restrictions on passwords in our API. I've had folks ask me if we support emoji, "code/SQL" like in this example, Chinese characters etc. So fun to see and hear from folks on all sorts of stacks, especially legacy systems where layers of cruft have accreted over time to produce Byzantine requirements like this.
- pierrekin 3y agoI was made to do this at work also. The reasoning went something like this. Yes of course we need to properly escape all strings that we render / use parametised queries to avoid injection attacks, however we also need defense in depth, so all fields need to reject code that looks like sql or html. It was easier to just add this that push back. Sigh.
- wly_cdgr 3y agoI don't see any downside here. It's just another layer of protection. So what if it's not sufficient?
- deleted 3y ago[deleted]
- Hippocrates 3y agoIf I were an adversary this would certainly pique my interest.
- rco8786 3y agoMakes me ponder the question - what’s the worst you could do to a sql database without using those strings (at least not directly). They don’t prohibit semi colons so there’s still some potential here.
- captain_bender 3y agoThere are a number of South Korean websites that allow us to use only ‘!, @, #, $, %, ^, &, *’. They still force people to include those characters, and the 'maximum' password length is like 20, sometimes 12.
- vldr 3y ago"extra security is good, though" https://xkcd.com/463/ https://xkcd.com/463/ (no not the bobby tables xkcd)
- butz 3y agoThey should add a list of passwords already used, you know, for security.