Slashdot Asks: Are Password Rules Bullshit? (codinghorror.com) 498
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?
In your face Betteridge! (Score:5, Insightful)
Yes.
Re:In your face Betteridge! (Score:5, Interesting)
Re:In your face Betteridge! (Score:5, Informative)
That's not necessarily true.
When you set your password, they could extract various 4-character permutations, and store a salted hash of those characters along with their positions within the password.
They're basically making a number of smaller passwords out of the alphabet you supplied via the characters in your password. Then they can salt, hash, and store these small passwords just like would be done for a full password. The plain text password is not stored.
If they do this for, say, 20 permutations, and select one randomly each time you log in, you likely wouldn't be smart enough to see any pattern in the prompting. You'd wrongly think they're selecting the characters dynamically. Then you'd go off on Slashdot claiming that they're storing plain text passwords when they very well may not be, making yourself look like a silly goose.
Re: (Score:3, Insightful)
Possible? Yes.
Likely? No.
Re:In your face Betteridge! (Score:5, Interesting)
In the goal of increased security, it's exceedingly unlikely that a larger bank is storing anything password related in plain text. Banks are beyond that stuff these days. Procedures and software are audited, etc etc - nobody but mom and pop sites would be able to fly under the radar of the harm to reputation that would occur if it turned out that your bank passwords were being stored in plaintext.
Re: (Score:3)
HAH! We were just talking about this on the Ask Slashdot thread about password generators.
YES, password composition rules are bullshit!
EVEN WORSE, are website that block you from pasting in your password. This again penalizes the ideal security model... you are pasting in a long and ridiculously hard to type random password from a password generator.
ALSO BAD, websites that have short password length limits and/or can't support certain characters. All these require workarounds again for password generator us
Don't store multiple hashes! (Score:5, Interesting)
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.
Transition to better password storage (Score:3)
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.
There are two ways to do that. One is to require all users to go through password recovery, as you mentioned. The other is to prompt the user for the full password next time he logs in, and then once it matches the hash, transition that user to the vault for subsequent sessions. Users who do not log in at all during the month of transition to the vault would have to recover.
Re:In your face Betteridge! (Score:5, Informative)
Things you should never use as a password:
1) Your first pet's name
2) The street you grew up on
3) The model of your first car
Things banks use for "security questions":
see above.
Re:In your face Betteridge! (Score:5, Funny)
Things you should never use as a password:
1) Your first pet's name
2) The street you grew up on
3) The model of your first car
Things banks use for "security questions":
see above.
That why I always use Password123
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
See, here's the obvious thing that people don't seem to understand: Banks do use those 'security questions', but there's no compulsion to use answers consistent with the question being asked. You could even use totally random strings for those, too, if you wanted to.
But you need a method of remembering how you answered them.
Re: (Score:3)
And that's the problem. They know people forget. It's probably ten years or more since they last answered those questions, so they do allow some slack in the answers especially when you're talking directly to a teller. Ie, name of high school, was the answer "XYZ" or "XYZ High School", or "XYZ Joint Union High School". Did you accidentally type in "Washingnot"? First car was a either a Celica or Corolla, not sure which.
At the time you need to find the random answers to these questions is when you need to
Strong Crypto! (Score:3)
Re: In your face Betteridge! (Score:3)
When forced to answer security questions, I generate a random multi-word answer and store that in answer in my password manager. Unfortunately that just makes it a weird backup password that I have no idea if or when it might become relevant.
I do this as well. I don't really see another option when websites (and banks are the worst for it) require them for Registration.
In today's world where people are monitored so closely (and people spew out just as much on social media), many of these answers are just a search away.
Strong password/passphrase enforcement (10+ characters), 2 factor authentication, and proper salting/hashing and storage on the server side are more important.
I'm also willing to bet these security questions are not stored securel
Re:In your face Betteridge! (Score:5, Funny)
Why couldn't they hash & store each character separately - so it's effectively multiple short passwords?
Re: (Score:3)
It's more secure because it is supposed to thwart keyloggers. Instead of typing, you have to select from a drop-down with the mouse... Well, actually you can just highlight the drop-down and type, but most people don't.
Take a look at the source code of the page some time. Most of them are a huge wadge of browser crippling Javascript that attempts to screw all the other hostile malware Javascript and browser add-ons. That's why I disable Javascript on my bank's web site.
Re: (Score:3)
Yes, except for length requirements.
Re: (Score:3)
I always use "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa". A password that long will take forever to crack.
Re: (Score:3)
Yes.
You are wrong. The correct answer is NO.... Well maybe that's not the right answer either...
Ok.. It depends.... Password rules, like anything, when used within reason CAN increase security. The question is what constitutes "within reason". Keeping folks from choosing common an easily guessed passwords on a system you need to be somewhat secure is a good thing... Making passwords so complex users need to write them down is not a good thing. So it depends. Depends on the security needs of the system and
Kind of true (Score:3)
It's not a password policy that makes you more secure, it's enforcement. You need to perform standard dictionary checks to prevent "password1234", detect crap QWERTY strings, ensure the password has a reasonable length, and allow _all_ special characters (space, tab, &, *, etc..). That latter is a problem with many banks, who disallow most special characters if they allow any at all.
If you force people to use stronger passwords you will not be susceptible to brute force attacks unless you don't monito
Proven Yes. (Score:5, Insightful)
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 [youtu.be] 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.
Patterns are the problem (Score:4, Insightful)
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
Don't know (Score:5, Insightful)
"Slashdot Asks: Are Password Rules Bullshit?"
I don't know. But headlines with "Bullshit" and "?" are.
Re: (Score:2)
title ought to have been "Password rules are bullshit"
Re: (Score:2)
Re: Don't know (Score:5, Insightful)
Re: (Score:3)
You can reduce the failure rate by eliminating the toast and buttering the cat directly!
Customer Psychology (Score:5, Interesting)
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.
Re:Customer Psychology (Score:5, Funny)
Re: (Score:3)
Pick a strength at random.
That must be how they work. There's one site I use where I paste generated passwords in when creating new accounts. Sometimes a really strong password shows up as really weak. If I remove it and paste it again, sometimes it's strong. Sometimes I have to paste it into the "Repeat password" box first to clear out the "weak" designation.
Re:Customer Psychology (Score:5, Insightful)
I saw the exact opposite in the right situation.
I was using an automobile forum that was apparently part of a much, much larger automobile forums company. The company got hacked and apparently their password database was compromised, so as a reaction they now required their users to have twelve character complex passwords, changed monthly. Because they, not the users, screwed up.
I stopped bothering going to them. I am not going to put up with those kinds of password requirements to talk about skidplates and tires. They are not a bank, I have no financial connection with them, arguably even the password itself is not that important on that site, it's very unlikely that anyone is going to care to impersonate me as there simply is no benefit to doing so.
Of course you are right - but how to make it stop (Score:5, Interesting)
Re: (Score:2, Interesting)
Just say no to most of the things that require a password. Most of them are worthless anyway.
Only post anonymously to /..
Quit forums and registration-only websites. You'll find you're getting more free time and less Internet-induced anxiety.
Scuttle your StackOverflow account. It's taken over by H1Bs.
For professional work, use other means of authentication such as crypto keys. Manage professional accounts with password manager and 2fa.
Use long passphrases and 2fa for local logins. Scrap stuff like "clou
Re:Of course you are right - but how to make it st (Score:5, Funny)
Make sure the creases in your aluminum hat are sharp and at a 60 degree angle.
Let me see what I type (Score:5, Insightful)
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.
Re:Let me see what I type (Score:5, Insightful)
Also, please for god's sake let me see what I type.
^^^^ This this this.
I use some long password phrases and I occasionally make a mistake when entering them. If I was able to see the characters I'd be able to correct my typo. This is especially annoying when using the craptastic user-hostile user interfaces on TVs where you have to dick around with the remote, slowly bumping along from letter to letter at a snail's pace.
Re: (Score:3)
Re: (Score:2)
Re:Let me see what I type (Score:5, Funny)
Re: (Score:3)
let me see what I type.
IE started doing that in Windows 8, still has it; and now in Win 10 Edge does too. So you might get what you want by switching OS's?
Re: (Score:3)
Re: (Score:3)
So does Android.
Obligatory XKCD (Score:5, Informative)
https://www.xkcd.com/936/ [xkcd.com]
Re:Obligatory XKCD (Score:5, Interesting)
I remain in disagreement that that is the best approach. It gives you needlessly large amounts of typing for little entropy. Acronym passwords are better - think of a sentence and a rule for turning it into a password (the simplest just being using the first letter or two letters of each word).
Sentences are easy to remember than four random words, the resultant passwords are shorter, and while the search space can certainly be reduced by statistical means, it's not nearly as much as with four random words. Aka, if the last letters the person typed in were "stapl", what do you think the next letter is going to be?
It's worth pointing out that XKCD's pretense that four random words are easy to memorize was based on them choosing four easy to memorize words. If I just have /usr/share/dict/words pull up random words for me, here's the first five passwords it comes up with:
cytopharynx Gasperoni gastroplasty revolutionising
reacidifying bosom-breathing sipers down-in-the-mouth
text-writer clubbed midfields Shuqualak
Malkite phthisiology BLM improbabilize
weaves Whiggamore unspirally Exod
Yeah, best of luck with that. By contrast, if I convert the previous sentence into an acronym password, I may get something like (depending on what rules I use):
Y,bolwt. .... etc. Choose your own rules. But you won't forget "Yeah, best of luck with that"
Yebeofluwith
yEbE0FlUw1tH
Re: (Score:3, Insightful)
So, your primary counterpoint is that you did not read the original point and instead of having a tool randomly pick four words from your common vocabulary, you asked a tool to pick four words from a lingual mix of English, Greek, Latin, proper names, and acronyms?
I have a better password for you:
uninspiring straw troll Slashdotter
Re: (Score:3)
I use DiceWare.
http://world.std.com/~reinhold... [std.com]
Re:Obligatory XKCD (Score:5, Informative)
It's a good thing that XKCD's Munro doesn't choose four random words from /usr/share/dict/words then, isn't it? The cartoon shows 11 bits of entropy associated with each word. That means a dictionary size of 2^11: about 2000 words. (In contrast, a typical /words file might have a hundred thousand entries. That's fifty-fold larger, so you get about 5.5 extra bits per word, but would indeed lead to the utterly useless output you've shown.)
The General Service List [wikipedia.org] contains the top 2000ish most-often used words in the English language. I used the version compiled in 1995 and found here [jbauman.com], mostly because it was the first version I could grab online. Pulling random words from the first 2000 entries, the four words I got (on my first three passes) were:
competition behave exact toward
experiment miserable there lord
spare page circle rabbit
Right out of the box, it's not what I would call a disaster, though a few of the words are a bit cumbersome, length-wise. (For reference, your /usr/share/dict/words selection only contains one word - "weave" - from the GSL.) If you started from, say, the top 5000 words, you could probably cut it down to a 2000-word list where every entry was non-obscure, had between 4 and 8 letters (the average word in the GSL has a length of 5.8 letters), avoided difficult-to-spell words, and eliminated similar-sounding words.
Re:Obligatory XKCD (Score:5, Insightful)
You're missing part of the point of the XKCD. It's not just about choosing four random words, it's also about constructing a mnemonic to remember that password. That's what the image with the horse is all about.
And it works.
The day I read the XKCD, I changed my home domain password policy. I pulled out all the annoying requirements like must have upper case, special character, number, etc, and extended the length requirement one to 20 characters. That's it. I then showed my family the xkcd and made sure they understood what I was after. They grumbled. The excuse I heard from every one of them was 'I suck at choosing passwords'. I helped them through that, and after they got used to it, they didn't grumble anymore. Sadly, I've had quite a bit more difficulty getting them to use password managers, though I hope that my dire threats of doom and revoked network access have made it clear that they don't use their home domain password for anything else.
Professionally, I've tried to get my companies to see the light, but they remain stubborn and insist that the special character requirement is good enough, and about the only way I could disprove that would be to launch an attack to prove otherwise. Since that is likely to be a resume generating event, I have so far declined that option.
I think the most irritating work password experience I had was when I started using long passwords, routinely over 20 characters.... until I ran into an internal app that, despite using Active Directory for authentication, restricted the password field to 12 characters. Apparently web developers don't understand the logic of 'if you're going to use AD, and AD accepts longer passwords, your app should to'. That's when I wrote my own damn app to mimic the same functionality.
Re:Obligatory XKCD (Score:4, Insightful)
Re:Obligatory XKCD (Score:4, Funny)
Aka, if the last letters the person typed in were "stapl", what do you think the next letter is going to be?
In what circumstances would I know what the last letters the person typed in were? Passwords don't work like that. The only circumstances this may be known is with a key-logger, in which case all bets are off. I don't have to work out what the next letter might be. Just wait and I'll be told.
But I've seen in Hollywood films how they attach a device that cracks passwords one number/letter at a time.
Mysterious rules are worse (Score:5, Insightful)
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?!!
Re: (Score:3)
Set the appropriate options in KeePass that include a minimal superset of the permitted symbols, then click on the "Preview" button. You'll get a thirty sample passwords, at least one of which should fit the requirements - copy and paste it. If not, switch out of the Preview tab and back to get another set until you do get one that works with whatever subset of special characters
Re: (Score:3)
The symbols thing always bugs me. "You must use a symbol in your password", I *DID*! Please tell me which symbols you're going to accept so I can try again! (some of these only allow symbols that appear above the number keys on a standard US keyboard, which means ,./?;':"[]\{}|~` all don't count, others allow some subset of those, but not others, it's impossible to guess)
It's very apparent that every one of these rules decreases password security, every one decreases the amount of space an attacker needs to
What is truly bullshit... (Score:2)
...is the fact that we supposedly have all these methods of forcing users to create more secure passwords, and yet those "top 10 worst passwords" lists that come out every year haven't really changed in fucking decades.
Obviously neither has the mentality towards online security.
Why you ask? I don't know. Ignorance? Stupidity? Don't give a shit? Doesn't even matter why anymore. Rather obvious nothing will change.
Re: (Score:2, Insightful)
How about this reason: I don't care for the account in the first place.
Simple scenario: I want to use a website once, but it requires me to "register an account". Why? No idea. I have absolutely no need for one and don't care if it's "hacked". For all I want, you can throw it away immediately. So I'm going to register the following account.
Username: johndoe123
email: johndoe@mailinator.com
password: 123456
Go ahead, "hack" my password, reuse my account, whatever. I don't care.
Once the site gets breached, I'm a
Re:What is truly bullshit... (Score:4, Funny)
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.
Think... (Score:2)
Re:Think... (Score:5, Insightful)
When my passwords get pwned, at least I can change them. When my biometrics get hacked? I'm SOL.
Re:Think... (Score:5, Interesting)
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.
Re: (Score:3)
For those types of security questions, I pick a favorite character from a radio program, or tv show. Tada!
What was the model of your first car? Marty McFly -> Delorean.
They are as implemented (Score:4, Insightful)
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.
Re: (Score:3)
Maybe we need to re-think things.
Is a single letter password really insecure? or extremely secure?
What password testing system would even bother testing for it? it's simply assumed it can't exist.
"more entropy" is only useful if the attacker is using the same assumptions you are.
Password rules aren't consistent (Score:4, Interesting)
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.
Yes (Score:2)
Length is good but complexity doesn't really help if you have a good lockout policy and good monitoring.
Complexity rules just mean that a) people write it on a sticky note and stick it to their monitor or b) constant password resets / helpdesk calls.
Dana Carvey's son, is that you? (Score:2)
Are you really Dana Carney's son?
https://youtu.be/tN-LJ7w5pwQ?t=51s
Provides Info to Crackers (Score:4, Insightful)
Not just composition rules... (Score:4, Informative)
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.
Re: (Score:2)
That last problem can easily be thwarted. Take your average user and let him enter his username and password. How long does it take him? 2 seconds if he's fast. 5 seconds if his name is long and he's a slow typist. So simply implement it in such a way that between two tries you have, from the start, a 2 second delay. That means at best 30 attempts a minute, 180 attempts an hour, 43.200 attempts a day.
Even if you know that the password is four letters long and only lowercase, you'd need about a week to brute
The Only Rules (Score:2)
I might accept is that if the language the app is written in has certain key delimeters (% sign, period for PHP, # for ColdFusion) I could see blocking those in passwords to reduce the risk of an injection attack.
And then there are the sites. . . . (Score:4, Insightful)
. . . .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. . . .
Re: (Score:3)
And then they tell you next rule you've failed.
And then the next.
And then you find that in fixing rule fail 3, you've inadvertently breached rule 1 again.
Then you want to kill the designer of the website and can't bear the idea of going through the process yet again. So you put in the simplest password you can think of that can't possibly fail. Well done, designer, you've beaten all complexity out of my password and reduced it to
Re: (Score:2)
Rainbow tables (Score:2)
I keep thinking about. . . (Score:2)
. . . .the original Facebook technique of using "Chuck Norris" as a password [gizmodo.com].
Because NOTHING can defeat Chuck Norris (grin)
Most password rules are bullshit (Score:4, Insightful)
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.
3 Tries? (Score:4, Interesting)
For God's Sake, it DEPENDS (Score:2)
I'm furious when certain newspapers or other non-important or non-financial websites force me to use combinations of letters, symbols, capitals and numbers. They are actually trying to make sure I don't give my password to other people to read their content, they aren't protecting ME from anything. That forces me to either a) disclose my important password techniques, or b) create an even more difficult to remember password for a site that's considerably less important than my bank, etc. Worst case are (a
The standard rules are stupid but... (Score:2)
A minimum length, a maximum age, and a requirement to include upper, lower, and a special character are good things.
Length, case, and special characters all massively increase the search space and help to defeat brute forcing and rainbow tables.
People who insist on stupid passwords like, "OM#*&!N!lkjasdf_###7" are the problem. Such passwords are difficult to remember (or type!) and easy to crack. Use a normal sentence (or two short ones) with a proper noun somewhere in it and use normal punctuation.
Random Password (Score:2)
"123" is also a legitimate result of a random character generator. It is a bad password no matter how you come up with it.
They are "follow-the-ritual" without understanding (Score:3)
I have been annoyed by this for a long, long time. Put in a 100bit+ entropy password and the moron that implemented this has his software claim that your password is "insecure". Seriously, all lowercase letters and digits at random is about 5.2 bit/character in entropy. Lowercase letters, digits and a special symbol (and who does not just append a "!") and an uppercase letter (and who does not simply make that the first) is, *ta-da* 5.2bit/charabter entropy! Of course, making random places uppercase or a random symbol would be a bit better, but even that would only be 6.1bit/character in entropy (with 10 possible special symbols), i.e. it does not really matter.
Password rules are complete and utter nonsense perpetrated by people that value rituals over understanding and that, in addition, have none of the latter. Of course, many things in IT today are done by ritual and not by understanding, but this is one of the most stupid ones.
Security levels (Score:3)
The problem isn't password rules. The problem is the idea of security levels.
For a site like /. or soylentnews.org, just about any password should be allowable. This is a password you will likely use on lots of different sites. Also, the password should never expire. Account should be locked if a thousand bad passwords in a row are tried. The password reset should go to your email, and you should not have the ability to change your email address (but you can add a secondary email address) for a month after a password change. That way if someone breaks into your account you can get back in afterwards.
For your home computer, it should also allow any password. Passwords should never expire. The account should never be locked but you have the option of added security (ie: encrypted home directory).
For work, a more complex password that changes every six months to a year.
For your banking, a complex password that changes every year or two. Account lockout if 10 tries in a row fail.
For your email account, two factor authentication all the time and a password that needs to be changed every 3-6 months (since your email is used as a lockout to all the other possible accounts).
Re:Security levels (Score:4)
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.
Password Guessing hasn't been the problem! (Score:3)
Think of the big breaches, which I tracked until about five years ago... In the Zappos [zappos.com] breach, hackers broke into their system and stole their database. They didnt guess passwords, just stole them.
In May 2005, GMail was hacked... via JavaScript, [darknet.org.uk] exposing contacts, personal data without cracking (or exposing) passwords.
When CardSystems Solutions [ftc.gov] (a payment processor) was hacked and 40 million credit card numbers stolen, it was by SQL Injection. Fust full names, addresses and passwords exposed without any password guessing.
TJX (TJ Maxx, a retailer) lost 45 million credit card [squidoo.com]records in a hack... by unprotected WiFi and unencrypted records.
Google's AdWords system by surrupticious files being installed. User passwords were stolen.
About ten years ago, Internet Explorer (yeah, I know...) facilitated look-alike sites to steal Hotmail (Microsoft), GMail and Yahoo passwords... but complexity or guessing were not the issue.
When Epsilon Data Management was hacked, it wasn't via guessed passwords, but they were stolen, compromisingcustomer accounts on Citibank, Chase, Target, Walgreen and Best Buy.
LinkedIn [linkedin.com], the professional networking site, had six million passwords cracked-and-leaked in June 2012. The process was an attack on the server storage encryption [mashable.com], not on password strength.
The stupid thing was, when Zappos was hacked (again, not via password theft), they then decided to impose stringent password requirements. Amazon doesn't have such stringent requirements, so just for ease I've switched most of the purchases (about four a year) I used to do from Zappos over to Amazon.
Passwords (Score:4, Interesting)
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.
Yes, They Are God Damned Bullshit (Score:4, Interesting)
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.
Complex password rules are a sign of bad IT. (Score:3)
None of this is magic. We have known that this is required of IT security since the mainframe days. Defense in depth with different security layers is not just a good idea. It is central to all effective defense planning for thousands of years. However, instead of doing good IT security, we attempted to push the burden and failings of IT onto the users via complex password rules.
Of course, there should be some password rules. They should look more like:
Apropos joke in inbox today (Score:4, Funny)
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.
Better than having secret rules (Score:3)
Worse than that are the systems which silently truncate at a set length, or at the first unacceptable special character. Or which truncate at password creation, and handle logins with a different parser...
Re: (Score:2)
Where I work at we have both password rules AND mandatory password change every month... MONTH! Who the hell comes up with these stupid arbitrary ideas about security?
Who? Probably someone who doesn't use a computer.
Arrgh, what a system. Now you probably have people writing down their passwords, and storing them in their wallet or purse, or worse, the traditional "under the keyboard". Then the IT department is probably spending a lot of time resetting passwords when the people who do it correctly forget their password. Over and over
Re: (Score:3)
storing them in their wallet or purse
When I was on a corporate security we actually used to suggest this! You could gbe disciplined if you were caught with a password on a sticky note attached to monitor or under a keyboard but we told people it was okay to write them down if they must provided they keep it in their wallet or purse. This was our official policy.
Why?
Most people notice a wallet or purse missing almost immediately! Certainly within hours. Which is still on the pretty good end of compromised password detection. We simply told
Re: (Score:2)
ITSM checkbox auditors. "Having a password policy" is a checkbox they can tick off, "having a password rotation policy" is another one.
Nobody asks if that makes sense. What matters is that you implement it. And these are quick wins, because it's trivial to implement.
Re: (Score:2)
Re: (Score:2)
It is near impossible to create a sensible password strategy that satisfies the three core demands: Easy to remember, hard to guess, hard to brute force.
Go ahead and define one. And then sell it, good money will certainly be paid for something like this.
Re: (Score:2)
First, system designers tend to be clueless about security needs of their own system.I want my bank to require strong passwords. I don't need some discussion forum about, I don't know, aquarium cleaning or salt shaker collecting to need a 10 digit password with numbers, letters, and punctuation marks. It's annoying.
Second, human beings aren't digital storage units. The harder the password to unlock, the more likely we are to either use the same password everywhere, significantly reducing
Re: (Score:3)
The bullshit is not in the passwords, the bullshit is in the people. Or rather, demanding that people remember that character salad.
Yes, those passwords are great. Especially "&2lkjf(82ld0*@#jmG73". Awesome, strong and secure. And now have a person remember this. No chance. None. Zero. Zip. Maybe there's some dedicated aspies that can, but most of the people you have in your office will look at you like you asked them to do a multidimensional integral in their head. Or they'll question your sanity.
What
Re: (Score:3)
And now ponder needing this password once a week. Still memorable?
Also let's not forget that we are dealing with people here who have anything but security on their mind. They want to get their work done. Security is for them, at best, a nuisance. At worst something that stands between them and doing their work.
Take a security door that swings closed after someone went through. Now imagine someone who has to carry heavy boxes through this door. This would mean that he carries the box to the door, opens the
Re: (Score:2)
That depends on the situation. In most circumstances, you're right. If you have no control over the servers (read: If you're dependent on a supplier) you might want to implement a changing policy, especially if you can't rely on them reporting a data breach reliably and in a timely manner.
Re: (Score:3, Funny)
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?"
T