Sites with dumb password rules
github.com
github.com
I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figured it would be OK. I input my username and password using my password manager but it didn’t work. Pretty strange, as I was able to log in to the “main” EZpass site using those same credentials. I tried logging in on the payment site again to no avail. Finally I realized that my password was being truncated by the password input field itself.
The solution was to inspect the page and change the maxlen attribute of the password field.
Say there is a function named ‘verifyPassword()’ you can simply run ‘verifyPassword=function(pass){ return true }’
Often times when I'm fixing sites, there's an actual error thrown in the console, which will take you to the line in the code where the exception happens (or any line along the stack trace), so you can set a breakpoint right there and fix the code. If the code is minified, there's also a button near the bottom of the code section to reformat it./
The only tricky part is if the JS is embedded inside the html, then Chrome doesn't let you edit it, but often then, it's in the global Window namespace, so you can literally override the function by typing in the console. Hope this helps!
As a hands-on example, you can open hn.js on this page, add `alert('hello')` to vote(){}, save, then try upvoting my comment :)
However I am quite certain that not every solution has hashes of the password stored because every now and then I still get sites that tell me the password I chose has disallowed characters in it.
I kept thinking there was probably something in their tos pushing the blame on me if any issue happened since I had to bypass their security feature.
And of course then logging in doesn't work at all. It took me days to figure out what was going on.
I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).
The big payout was when we had an on-site formation from a third party and the teacher needed to create a corp account. He miserably failed to validate various secure combinations against policy (like 16+ length 5 words xkdc style). Being the only consultant associated, I just yelled across the room full of in-house IT guys "Just try Password1 it's gonna make it!"
Obviously it worked out ¯\_(ツ)_/¯
PS: Oh and nobody reported me for this "incident" I still don't know if it's out of shame, dumbness or because nobody wanted to actually get to work to change that policy.
It satisfied the uppercase, lowercase, number, symbol, and non-reuse criteria perfectly, while having precisely zero security.
Come to find out, something like a dozen different contractors were all sharing this one guy's login. He was the only reason anything got done in the whole region. The "system", such as it was, worked, but it made a mockery of corporate IT.
A few months into the project, that employee gave his notice and quit. Went to work for the competitor across the street; we'd bump into each other at the diner and stuff. But they couldn't just turn off his login -- his manager understood that all the contractors were using it, so they just left it active, and whoever got the expiry prompt would dutifully update the password every month...
Isn't corporate IT recursively defined as being a mockery of corporate IT?
Passwords don’t really have an expiration date if they are secure (as in long enough and not reused) in the first place.
But I guess they also knew my boss would have laughed at them and said he support me. I have a great boss. I really can’t complain on that level.
Me too. It's like a game: choose the easiest possible password given constraints.. My theory is: for each set of constraints there is always exactly one such password. Hard to prove, I know.
Work gets the equivalent of Banana1!, Banana2@, Banana3#....Banana9(, Banana1! (upper case, lower case, number, symbol, can't be previous 8 passwords) because we rotate constantly.
I'll let you figure out how I know this :|
It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad.
It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.
So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.
That’s a huge win!
My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?
Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true).
Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.
But I often have to toggle it off temporarily to bypass the stupid copy/paste blocks.
I don't get it -- don't the sites want users to use more secure passwords? That should mean encourage password managers, unless they imagine I'm gonna remember a 32 character random unique password for every website?
Safari users can install StopTheMadness which disables this and other such nonsense.
So I got a shirt that said "myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com"
Not too much later, I ended up working in software validation, and I broke so many login forms with that perfectly-valid address, I lost count.
Since then, Halibut Stuff dissolved and the forwarding service is long gone. If some HN reader wanted to set up a Mailinator-like service that generates absurd-yet-RFC-compliant email addresses for such testing, I think there might be a market.
Until a few years ago it was fairly commonplace for sites to reject my perfectly valid addresses just because they had more than one period (i.e., a subdomain) or in one case, ended in the .us TLD.
I use 1Password and even though I agree that forced password rotation is dumb, this makes it painless.
A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.
"Pet's name?"
"ICUP."
"Can you ........ Oh."
I always (politely) point this out when I'm dealing with a human at an institution who asks me for this information as part of the security process.
This SMS annoyance is a major reason why I left them.
I get annoyed by the security questions in a different way. If they are all based on "firsts" such as first school, first address, first friend, etc, I'm screwed. I moved 23 times growing up and went to 9 different schools. I have no idea what my "first" things were.
Their password requirements: “It must be at least 12 characters long and not be a commonly used password. That’s it!” [1]
Oh, and login.gov allows pasting from a password manager.
[1]: https://login.gov/help/creating-an-account/how-to-create-an-...
It specifically bans most of these dumb practices listed in the OP.
No 'security questions', no password hints, no special character or other composition rules, no short character limits, no routine expiration dates.
The main idea is: let the user make the password they want, require two factor, and run their password against a list of known compromised passwords to make sure they don't pick something stupid.
- Of all the password databases breached in 2016, "123456" made up 4% of them [1].
[1] https://en.wikipedia.org/wiki/List_of_the_most_common_passwo...
I'm also kind of surprised not to find some variation of "sesame" on here.
- FIDO keys don't have identity. Each FIDO key is different of course, mine can't be used in place of yours. But an activist can use the same key for their Facebook "Smash Exxon" page where they are never shown without mask and also for their login.gov ID where they sort out government affairs using their true full name and address, yet even if the government and Facebook and Exxon all work together they can't tell those are the same person from the credentials.
- FIDO keys don't move secrets. There is usually a "secret" random value baked inside your key to make it unique, but everything sent back and forth is public, so if it leaks that's no big deal. login.gov could literally paint all the FIDO credentials it has on the side of the Capitol building for everybody to see and it would make no difference to security.
Must not include more than 2 identical characters (for example: 111 or aaa)
Must not include more than 2 consecutive characters (for example: 123 or abc)
First, they apparently mean repeating and not identical characters.
But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords.
------
Edit - Just simulated this for 10 million 12-character passwords randomly generated from the 90 characters Chase allows.
Turns out the repeating and consecutive rules would invalidate about 0.3% of purely random passwords.
A negligible reduction in entropy is certainly more than offset by preventing passwords like aBc123456789.
Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
For example, if you set a minimum password length of six characters, an attacker doesn't even need to bother going through all of the 1 through 5 character combinations.
The flip side of the coin is that, obviously, allowing low-entropy passwords will inevitably mean that some users will actually use them, which means that their passwords actually have decreased entropy.
If you want to crack my password, and I tell you that my password is L characters long, by skipping all passwords of length < L you've only saved about 1/N of the required effort (where N is the size of the character set you choose from).
In other words, telling someone the length of your password does not help them very much.
If you say "No passwords less than eight characters", most passwords will be clustered around 9 or 10 characters. That's human nature. This means that your entire search space is only the character set in that very limited set of strings. And, if you're limiting that character set, and also it's expensive for you to hash (ie scrypt or bcrypt with lots of rounds), then not having to go through the first 1-8 set will save you a tremendous amount of time...
Well, not quite. If you allow say capital letters and numbers only (36 different characters), and you have to go through all 9 and 10 character passwords, skipping the first set of 1 to 8 character passwords saves you less than 0.1% of the work, if my rough back-of-the-envelope calculation is correct.
That was precisely what my statement was about - longer passwords are just so much better.
(Note that this assumes that the cost of computing the hash is by and large independent of the length of the password, which is a very good assumption for the lengths we are talking about here).
Well, the theoretical entropy, but not the empirical.
You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy" and makes things less secure (after all, your random password generator might just randomly have generated "12345678"), but in practice quite obviously it makes things more secure.
> Well, the theoretical entropy, but not the empirical.
Agreed.
There are profound implications of that statement of that statement when applied to other problems, because we mutually accept the theory as correct, but only theoretically, when we know it has significant limitations in the real world.
> You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy"
Obviously. And yet, equally obviously, removing those from the rounds because they're preemptively banned reduces the actual number of test hashes we have to run to brute force, and introducing a rule means that we can also eliminate huge swathes of potential keyspace.
So, the obvious is not necessarily so obvious after all. This gets more and more interesting the deeper the rabbit hole goes.
What if we have extremely random data -- perhaps even raw binary -- but it happens to have a sequence of three arbitrary integers, which is in violation of the rules, and therefore we can eliminate all such passwords from our test cases? That's a potentially huge chunk of entropy.
Re-running the simulation to assume case-insensitivity results in 0.44% of random 12-character passwords failing these rules (assuming Chase treats aBc as an invalid sequence).
Note that Facebook also accepts variations on a password, for example if you have caps lock on, or if the mobile device automatically capitalizes the first character, or if an additional character is added at the end of the password.
More discussion on Facebook's policy here -> https://news.ycombinator.com/item?id=13426544
Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.
Screw up 1 too many times and you end up in a cycle where you never will remember your password and you'll try the last 3 or 4 you used, eventually locking yourself out again.
Ideally you'd detect one source trying logging into multiple accounts with many failures instead.
I just close and reopen an incognito window and voila, no more rate limiting.
What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.
Good security dictates a minimum length, and practical avoidance of your login form being a denial of service... well, that dictates a maximum length too. It can be quite long, but you generally should not allow bot makers to instruct your login handler to actually hash the entire declaration of independence, repeatedly.
(Edit: I should clarify, by "reasonable" I'm talking like, 200 character or more reasonable. These sites with 20 character maximums make me cringe. Also the computational complexity can be mitigated in other ways, like sensible rate limiting.)
I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.
This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.
Eg use the first 72 bytes of SHA256, if you like overkill.
That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.
So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.
I've been able to supply my 'too long' password more than a few times that way, and it's transpired that actually it clearly was all stored on registration.
So on a whim I've tried it when registration's failed, and sure enough it's been stored, and then not validated on login.
It's so easy to do better, just don't do it in the frontend!
I think they simultaneously ignored all case but that could have been an unrelated site, memory is hazy.
> Password must be exactly 6 characters long and no special character.
I had an account with these guys. Their security is just ridiculous. 6 alphanumeric characters is all they'll accept! I mean, some of the entries on the list are bad, but this is a friggin major national bank in Canada with a piss-poor password requirement.
This list needs to be segregated into different categories so we can laugh at the different ways sites are dumb.
EDIT: OK, they apparently updated their password rules to make them more sane (but didn't, like, tell any of their clients to go update their passwords?). Apparently their previous system was worse than I thought - it actually mapped your alphabetic password onto a number pad, so if you set the password AbcDEf then you could login with 111222. Guess this is what happens when you try to drag a telephone-banking system into the online banking era...
They ONLY offer multiple choice questions for the security questions!
Of course, for some questions none of the answers are correct (favourite artist etc). On the other hand it would be dumb to choose a correct answer that someone else could find out and then take over your account.
Some of the questions have as few as 12 valid answers - e.g. "in which month...". Also in the select box where you pick your answer the months are sorted in a nonsensical order.
I ended up picking questions with more possible answers and choosing a random answer and putting it into my password safe.
Infuriating!
It's mind-boggling to me.
The person on the phone then just asked me a basic question about the policy, which I got right since I had the policy in front of me, and was then happy to change my password.
Fantastic... not.
If you say it like that it may make sense, however the email address that I often use (especially if you have to use exotic text entering device) is a@xxxxx.com.
End result: I'm banned to use the letter a in my password... how smart! It drives me really crazy.
For when XXX is just not kinky enough for you.
If it does, you can easily work around that limitation by signing up with a+microsoft@xxxxx.com
I try to do that for any sites that let me, both for ease of indexing, and if my leaked email ever gets found in a data breach, I know which source it came from.
* Password must be EXACTLY 8 characters long
* Password must start with a letter
* You must use exactly 3/4 of the following: upper case, lower case, numbers, one of three special characters
* Password cannot "resemble" username or past password
Unfortunately, it's not that uncommon. I've done security consulting work at a few major F500 companies that were using this and had those same password rules. At one of them, it got to the point where almost every security review meeting had to start with "yes yes we already know how bad the password are, don't bring it up, let's talk about something else".
1: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...
IBM already has solutions for secure passwords of variable length. Outdated systems may have stored passwords as plaintext with symbol limitations, but modern RACF can hash passwords, encrypt profiles, and generally take whatever you throw at it and handle it securely. The tech isn't the problem, only the personnel.
For instance, case-insensitive passwords.
EDIT: I guess they could be converting to lowercase (or uppercase) every time before hashing, as multiple people pointed out. If that's the case though... fine, let's pick one of the first instances in that site (not mentioning by name).
Why can't it have spaces? Hashes don't care about this. Smells awfully like some string manipulation going on.
Why is it limited to 20 characters? Odds are that they are using VARCHAR(20) or variants. Hashes also don't care about this.
None of this is proof, but it smells really bad.
Since then I have seen a better solution: Try the password, if it fails try it with the case flipped. If that works it's a caps-lock error, they know the password, accept it.
Flipped case (caps lock) or first character case is wrong (mobile input field) were both allowed. Not sure about now. The article I found about it was from 2014.
Stackoverflow Meta Question here:
https://webapps.stackexchange.com/questions/26301/facebook-a...
My Question (the reason why I know):
https://stackoverflow.com/questions/10718236/how-to-alter-th...
But you are right, that none of those companies do that.
They don't want to deal with angry customers who are "definitely entering the correct password but it's not letting me in".
After a few months, I bought a new phone so I had to get a new link (I thought). But even the IT guys are saying: Nah man that's too hard. Just use the same link you received months ago.
It worked. There is no time-out on those links!!!!. A link we receive in a plain-text email!!! Some of our inboxes are shared / have a PA attached.
But nooooo, this is not a security problem AT ALL... :-(
I hope if someone gets hacked they will be able to sue the them because of their archaic security practices.
p.s. would like to use this opportunity to also complain about their non-english English dashboard, god I hate it.
Hm, sure? My comdirect account uses a 6 digits pin. Never tried to use more than that. But 6 were still horrible enough when looking at the fact, that SEPA transfers of up to 30 Euros don't require entry of a TAN. A feature, which can't be disabled. Hate comdirect for that move.
EDIT: feature, not option. :)
And, yes, the forced TAN-less transfers is why I am closing down my accounts. That is, they forcing thid disfeature on me, and their impertinent reaction when I rejected their bullshit justification (essentially they calling me rude and therefore refusing any further conversation because I pointed out that "many customers like this feature" is not a reason to force it and the risk that comes with it on customers who don't like it).
Clearly not an IT focused organisation! The were also offered the .com version of their name for $1m AUD and turned it down which I found amazing for a $100bn organisation.
I use westpac here in New Zealand and their website works really well, normal password, normal inputs, nice looking UI... but IIRC they are technically different companys.
And there's a special place in hell for sites that require entering numeric PINs by clicking on a "keypad" of randomly generated button locations.
I guess the password is being used in a query template? Seems like a very bad idea.
Basically anything a scripting programming language might use as a comment or sigil. Putting 'we are probably calling exec() on your password' into writing though is a boneheaded move.
-Must be 8 characters
-Must be all lowercase
-Must contain $ or !
-Must contain letters and numbers
I'm not joking.
E-Trade has a decent security story though. 2FA w/hw token, and they refund all ATM fees on the checking account so it's decent for general banking in addition to trading.
Because it's totally not a bad thing to train users to accept unknown 2FA requests in the middle of the night because "it's probably just my work computer refreshing itself".
That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default.
Long story short, encoding problems can be tricky, even in 2019.
For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.
Of course, we have to use these passwords in quite a few circumstances where a password manager cannot be used (logging on to random terminals, etc.), and then there is the multiple random 2FA checks, in buildings that have no cell signal...
I just realized that I set up this Twitter account 10 years ago, this month: https://twitter.com/passwordfail
Most sites don't email passwords anymore, so I suppose that's something.
Yesterday I had to go through an inconvenient password reset because my bank no longer allows spaces in passwords. The password input inconspicuously removes spaces after you type them. It took several failed attempts before I realized what was happening.
I've also set a password that wasn't accepted by the login box, it explicitly stated there was an invalid character.
My quick idea is that it would be good to have a way of reproducing those cases somehow; not sure how though, because registration is something that is difficult to automate, so we'd probably need some browser extension to do this research. Once we could automatically test (or semi-automatically, waiting for a user to verify) whether this is still an issue, we could create a website where one could sort by most popular / annoying / old flaws, maybe also arranged by communities so that changes would happen.
Either way, I appreciate kicking this off. It's definitely a good start. I just wish we could transition from this to actually changing this deliberately, as opposed to just shaming and hoping for organizations to eventually fix their things.
What I don't understand is why sites use a maximum password length. They shouldn't save your password anyway, and only compare the hash, right?
Irrelevant compared to the rest of the operations done on the server.
Still, you have a point that allowing arbitrary sized passwords to denial-of-service attacks. Still, a more reasonable limit would be 100 or 256, for example.
Whatever the reason is, it's pretty darn stupid!
What do you mean with that? I don't have a problem archiving passwords in 1Password. When I change it it's automatically stored in the entry as password history. If I retire a login because a site closed but I still want to keep my credentials / details I move it to an "Archive" vault in 1Password.
Many of these are so nitpicky that it loses credibility
“oh it doesnt let the user know the max character limit is 30 characters uwaaaah”
cases like these should be part of a checklist that shows this is a minor infractions instead of putting them all on the same level of shame
It makes sense to change credentials periodically, but the policy of 30 days for humans doesn't work because the humans aren't realistically going to remember new credentials every 30 days.
If you have Let's Encrypt, the default setup (Certbot) will change the key every time it renews, typically 60 days, but you aren't expected to remember the key it's just data for a machine to store somewhere, so there's no practical problem and it defuses some risks (e.g. bad guys get hold of old backups). So the idea of rotating credentials like this would make sense _if humans weren't expected to remember them_.
Also, TLS is MITM-able (the CA system is one giant backdoor, CT doesn't prevent MITM attacks) so you're password and authenticated token can be captured and your account can be pwnd.
Don't use pass words. Use mnemonics to derive public/private keys and use authenticated encryption (see lib sodium) or separate signatures and encryption.
Some of my explorations here (work in progress)
https://docs.google.com/presentation/d/1f2k6fsIkDmIS1WyJAT0l...
If you choose a password by randomly selecting from a list of 500M passwords, surely it has log_2(500,000,000) ~= 29 bits of entropy?
Let's take the "insufficient serial entropy" as one very clear example. That was a Brown M&M and not an actual technical concern, but you haven't understood that at all and just linked it as part of a claim this is "Security Theater".
Several of your links supposedly about "HTTPS snooping by Governments, Employers and Hackers" aren't about HTTPS, or even TLS, or even the Web PKI, but instead unrelated "certificates" of one sort or another than you apparently didn't understand weren't the same thing. For example the Apple Insider article is about Apple's iPhone application signing.
And then your "solution" ends up relying on all the same infrastructure you've wasted slides decrying as subject to MITM, including both HTTPS itself and OS-specific code signing.
Get out of here with that Coiner nonsense.
The original entry didn't even fully capture the stupidity of the BMO password system (which I recognize they have now fixed).
The most egregious part was not that your password had to be only 6 characters. It was that whatever password you chose ended up getting mapped to where those characters were on a telephone keypad. So, for example if your password was passwo, you were also able to login with 727796 or rARsYo or anything else that mapped to the same characters.
I really should have switched banks when I found this out.
Edit: Link to the github issue comment mentioned - https://github.com/dumb-password-rules/dumb-password-rules/i...
Since you're curious: I signed into telebanking and it asked for me to input my password. I didn't ever remember setting a phone password, so I tried punching in the numbers that corresponded to my online banking password. It worked.
Obviously the only way this would work is if they stored the numeric keypad representation of your password instead of your actual password. So I experimented a bit and found password horror.
Allegedly this protects against key loggers.
My favorite was "Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries)." So I have to search every word that humanity has ever used??
---
Letters [required 1]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z – AND
Numbers [optional 1]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 – OR
Symbols [optional 1]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ‘, “, ,, ., <, >, /, ?
Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries).
Verify password is not the same as, or a trivial variation of the username.
If Account ID is ‘fred’, then password cannot be ‘fred’ ‘fred1’ 1fred’, ‘fr3d’, etc.
Password check should look for Account ID string in the password
Password system must support mixed case passwords (Password1 should yield a different result than password1)
Passwords will expire no later than one hundred twenty (120) consecutive days after issuance.
Products must accommodate Account ID lockout after 10 consecutive failed password login attempts.
The failed count (if currently under 10) should reset after a successful login
If the 10th consecutive failed attempt is reached, the Account must be locked out for a minimum of 24 hours
After a password expires, the user must select a new password
The password system must remember the previous 5 passwords for each user
The user may not select a new password that was one of the previous 5 passwords for that user
The user may not change their password more than 1 time per hour
---
https://developer.intuit.com/app/developer/qbo/docs/legal-ag...
The only thing I hate from passwords is lenght. Most of the websites don't allow me to do +40 char passwords. I generate everything with 1Password and I have to limit on most websites to under 20 characters.
So if you ever find yourself having trouble logging in with your 1pwd auto-generated password, try again with the first 20 characters. You just might get in!
If so, I wonder whether it's worth adding a (politely-worded) summary at the top of the page describing why rules like these are dumb? Then the people responsible for these sites, most of whom are themselves probably not dumb but just mis- or uninformed, can learn from their mistakes.
...a checkbox.
Worse, this checkbox is exactly where one would normally expect the "Remember me" checkbox, so if you check it out of habit, you'll end up getting shoved into the password reset flow instead.
Who does the usability testing on those sites?
You can disagree with the rules but if you don't want to get in trouble, you have to follow them until they fix them.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
I definitely don't think it does this. In fact it probably makes most people much more likely to use the same password on every site, since their passwords just became 3-4x harder to remember.
For some reason I feel that the upcoming European payment services directive is only going to make this worse.
Kidding, I hate silly password rules as much as anyone, and these places deserve the public shaming.
Brilliant.
From a usability perspective, if someone manages to accidentally enter some dodgy control codes, and then can't log in on other devices because they don't know how to enter their password, it may be problematic.
Personally I think if a user chooses to put control codes or emoji or the unicode symbol for 1/2 as a fraction in their password, they're entirely welcome to have that but they shouldn't be surprised that when they want to log in they have to enter the password with that in it.
Ultimately, it depends on the expense of the support request that arises when users screws up and needs to reset their password - if it's too expensive it may be worth excluding the really exotic characters.