It's correct, but with such a large scope of available options out there, such a giant demand for the tool, it's a behemoth that is slow to change and full of silly mistakes. It's an unfortunate reality and consequence of the world we live in.
Please don't put anything in here that might harm us, because we're inserting these characters directly into our totally secure password database, which also happens to contain all of your biometrics. We use firewalls and lots of red tape, so it's all very safe.
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.
Maybe they run a password report and someone had <script>alert("lol");</script> as a password. Managment freaked out and demanded someone fix the hack.
The interesting thing about some of these is that you can instantly spot instances where they are storing the password in clear text.
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.
Not necessarily. They could run str.lower() on the password input before hashing and saving the hash. Then to verify the password, you just always run str.lower() on the input before calculating the hash.
Why? I've done it before. This was an in-house program with little in the way of security implications. Forcing the case on the password greatly cut down the number of problems.
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.
They're not case insensitive, but they do allow for some casing mistakes.
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.
That seems bad, like philosophically it feels like a password and only that exact password should work. But rationally I can't see too much of a problem with this.
You can also implement that by just bruteforcing the previous hash with variants of the new password. IIRC Windows since 2000 implement these kinds of checks in exactly this way.
Honestly, I'm past caring about upper length limits, however stupid they are.
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.
Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length.
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.)
Bcrypt is still widely used. It’s just advised to increase your work factor to something at least 12 if not 14+. And every year or two bump it up another level.
> that complexity is meant to be computationally ridiculous, and probably scales with length.
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.
bycrypt has a limit of 72 bytes (not characters) and possibly less depending on the specific implementation. Theoretically this could limit you to only 18 characters if your password is utf-8 encoded emoji (4 bytes per character).
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.
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.
Wouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.
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.
But the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack.
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.
Silent truncation. This becomes worse when you realize that a companies web login vs mobile have different hard lengths, in this case it was mint.com. They allowed 16 online and 32 mobile, after letting them know they thankfully made it consistent at 32. Which isn’t perfect but it’s far better than most
I've encountered other weird bugs in mint too. On one site they wouldn't let me enter an email address as a username for a website which used your email as your username. Editing the DOM to remove that front-end validation worked, which was also disappointing, but at least it worked.
Oh! Related gripe - registration and login having different validation, removing it in the frontend 'fixing' it...
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!
It would be nice if there was a HTML standard for specifying password requirement data, like length ranges, valid/invalid characters, character type requirements(3 letters, 1 number, 1 special character), etc, so that password managers/generators could use it to always create a valid secure, valid password for you.
Useful idea, but I wouldn't it be exploitable by adversaries as well (eg. knowing those constraints would be helpful for generating dictionary attacks)?
If you're targeting a specific site's database for a dictionary attack, finding out and entering the specific constraints would be minimal effort. And if you're not targeting a specific site, you probably want your dictionary to be as permissive as possible so can potentially match users on all sorts of sites.
Or the password is used in sprintf() ... I know at least one organization where this happened. The % was being stripped from passwords for that reason.
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.
Yes, but no, but yes. What I believe the original poster was hinting at and I believe you, witty little you, also understood was the rule severely inhibits the entropic nature that you would rather see.
Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
The maximum possible entropy is in a sense sampled by users various passwords. The sampling can be biased, so rules can technically eliminate such biases and lead to higher effective entropy. Furthermore, there is a benefit in forcing the user to not share the same password across multiple websites which can be achieved by imposing extra (or ideally mutually exclusive) password rules. Of course I am just playing devils advocate here.
It's ironic that allowing low-entropy passwords (for example, one-character) can actually increase the available entropy.
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.
I have actually thought about this a lot and done some napkin calculations: using a set of about 93 characters the search space for 5 character passwords is about 7 gigabytes; combining all the possible passwords <= length 4 is only about 74 megabytes in comparison. I think that the entropy loss is insignificant.
Indeed, and the factor is about 95, which is close to 93, and that is not a coincidence, when you think about it.
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.
The impact of this really depends on the cost of calculating hashes, which varies based on hash algorithm. It might even be the difference between being able to ever find the hash or not. Being able to constrain the search space is the ONLY tool you can count on.
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...
> 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.
Does it reduce the entropy of passwords in practice or just in theory? It could be that in practice if you let users repeat characters they will do so more often than random chance would allow for, thus making their passwords predictable to some degree. Thus, prohibiting that practice would increase the randomness of passwords actually getting used.
My 16-char alphanum generated password for Chase had an equivalent of "rST" in it. I can never remember which password modification I ended up with, and "can't choose the same password as your previous 4" gets real old real fast.
When you did your simulation did you use lowercase and uppercase letters? I ask because chase.com doesn't differentiate between the two. Seriously. If you have a chase account, try changing the case of some of your letters and you'll still login successfully.
Using uppercase and lowercase letters and the symbols Chase supports, 0.25% of random 12-character passwords would be rejected by the repeating and consecutive rules.
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.
It's a naive approach, and also honestly, in my personal experience with banking software, these rules are not selected through some careful secops research, but are usually arbitrary picked to sound smart to managers and be easy enough to implement by devs. Bad passwords should be addressed specifically, because having "ijk" or "777" somewhere in you 40chars long random sequence is not really a vulnerability. On the other there are many bad passwords that are not made of sequential numbers, say "qwerty" or "asdfghjkl" or "sunshine". There're so many data dumps these days that it's easy to create a blacklist of popular passwords and block it, without giving headaches to users with password managers just because their safe random password happens to have a wrong number of these or those chars.
I didn't even bother enabling online banking with my local bank because of this. None of the local banks have a damn clue so I just use them as if it's 1995; ATM and IRL. I only use them for cashing checks though so it's no big deal.
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.
Microsoft OWA for business. It automatically sends a 2FA message to your phone whenever a session times out, whether you asked for it or not.
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".
There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for https://pages.nist.gov/800-63-3/sp800-63b.html and Sophos for their summary here https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... (both of which make fine references when requested). As a side point, I'm now entirely unsurprised by the near-weekly big-corp breaches that get announced given the caliber of the compliance people we encounter.
As much as I'm grateful for the improvements made to NIST and the slow trickledown to other compliance frameworks (HITRUST, etc) there are still major compliance frameworks that require password changes and mix of upper/lower/special characters including PCI (see https://pciguru.wordpress.com/2019/03/11/the-new-nist-passwo... for a more detailed discussion). It's frustrating that while 80% of the time compliance frameworks reinforce security, 20% of the time compliance frameworks actively prevent better security.
Ironically, if you ever get an IT account on a NIST campus, they dont follow their own rules. It's "at least one capital letter, one digit and one symbol, and can't contain any English words of 3 letters or more" or similar. And they make you change it every 6 months. Pain in the neck.
Want to DDOS somebody? Try their password incorrectly three times.
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.
I don't even think rate limiting after 3 mis-attempts makes sense. I regularly can't remember my password and might need 6 attempts. Nobody's going to guess your password after 300 attempts, so make the limit 30 and you're safe.
This is basically why I started using a password manager.
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.
The primary reason you should use a password manager is that you should consider that password insecure at the place you use it. Any sysadmin at a company can grab your password and try it everywhere else you have accounts.
While it doesn't really justify locking accounts, there's an approach to guessing passwords where you have a large list of accounts available and try each with top 10 passwords, then top 100. Given enough accounts, some will work. (Password spraying) so even limiting to 30 tries wouldn't stop it.
Ideally you'd detect one source trying logging into multiple accounts with many failures instead.
Yup. Long ago, a high level person was fired. After that someone hit everybody's passwords enough to trigger account locks. It could only be fixed at the console.
I accidentally DDOS'ed myself creating my ssa.gov account and now I'm pretty sure I've got to visit a physical SSA office with identification to create the account.
Sounds like they were using z/OS or RACF [1] mainframe as a backend. Oof.
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".
I suspect they want to be able to brute-force passwords if they really need to, in the event of a uncooperative or malicious employee, and these rules allow for that.
Nah, they tend to be systems whose original infrastructure was written pre-internet and had 3 or 4 (or more) decades of bolt-ons laid on top. Password security wasn't nearly as much of an issue, but now the same system that had been designed for employee use now is used by customers and is exposed to the web. Kind of like taking a lock on a diary meant to prevent casual perusal by a sibling and puting it on a bank vault because you put the diary in the vault.
Still no excuse. They need to create a custom encoding that works with their backend that allows more flexibility is password choice. It is not that tough of a problem.
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.
I worked on a VMS system that used 4. It was originally meant to be a PIN entered over the phone, then the internet came along and that interface was exposed to the web. But it's okay, after a few years they upgraded to 6.
It's also frustrating when they change password rules and invalidate existing passwords in the process.
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 hit that, also. I finally gave up and did a password reset. In setting the new password I find the new rules precluded the password I was using. Apparently that was enforced by editing the input.
I've also set a password that wasn't accepted by the login box, it explicitly stated there was an invalid character.
When I first created a Cingular account (before they bought and became AT&T), the maximum password length was four (4) characters, because the system had been adapted from one that used PIN codes.
My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York.
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.
I had this issue with Air New Zealand - one of their sites was truncating the password field on one of the pages, but not on another page. Took me ages to figure out why sometimes I couldn't log in.
My local bank made a new website that does something similar, where the input for creating the password is truncated to be shorter than the field for entering the password. I forget the exact length but it is pretty short, like 10 characters. It took me forever to figure out why I couldn't log in to their new site.
Reading this and other similar experience, I wonder if one could make a browser extension (or vendors implement on the browser) to warn the user when they are typing behind the maxlength.
Ah, thanks for the link, that's super neat! I was looking for making changes that would persist across page loads or browser restarts, and this is exactly that. It's a shame that it's not a feature in Firefox's dev tools (not yet anyways)
In chrome, if you open the dev tools and go to Sources, you can see the files and modify them right there. If they are executed once at page load time, you need to set a breakpoint and refresh, edit, save, then press Run again.
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 :)
The time entry system at my job disables the later days of the week (anything after tomorrow's day of the week) in the week when you try to enter your time the next week, even if you've manually selected the previous week. So on Monday Wednesday forward is disabled. So I need to run jQuery('input').removeAttr('disabled') in the console!
The only reason I can figure why anyone would do that is if at some point the password in the db was a varchar with a length and then they changed it but didn't change the frontend - big isolated development team problems.
afaik, passwords are not stored in databases. Only the hash of the password is stored. The database doesn't know and doesn't care about the length of the password.
A human has to do the work to turn the password string into a hash and store the hash. At some point in time (or now, even), it's probable that they ... didn't hash the password.
Either the password or the hash of the password is stored, which it is depends on the age of the application, the skills of the developers and probably other factors that do not readily spring to mind.
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.
Not a password but slightly related, had to use western union to send money for a friend last year and on their credit card page someone tried to be smart and failed, it checked for they key pressed to ensure only numbers but didn’t account for the fact that not everyone use QWERTY (on a French azerty you need to use shift to use the top row of numbers, without shift it’s accented letters and the like).
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.
Just bad code where they took the actual key codes being pressed not the characters they map into, which made the code reject anything with shift pressed.
Mine is my workplace. They mandate changing the password every 3 months (so most people use post-its) and their password change utility accepts special characters for input but mingles them when actually stores them (the backend uses AD for authentication, but the password change goes through a custom web form).
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).
I once tried Password1 scheme as a form of protestation for a client corp account I'd connect every 2 month or so but that had a 1 month rotation policy (so that I actually had to change my password every time I connected to them). It worked... Obviously I changed it to something else but regularly tried if still worked.
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.
Oh yeah. Yeeeears ago, I was contracting for a telecom provider, and as a contractor, the process for getting logins to all the stuff I needed access to was onerous in some cases, nonexistent in others. So the employee who was sponsoring my presence in the building just said I could share his login. "The password is Apr1999!, if you happen to be the first one to log in when it expires, just change it to May1999! and so on, alright?"
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...
I don’t know someone from this client could have called my boss and said that I was a disrespectful dipshit that compromised their reputation in front of a third party...
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.
I use very secure passwords (32 character random) basically everywhere except for work because they are so aggressive about password rotation.
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 regularly run into situations where my password on sign up is silently truncated (without being given a maximum char count) so at login I can’t just edit a field, I’ve got to guess how many characters of my password they actually use or reset it (and still guess).
E*Trade’s mobile app does the same thing, but you can’t edit the password field since it’s a native app. Website allows longer passwords than what their mobile app allows and just locked you out of your account after a few correct password entires. To make things worse, support tells you it’s due to your network.
If only they were the only ones! Consorsbank (BNP Paribas) also has a limit of 5 chars, and comdirect even has a limit of 5 decimal digits. The IT security incompetence in banks in .de is just insane.
Which is clearly better, except ... what kind of incompetence hides behind that upper limit? Is their hashing function incapable of processing more than 38 bytes? Or is someone storing passwords in plain text?
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.
Oh, oops, yes, you are right, it's 6 digits ... not that that really makes a difference, though ;-) (And yes, I tried, you can't use longer or non-digits ...)
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).
Hi, this needs a checklist or ability to see severity of infractions because some of these edge cases are very dumb to elevate alongside the truly broken flows
> I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.
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?
I used to set this permanently, but discovered if you use facebook making status updates and comments become broken due to how fb seems to scan your input to apply styling.
But I often have to toggle it off temporarily to bypass the stupid copy/paste blocks.
I tried this, but this breaks some web apps where I need clipboardevents to work (e.g. Google Docs). There needs to be a more granular option for this somehow, possibly in a plugin.
Just to add. I'm Not sure if it's just a policy thing, but when a windows rdp session locks, pasting the password is blocked. Manually typing the password becomes a pain.
I really hope anything that blocks pasting in forms has good reason, an not just psuedo security
I've noticed a number of sites now are doing something that interferes with the password manager (Lastpass in this case). Common problems are either that autofill doesn't work (even explicitly clicking autofill does nothing), or they put a button in the username/password field that's exactly where Lastpass puts its button, so it's impossible to click.
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?
I contacted my credit union about this and they responded their auditors required it for security compliance reasons. Thankfully after many months they "fixed" it by removing the restrictions... but made the login a multipage ordeal which still breaks my pw manager.
Dunno about educating all those idiots, but for mitigating their idiocy I have a two-line AutoHotKey script (this is in Windows) called FakePaste mapped to ctrl-shift-alt-V. All it does is read from the clipboard and pretend to type those characters, one per 100ms if I recall correctly, or maybe I set it to 200ms. AHK can mimic keypresses at the system level, so it defeats whatever silly shit anyone tries to do in the browser. It's as if you were typing. If you're on Windows and willing to install AutoHotKey I can give you the script.
I literally couldn't apply for an American Express card about 15 years ago because my (ISP) email address was too long. I wonder why they chose to restrict it rather than go with the standard email max length; they had to put effort in to pointlessly restrict new signups. Odd.
Back in '99 or so, there was a company called Halibut Stuff selling T-shirts at Defcon (and presumably other events) that included a free email redirect service with purchase of a shirt.
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.
Like anyone would actually use such a testing service.
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 remember when their max password length was 8 characters. It blew my mind that a (effectively) bank had such terrible requirements. At least they fixed that
The 8-character limit was probably because the web site was just a fancy front-end to some decades-old mainframe system. You'd be surprised the age of technology and software big banks rely on. They tend not to fuck with a working system, partly because their reputation and millions or billions of dollars are on the line, but also because no manager wants to be the reason for a critical outage.
Using a password manager. Most include functionality to re-generate/rotate a record's password in-place, and then copy the new one to the clipboard (or even directly into the web page).
I use 1Password and even though I agree that forced password rotation is dumb, this makes it painless.
The credit union I use has pretty standard password rules (that is: decent by bank standards, i.e. pretty abysmal), but what really takes the cake is that the "Forgot Password" mechanism is driven not by a button or link or what have you, but...
...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.
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_.
I'm a proponent of only 1 simple rule: high min length. Most sites have min length of 8. Double that to 16-20. No max length, no other complicated restrictions regarding characters. This instantly takes care of brute-forcing as a reasonable possibility, and forces good passphrase discipline on the user.
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.
My pet peeve: sites that require all-numeric PINs when logging in online. Numbers make sense when you're punching buttons on a phone or ATM, but elsewhere, why limit my entropy to 10 possible characters instead of at least 62?
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.
326 comments
[ 2.1 ms ] story [ 336 ms ] threadBasically 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.
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".
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
I guess the password is being used in a query template? Seems like a very bad idea.
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
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".
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.
* 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.
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.
zxcvbn: https://github.com/dropbox/zxcvbn
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 :|
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).
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.
-Must be 8 characters
-Must be all lowercase
-Must contain $ or !
-Must contain letters and numbers
I'm not joking.
...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.
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_.
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.
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.