Slashdot Asks: Are Password Rules Bullshit? (codinghorror.com)
Here's what Jeff Atwood, a founder of Stack Overflow thinks: Password rules are bullshit. They don't work.
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
Yes.
"Slashdot Asks: Are Password Rules Bullshit?"
I don't know. But headlines with "Bullshit" and "?" are.
Coder's Stone: The programming language quick ref for iPad
The problem is now that the bullshit rules are now expected by customers. When we did our last major UX review, we didn't have those rules in place. Adding them made our customers overall feel more confident in our platform.
It's "cargo cult" requirements. People are so used to the security theatre of the password rules that when they come to specify what their system should do they put in all of this stupidity, They don't actually read NIST guidelines. Maybe we should lobby for some kind of certification mark - and the people who assess it would have some clues.
Also, please for god's sake let me see what I type. I have 99% of my passwords in a password manager, but not all of them, and sometimes i'm on a different device where I don't feel like logging into it if i actually know the password. Sometimes its the login of the machine itself, so unless I'm using a dongle for loging in, I'll have to type the password.
if I can't see it, and god forbid we're on mobile, I'll have to make it significantly simpler to ensure I don't fat finger shit 19 times.
That's especially true with devices. I already mentionned mobile, but game consoles, smart thermostat, and all the IoT bullshit (some are actually useful). They force me to type my password blindfolded on unfamiliar input devices. If my password is 25 characters, I'm going to make mistakes. Let me see them please.
https://www.xkcd.com/936/
I don't mind too much the simple ones like must have a symbol, one uppercase, and a number and a minimum of x characters. Those are fine because I can click those buttons in Keepass to generate a password with or without those options.
The ones that piss me off are ones that only allow/require a very small set of symbols, so I have to generate it and tweak it.
The other big thing that makes me angry is when their password requirements are hidden. You just have to keep typing in passwords until their validator stops bitching at you. Why are these requirements not up front?!!
The idea of a password rule, as in some set of checks to make sure it meets a certain level of security, is a good one. However it needs to be something complex like entropy calculation. A password can have lots of entropy, and thus be strong (meaning hard to guess/crack) in a number of ways. A truly random set of characters has lots of entropy per character, but a phrase can have plenty, even though it has much less per character and can be easier to remember.
It shouldn't be some hardass thing of "you have to have 3 of 4 groups, no repeating characters, etc, etc". If you want an all numeric password, that's fine, it'll just need to be longer. Test based on actual entropy, not arbitrary bullshit.
Or, if you really care about security, start doing two factor. It always amuses me when some place has ultra-bitchy password rules but has no options to use even weak two factor auth. They care about security, apparently, but not enough to do anything that might be really useful.
The password rules wouldn't be quite so annoying if they could agree on a common set of rules. Website A wants caps, numbers and no special characters. Website B wants special characters, caps and numbers. This means more passwords, more permutations of passwords and the end result is worse security because of all the problems with forgetting passwords. I don't know that there is an easy solution but a start would be to have the same password rules everywhere whenever possible and they should follow whatever the currently acknowledged evidence based best practices are. (balancing usability with security of course)
Making the problem worse is every f***ing website wanting you to make an account with them even when doing so is of no benefit to me. Guest checkout should ALWAYS be an option. I'm not going to become a repeat customer because you make me create an account. I'll become a repeat customer because your service and prices rock and you provide something I need.
I've always thought password rules probably made it easier to crack passwords. Password has to be between 6 and 10 characters? Great, that cuts out a huge range of potential passwords. Password has to have a symbol? That pretty much guarantees 'a' will be '@' and 'i' will be '!'.
It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules".
But you repeat yourself....
Also in there:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.
Holy crap, sanity!
Also need to scrap the minimum change interval some things impose (you *can't* change your password, even if you know you exposed it to someone accidently).
I'd also want to be very careful about account lockout policies. Yes, they are a tool to rate limit an attacker, but they are *also* a vector to DoS an account by locking it out on purpose.
XML is like violence. If it doesn't solve the problem, use more.
. . . .that don't tell you their password rules, only that your password doesn't fit them. This is especially irritating for the sites that require complex passwords and have short (i.e. 3 fails) lockouts. . . .
Even aside of the obligatory xkcd comic that will certainly still surface, password rules are at best useless. At worst they lead to behaviour that is detrimental to security.
So how long do they now have to be? 12 characters at least, no words from a dictionary, containing all sorts of numbers, special characters, upper/lower case, no semblance to any passwords used within the last 60 years... resulting in such great passwords as f$nUkw1dfvM(qkI and so on.
How to remember that? Not at all. What do people do? They write it down. If you're a lucky CISO, they put the post-it into their wallet. If you're not, you find it under their keyboard.
Sure, you can demand that they don't write it down. Then be prepared to drown your support in calls from users that have to get their passwords reset twice a day. Once when they come in, once when they return from their lunch break.
And all that because we are lazy. Yes, we. The company security. We brush off our business, i.e. securing access, onto the user. And why the fuck do we get away with that? Please tell me. It's OUR job to make machines secure, not the user's.
Security is best when you achieve total security without the user even noticing you're there. Perfect security means that little, better even no, user interaction is required. The less the user could possibly fuck up, the better for your security. And yes, that is possible. Replace a "what you know" security model with a "what you have" one, i.e. hand key cards to your personnel. If you really feel like it, augment it with a 4 digit pin they can set. That's already enough.
But brushing off security onto your user and putting insane demands on him is unacceptable.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
What confuses me the most about common practices is the small number of attempts many platforms allow before they lock your account. How did three tries become standard? I could understand if the password was an atm code, with 10k possibilities, but many of these platforms require fairly strong password to begin with. I often enter one or two incorrect passwords if I am not paying attention - caps lock, typo, num lock, etc. Is allowing 10 attempts really that much more of a vulnerability?
When my passwords get pwned, at least I can change them. When my biometrics get hacked? I'm SOL.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Make sure the creases in your aluminum hat are sharp and at a 60 degree angle.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Depends on the security questions. For example, a few of them that I use:
"What is the surname of your last parole officer?"
"What was the judge that signed your last peace bond?"
"What items were in the property room the last time you made bail?"
"What street was it that you were arrested on?"
"How many inches deep a grave did you did for the bodies?"
"When you were arrested for DWI, how many feet did you make it with the sobriety test before falling down?"
"Was was the badge ID of your last arresting officer?"
Those tend to be fairly hard to find, as opposed to someone's dog name.
Indeed. I have a password that I use for all of the diverse sites that I don't give a rat's arse about. What's someone going to do if they compromise it, make fake posts as me? Ooh, shudder.
The big brain am winning again! I am the greetist! Now I am leaving for no particular raisin!
My first act upon entering my last workplace:
- Remove enforced 30-day password resets that could only be done via IT (500+ users means two tickets a day, at least, were just password resets - and imagine what that does to remote workers who then can't get into remote desktop or email to request a password change anyway!)
- Remove "password history" requirements that were onerous and made people invent - and therefore forget/lose - passwords all the damn time or just use numbers tacked on the end.
- Remove all complexity requirements from passwords, except minimum length.
- Encourage people to choose a small set of GOOD passwords, which I promise I will not invalidate every month, and use them well (e.g. if one system requires another to work but gives NO MORE access to data than the first, they may as well use the same password!).
- Stand up once or twice a year in all-staff meetings and gently remind them to change their password, oh and by the way, I was the guy who stopped you having to change it every single month so you might want to pay me the courtesy of actually doing so.
- Demonstrate, as a mathematician, the thing that the XKCD cartoon does - LENGTH MATTERS, ALPHABET COMPLEXITY DOES NOT (*).
The staff loved me for it, it's totally compliant (passed through security audits, DPA audits, etc.), backed up by official NIST, GCHQ, etc. advice and all kinds of computer security experts and it works.
Number of account compromises: 0 in 3 years.
Number of account password resets required - ONE THOUSANDTH of what it used to be.
(*):
Adding a single character to the alphabet available increases brute force times by a factor of 1/(size of previous alphabet), e.g. one-twenty-sixth more.
Adding another character - using the same alphabet - to the length of a password increases brute force times by a factor of (size of previous alphabet), e.g. TWENTY SIX TIMES MORE.
A 10-character, only A-Z, a-z password takes TWICE AS LONG to brute-force as an 8-character, every-ASCII-character password.
password that changes every six months to a year.
Why? Why not every 2 years, or every week?
What problem are you solving by forcing password changes to uncompromised accounts?
I can tell you a problem you're creating, and no technical policy can fix: Passwords written on a notepad in the drawer or taped to the friggin monitor.
I work 100% remote and have a pin+rsa VPN login, but my AD password changes every 90 days. How on earth is my password being compromised? It isn't. Quit treating it like it is.
Grammer Nazis - I mod you "troll" unless you actually add something on-topic. Yes, I know I have mispellings in my sig.
they could extract various 4-character permutations, and store a salted hash of those characters along with their positions within the password.
The organisation I work for used to do exactly this. Then one day they decided that they would use a hardware password vault, with the ability to verify the password combinations. The problem was that to move to the vault we would either have to get access to the full password or get everyone to re-register. The business said to me "is there anyway you can get the original password". My initial reaction was "no - it's hashes the password isn't stored", but after a litte thought I realised that the first 4 character combination was basically a 4-character password. A naive brute force could crack it in about 45 seconds. Optimizing simply so that it would try the most common letter combinations first reduced that to under 20.
Having obtained the first four characters XXXX---- finding the subsequent ones XXX-X---, XXX--X-- and so on is sub-second, you only have to find one character each time using the appropriate hash. Cracking the whole customer list took just over 2 days
The current solution uses multiple passwords each of which are known to only one role of person, something in the hardware unit, a value put in the database by the DBAs, and a value set in a file by devops. We know that encrypting the password is not the most secure method but the reason that we use the "4 from n" is we see the risk as asymetric; there is a much larger chance that the customer's PC will be compromised than our systems. Also over a certain limit we require two-factor authentication.
Ok.. It depends.... Password rules, like anything, when used within reason CAN increase security.
There has been some research which arrive at the conclusion that yes, indeed, password rules are actually bullshit for security.
As mentioned in the summary, enforcing password rules will actually block provably safe passwords :
- a base32 encoded 128bit pure random number. It's mathematically provable to be secure (if done by a cryptography-grade true random number generated, it's a 2^128 security, which is pretty good enough). But it's a 25 character long string of alaphanumeric. So it's not mixed case, and doesn't contain punctuation so it will be rejected by most stupid rules (also some rules have size specified as a range [9 to 16 characters], not a minimum [more than 8]. This will also reject a 25-long password).
As shown in presentations at numerous presentation in conferences such as CCC :
- even a complex rule set (Mixed case, must contain numbers and punctiation, at least 9 characters long) will usually give results such as "Denver17!"
Which are a lot less secure because they follow a general pattern (The first letter is the single capitalized, number come at the end, punctuation is the last and 9 out 10 times it's a '!' ). Most of these "rule abiding password" follow one of very few such patterns, and patterns are alarmingly easy to crack.
As such, no matter what, rules are a bad idea.
On the other hand, password managers with a generation function (like the above 128-bits equivalent password) are definitely a good idea.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Ditto those stupid 'KBA' (knowledge-based authentication) questions, which are even worse:
1. Who on God's earth thinks asking "What was the make of your first car?" is remotely secure? Ford, Honda and Toyota together make up over 30% of all the cars on the roads!
2. once a database on these is cracked/leaked/left-in-a-public-restroom I can never change "the first concert I went to" making that answer insecure for the rest of my life, but I'll probably never know that.
3. I find myself looking down the options going: well, none of these apply. I don't have a favorite baseball team. I didn't have a nickname when I was a kid. I don't want to give you gobs of biographical information. I guess I'll have to make something up, and then forget it.
None of the security of biometrics, with all the irrevocability. I can't figure out why these were ever thought to be a good idea.
'This writing business. Pencils and what-not. Over-rated if you ask me. Silly stuff. Nothing in it' - Eeyore
Just to add insult to injury, those fuckers started adding third party web sites for services like project planning and some employee incentives. And those third party web sites also had their unique password requirements. I eventually arrived at the conclusion that most of their employees were so busy maintaining their passwords that no other work was getting done inside the company.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
What study?
I'm kind of lazy to google all the sources by my self.
The general approach is *pattern-based*.
I pointed to a presentation on youtube but there are other independent research all arriving at the same conclusion.
They are mostly done by applying pattern-based cracking either to leaked hashes databases or to hashes databases volunteered by organisations.
so it's not theoretical works, it's mostly noticing what is happening in the wild when your try enforcing password rules.
doesn't mean they are totally BS. {...} But OBVIOUSLY password rules force the user to avoid the common pitfalls in password selection and will more likely cause your users to have passwords that are not easily cracked.
The problem, as discovered among other on the presentation in my previous post, is that by trying to avoid common pitfalls in password selection:
- not enough variations if password are all lower-case only caracters (It's only 26 symbols per position)
you do not actually avoid the pitfalls
- if applied accurately that would give 26 lower + 26 upper + 10 digit + even more punctuation per position
but push the people into a different set of pitfalls.
- people are lazy. most of the time, it was discovered, they'll just upper-case the first letter and slap the required extra digits at the end. And add '!' afterthat if they can't get around punctuations. That's still 26 possibility per position, with a few more things (nearly negligiable) at the end.
So... what's easier to guess "password" or "Denver17!" ? I know what I'm going to bet gets broken first..
Both are in the "basically worthless" category.
the first one is straight out of a word list.
The second follows one of the most common patterns: "Llllll##?".
In theory, if a user used all possible characters at any position, you'd be getting "26 lower + 26 upper + 10 digit + 10punctuations" = ~approx 74 symbols per position. A 9 character long password would in theory get 74 ^ 9 or approximately 56bits of security. Not much, but still something.
In practice, most password abiding the rule will be one of the few common pattern such as above.
Without taking dictionary into account, only the symbols at each position of the pattern, the above is 26 ^ 6 * 100 * 10 or only 38bits of security.
You lost about 18bits of theoretical security, just because your users are lazy as shit.
There is about a dozen of such overwhelmingly common patterns (so you're looking at best at 41bits security. If you only use salted hashes in you password database and it gets leaked, the vast majority of your user passwords will get cracked appallingly fast).
And that's without factoring in dictionaries. (Look at all the 6 letter words that you can fill in the first part of the pattern, first use a few common combination for the numbers (current year, '13', '69', etc.) and you can basically go for '!' and leave the rest of the punctuation later). At that point, in case of a database leak, tons of password will get insta-cracked and the attackers can already start probing for password reuse even before the end users has had enough time to be alerted about the leak.
You want to stack the deck in your favor where you can, so if that means forcing your users to follow some rules in password selections gets you 50% more secure passwords.... Do it..
In practice , you only get marginally better security, because the users will resort to simple schemes just to get around the rules.
People are lazy and will resort to the simplest pattern possible just to get around the rules.
In this case, I'm not inclined to believe password complexity rules are just bad,
Their are bad in that they push non-security-minded end users to do things which are nearly entirely predictable for the password cracker.
i.e.: they are actually not adding any significant amount of securit
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
WINDOWS: Please enter your new password.
USER: cabbage
WINDOWS: Sorry, the password must be more than 8 characters.
USER: boiledcabbage
WINDOWS: Sorry, the password must contain 1 numerical character.
USER: 1 boiledcabbage
WINDOWS: Sorry, the password cannot have blank spaces.
USER: 50fuckingboiledcabbages
WINDOWS: Sorry, the password must contain at least one upper case character.
USER: 50FUCKINGboiledcabbages
WINDOWS: Sorry, the password cannot use more than one upper case character consecutively.
USER: 50FuckingBoiledCabbages ShovedUpYourAssIfYouDon'tGiveMeAccessNow!
WINDOWS: Sorry, the password cannot contain punctuation.
USER: ReallyPissedOff50FuckingBoiledCabbages ShovedUpYourAssIfYouDontGiveMeAccessNow
WINDOWS: Sorry, that password is already used.