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.
On 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.
I had an issue with one site where the maximum length on the "create new password" field was longer than the "maxlength" property on the input field for the login form. I couldn't figure out why I could use my password manager's autofill to login (since it ignored the maxlength), but couldn't type or paste my password in.
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..
Nettby had no HTTPS, so I did an ARP poisoning MITM and stole everybody's passwords. Then I posted random nonsense from people's accounts and watched the chaos ensue(did no snooping, even 14yo me had a semblance of ethics somehow).
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 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.
I disagree. It may seem good on paper, but it gives you too much of a false sense of security. Security measures like this often seem to work, but they are papering over a deeper problem. Usually this is being done because user input is not being handled carefully, and if so, the assumption that blocking some keywords "defangs" potential exploits is usually easy to prove false. Consider the case of eBay and JSFuck[1].
I dislike the mentality that leads to this; WAFs, lazy pentesting and compliance checkboxes have created a substantial body of absolute bullshit security theater and I have absolutely zero doubt that this has convinced companies it's "safe" to put insanely poorly written software partially out on the open internet and that they've "done their due diligence" so to speak. And then I get a letter in the mail apologizing that my most confidential information has yet again been leaked by some company I barely or didn't have any real choice to give my data to. I'm sure they all care deeply about my data and that's why it was stolen using decades-old Java serialization library vulnerabilities.
If 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.
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.
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.
What is the attack vector this protects against though?
If the authentication flow is doing anything other than salting/hashing the password and then throwing away the original plaintext password, the entire system really shouldn't be used at all.
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 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.
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.
I 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!?)
> And really if this works in the first place you're storing the passwords unhashed
Not really, your RDBMS probably supports some hash functions so you could be storing them hashed as "UPDATE USERS SET PASSWORD = SHA2($PASSWORD)" which would be vulnerable to SQL injection yet does not store unhashed passwords.
There are good reasons I'd recommend to do the hashing in the application layer instead, but doing it in the DB (with correctly parameterized queries, of course) is not so terrible.
Nope - 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).
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.
This 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 $.
A 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.
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.
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.
I 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.
the 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)
I 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.
I 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.
Worked 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.
Until 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.
There 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.
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 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.
[+] [-] matejn|2 years ago|reply
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.
[+] [-] 0x00_NULL|2 years ago|reply
[+] [-] aidenn0|2 years ago|reply
[+] [-] cbsmith|2 years ago|reply
[+] [-] runlaszlorun|2 years ago|reply
[+] [-] crumpled|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] matsemann|2 years ago|reply
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|2 years ago|reply
[+] [-] mtlmtlmtlmtl|2 years ago|reply
Nettby had no HTTPS, so I did an ARP poisoning MITM and stole everybody's passwords. Then I posted random nonsense from people's accounts and watched the chaos ensue(did no snooping, even 14yo me had a semblance of ethics somehow).
[+] [-] account-5|2 years ago|reply
[+] [-] alanfranz|2 years ago|reply
[+] [-] qingcharles|2 years ago|reply
[+] [-] counterpartyrsk|2 years ago|reply
[+] [-] civilized|2 years ago|reply
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.
[+] [-] jchw|2 years ago|reply
I dislike the mentality that leads to this; WAFs, lazy pentesting and compliance checkboxes have created a substantial body of absolute bullshit security theater and I have absolutely zero doubt that this has convinced companies it's "safe" to put insanely poorly written software partially out on the open internet and that they've "done their due diligence" so to speak. And then I get a letter in the mail apologizing that my most confidential information has yet again been leaked by some company I barely or didn't have any real choice to give my data to. I'm sure they all care deeply about my data and that's why it was stolen using decades-old Java serialization library vulnerabilities.
[1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
[+] [-] wongarsu|2 years ago|reply
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.
[+] [-] oliwarner|2 years ago|reply
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.
[+] [-] zzyzxd|2 years ago|reply
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.
[+] [-] _heimdall|2 years ago|reply
If the authentication flow is doing anything other than salting/hashing the password and then throwing away the original plaintext password, the entire system really shouldn't be used at all.
[+] [-] ipython|2 years ago|reply
[+] [-] jknoepfler|2 years ago|reply
Which is to say this kind of sanitization on passwords is meaningless if the barest of security standards are in place.
[+] [-] vldr|2 years ago|reply
[+] [-] moogly|2 years ago|reply
[+] [-] turminal|2 years ago|reply
Source: I'm a student there and tried it out of curiosity.
[+] [-] wkat4242|2 years ago|reply
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.
[+] [-] MathMonkeyMan|2 years ago|reply
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.
[+] [-] jrockway|2 years ago|reply
[+] [-] dmurray|2 years ago|reply
Not really, your RDBMS probably supports some hash functions so you could be storing them hashed as "UPDATE USERS SET PASSWORD = SHA2($PASSWORD)" which would be vulnerable to SQL injection yet does not store unhashed passwords.
There are good reasons I'd recommend to do the hashing in the application layer instead, but doing it in the DB (with correctly parameterized queries, of course) is not so terrible.
[+] [-] hamburglar|2 years ago|reply
[+] [-] ipython|2 years ago|reply
[+] [-] dmd|2 years ago|reply
[+] [-] Retr0id|2 years ago|reply
[+] [-] berkes|2 years ago|reply
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.
[+] [-] turminal|2 years ago|reply
[+] [-] g4zj|2 years ago|reply
[+] [-] tkems|2 years ago|reply
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 $.
[+] [-] simion314|2 years ago|reply
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.
[+] [-] donohoe|2 years ago|reply
[+] [-] pixl97|2 years ago|reply
[+] [-] chasil|2 years ago|reply
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.
[+] [-] kstrauser|2 years ago|reply
[+] [-] buggy6257|2 years ago|reply
[+] [-] dathinab|2 years ago|reply
(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)
[+] [-] avgcorrection|2 years ago|reply
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.
[+] [-] pierrekin|2 years ago|reply
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.
[+] [-] throwawaaarrgh|2 years ago|reply
[+] [-] walrus01|2 years ago|reply
[+] [-] captain_bender|2 years ago|reply
[+] [-] kazinator|2 years ago|reply
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.