Slashdot Mirror
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/
Arbitrary constraints on passwords, with no math justification, actually reduces password complexity.
Most people reuse passwords, which is a weakness beyond the control of silly "password rules".
No matter how complex^W annoying the rules are, incompetent implementations store the passwords in plaintext.
Your typical web service security is next to non-existent and you dare imposing "password rules" on me?
Big companies are terrified that they'll be hacked, it'll be the big story on the Internet and the details of their sloppiness will include stuff like "they did not require employees to change their passwords every 90 days, even though that is considered standard best practice." So the CIO gets fired, and is followed out the door by the CEO a year later.
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?!!
While statistically it's possible to generate an all lower case letter password, because the attacks are not statistically random it's better to exclude the patterns that are disproportionately likely to be attacked.
As an example, I suspect everybody would reject their random string generator password in the one instance where it generated "password" because, while it can be randomly generated, it's not randomly chosen for attack. (That same logic extends by people that look at brute force hacking tools that run through words and letter combinations; that rule was created because of studies about types of attacks.)
...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.
There are two layers of responsibility for passwords.
1: The user; his job is to make sure that the password is known only to him.
2: The service provider; his job is to make sure that passwords are not stored in plaintext or transmitted through unsecure methods.
Nowhere in my post does it say that the password itself has to be secure, only the method by which it's stored and transmitted.
If someone has a weak password, tell them it's weak and the ramifications of such. If they insist on having qwerty as their password, then that's their choice. You know what's a major security issue? "Security questions". According to CNBC, 550,000 people were victims of identity theft by someone they knew in 2014, people who would know their dad's job, their pet's name, and the street they grew up on. Such fixed questions only encourage, allow, and endorse such crimes. Any company that does not allow you to pick your own security question should be treated as accomplices to identity theft.
Think it might be worse than that, think it might be that passwords are bullshit and no longer provide much of any protection. How do people feel about biometrics?
Why do I even need a password? Let me prove myself once, then put a token on my device. For the love of god, stop the password nonsense already!! Especially on my phone. If I am using your app on my phone, and I've proven myself already, and I have a secure password on my phone, that's enough. Just put a damned token on there and be done with it!
Guess what, all you "security experts" who think your fancy rules make passwords harder to crack?
GET THE FUCK OVER YOURSELF!!! YOU'RE NOT THINKING!!!!
All you're fucking doing is making sure everyone comes up with patterns and procedures to try to remember the fucking nonsensical password that's impossible to remember that your asinine rules are forcing upon us!
So, in your arrogance you create requirements that say "Don't write down your passwords, and don't use patterns to help you remember."
KNOCK IT THE FUCK OFF YOU BRAINDEAD DUMBFUCK!!!!!!!
ARE YOU TOO FUCKING STUPID TO NOTICE THE "NONSENSICAL PASSWORD THAT'S IMPOSSIBLE TO REMEMBER?!?!?!
Get this you ANENCEPHELIC TWIT: I HAVE TO REMEMBER MY PASSWORD TO DO MY FUCKING JOB!!!!! But I might not need to use THAT ONE more than once every week or so.
Yeah, I deal with the rules these brain-dead JACKASSES come up with every day.
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.
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?
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 "cloud" storage because they're there to TRACK YOU.
Get a dumb phone and set up Sim card PIN lock and screen PIN lock.
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.
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.
Do we have to continue having this bullshit debate?
"password" has an entropy of 28.7 bits and will be cracked more or less instantly
Now, let's require one capital and one number:
"Password1" has an entropy of 40.4 bits and is 3326 times stronger.
Now, let's required at least 12 characters:
"Password1dogs" has an entropy of 61.9 bits and is 9,867,243,735 stronger than "password."
Now, let's require one special character and forbid using repeating characters:
"Pa%sword1dogs" has an entropy of 63.4 bits and is 27,908,779,827 times stronger than "password"
Now, let's use my Windows password at work.
"&2lkjf(82ld0*@#jmG73" has an entropy of 93.3 bits, which is 2.796 x 10^19 times stronger than "password"
Requiring people to use strong passwords is not bullshit.
>> Password rules are bullshit.
Are you really Dana Carney's son?
https://youtu.be/tN-LJ7w5pwQ?t=51s
While we're at it, lets point out that password rotation does nothing but piss people off and make them chose poor passwords. NIST recommends against it.
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.
Even password managers adds a layer of risk because it's yet another potential target. Creating a solid password works wonders in protecting you online. Many simply don't take the time to create a good password when they sign up for a site. Or they make up one easy to remember but also easy to steal. I for one would like to see something better than passwords. But until then, the less layers of security and more emphasis on a good password to begin means staying safer online.
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.
I fully support Jeff's opinion there. All of the systems I have seen that implement strict rules have people invent easy-to-remember, yet extremely to guess passwords that pass the rules. It is my firm belief that password rules make passwords way more insecure.
Understanding is a three-edged sword. --Kosh
I used to have a single password for everything. Then more and more websites started bothering me because it only had lowercase letters and numbers. Once I couldn't remember all these unique passwords or which sites had them, I made the switch to a password manager. Yes, sometimes I have to click on "generate" a second time if the first password messes some rules, but that's not a big deal.
. . . .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. . . .
I want no rules for the password itself, but use rules to change it's duration.
8 alphabetic characters = 1 week
8 alpha/numeric characters = 2 weeks
10 upper/lower case, numbers punctuation etc = 3 months
Basically, reward strong passwords appropriately.
Are you sure that's random?
http://dilbert.com/strip/2001-10-25
It's a valid argument that holds weight, and I'd even take it a step further than the how involved with general users going around the rules to keep making new passwords is really... scary, predictable and in the exploding age of AI, machine learning and modeling, these rules, are indeed, a joke. For instance...
Just what I observe and know to be true: I can't tell you how many people who don't even know what 5cr1p7 k1dd13 language blantantly substitute all the letters of S, E, A, I, T and B for 5, 3, 4, 1, 7, and 8. Well that's an easy substitution and gives you a very 1:1 substitution pattern. Then simple typing patter heuristics will get you a bit farther to predict what/where most people 'prefer' to hit the shift key, which is mostly at the beginning or very end of a string. Coupled with all the password advice of using shitty, generic and way overused mnemonics, it gives a good solid guessable foundation for completely arguing it's mandatory bullshit, indeed. I didn't even sneak in the fact that a lot of people just use very linear and horizontal patterns on a keyboard, then on next password change, just shift over 'a key' and do it all over again. That ensures, to the end user, that they'll never reuse a password ever within a bullshit 'last reuse history' rule, but that's even MORE guessable than just making your own rainbow table on predictable typing behavior and mnemonics alone.
Now the question is, would I actually not use it in my own organization like Jeff Atwood wants? Absolutely not. Because then I'm absolutely positive the old 'top 10' commonly used passwords will for sure be in full damn effect. I'd prefer to feel ignorantly secure with the end users I administer around me.
Could be worse. I worked for one company that had a homegrown app, central to the place, that had Draconian PW requirements. Every 30 days, the password had to be changed, it had to be at least 12 characters, symbol, uppercase, lower case, and number, etc. The nasty thing was that if one fumble-fingered their password more than three times, their account would be deleted. Not locked, deleted, as in BOFH style clickety-click.
Of course, one disgruntled employee decided hide a deadman script when he was shitcanned, after finding out everyone else's username. Caused a week of downtime because even the admin accounts were removed, and because the app was made from a cookie-cutter offshore contract house that was dropped as soon as the app was live and working, getting people who could do something took a while and a lot of cash.
I await the day when every password is in a rainbow table anyway, no matter what rules you use. It can't be far off so passwords aren't sustainable. A lot of people have my fingerprints so that is not useful for authentication either. What do we do next? Some sort of mandatory certificate based authentication for everything?
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
. . . .the original Facebook technique of using "Chuck Norris" as a password.
Because NOTHING can defeat Chuck Norris (grin)
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?
I have more than a few accounts that I dont bother making any attempt at remembering the password & just use the password reset system every time i log into it.
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 poor fools who use their important bank password for a bullshit local non-important site where a snotty 20 year old has access to all the customer passwords.
In other words, the answer is "it depends".
Gently reply
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. Easy to remember, hard to crack.
1. The system will choose a 26-letter random password for you, consisting of letters, numbers, and symbols that aren't on a US keyboard.
2. It will change every month.
3. If you write it down, you're fired.
"123" is also a legitimate result of a random character generator. It is a bad password no matter how you come up with it.
Troll is not a replacement for I disagree.
Either the site restricts the number of incorrect guesses, in which case "123abc" is a safe password, or no password is really safe. If the site allows a botnet to hammer the site with trillions upon trillions of password guesses a second, no password is safe.
Troll is not a replacement for I disagree.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The rules at work got so complicated that I ADDED a personal rule: must contain at least one vulgar word.
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).
Help! I'm a slashdot refugee.
Back then (it was in the 1980's), one of the password recommendation from CompuServe was to use two absolutely un-related words, and separate them with a star (*). Fast forward today, and this should still apply today, unless the words cannot be from a dictionary, which makes sense. And if you have to change the separator, use a dot (.), an ampersand (&) or whatever else that can work. So a password like "Keyboard*Lasagna" could satisfy most requirements. And you can even add digits at the end. I could then remember a password like Keyboard*Lasagna1998 because I made a mess of Lasagna on my Keyboard in 1998. Also, now in 2017, there are so many passwords to remember, and you should keep them unique, that utilities like LastPass help so much remembering all those passwords. Another technique is to have cryptic notes for password reminders, that with two letters, remind me of the actual long password, with variations across sites or networks.A reminder paper under the keyboard us completely useless... to others than yourself !
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.
Do we have to continue having this bullshit debate?
"password" has an entropy of 28.7 bits and will be cracked more or less instantly
entropy is the wrong metric here
hsorgsrx has the same entropy (8 lower case letters), but won't be cracked BEFORE the actual brute force attack (where entropy matters) is launched. Your 10 year old kid would probably try typing "password" manually before even thinking of which automated tool to use....
bickerdyke
2 and 3 are among the possible random prime 512-bit prime numbers, but any good "random 512-bit prime number" rule for crypto should reject these outright. Likewise, a random password generator that purports to create "reasonably secure" passwords should filter out anything known to be in password-cracking dictionaries or anything that is easy to derive from them (p@ssword1, passw0rd2, etc.).
Like any access-control system, a password should be "hard to compromise, but easy for you to use when you need it" - whatever that means in your particular case.
"Easy to for you to use" doesn't necessarily mean "easy to remember" - if you are using a password-keeper system, you only have to remember the master password, not all of the individual passwords in your "vault."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If I ever incharge of a system, the only rule would be that the pass phrase had to contain a space and neither the last nor the first character could be a space. I think everyone would have to create unique passwords for that system.
Think of the big breaches, which I tracked until about five years ago... In the Zappos 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, exposing contacts, personal data without cracking (or exposing) passwords.
When CardSystems Solutions (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 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, the professional networking site, had six million passwords cracked-and-leaked in June 2012. The process was an attack on the server storage encryption, 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.
Different coward here, but to be honest, I find it exceedingly nuts to have to have a while slew of accounts for every thing you're wanting to talk to. I get that it gets rid of trolls and keeps people who want to sincerely discuss or use a service, but it still tracks you.
To be honest, even commenting on Slashdot as an AC leaves breadcrumbs to follow, but the counter question to that is where is the privacy and security meeting point with let's say Google/Alphabet's sign in policy? I get that it's convenient that their services can be logged on to with one single password, but why do I log on to Hangouts automatically by default when all I want is to check my mail?
Why can't _I_ pick and choose?
Before you say I can turn Hangouts off, I know. But there lies another issue. I can't set myself invisible. Some days I just want to speak to someone in particular. Not let everyone know I'm around AND get pissy when I'm working on something with someone.
Reset passwords, doubly so.
WARNING: Smartphones have side effects--most of them undocumented.
Yes, password rules are BS. My bank requires me to have a password that contains uppercase, lowercase, numbers and at least two symbols. All of which is rendered pointless by limiting the password length to 8 chars. Luckily I have 2 factor auth, but still.
Weak/strong password strength indicators, on the other hand, can be useful if done properly (and harmful when done by people with no grasp of combinatorics). Many people have no idea what counts as a strong enough password nowadays, so even a simple indicator that takes length and character variety into account can go a long way.
Ineffective against against the mind control matrix the lizard people are projecting from the hollow core of the moon. I recommend two or three coats of a turquoise paint such as Pantone 13-4720 TPG to cover both cases.
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.
If a poorly-salted password database is compromised today but the breach isn't discovered until this time next year, a 1-year-expiration would mean everyone's password would have expired or been changed already by the time the breach is announced.
Personally, I would tie expiration to complexity: I would allow trivial passwords like "password" with a 1-hour expiration, slightly-less-trivial passwords with an expiration between an hour and a week, moderately-strong passwords with longer expiration times, strong passwords with expiration times around a year or two, and super-strong passwords with an expiration time of maybe 5 years (on the assumption that in 5 years bad things will probably happen to at least a few of my customer's passwords without their knowledge). There will of course be special cases where a password will need to be "longer than 5 years up to forever" but those will only be allowed for certain situations, and then special rules will apply.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The #1 rule, about password length, is supported by the article. If you randomly generated a low-complexity password, you should re-roll, and the article supports this with a new rule based on an entropy calculation hidden to the user. The complaint that the rules frustrate those who pick weak passwords is not fixed by the new proposed replacement rules in the article (hidden entropy calculations and checks against common passwords).
No. But 'articles' like this are.
Programmers who implement bullshit password rules, then keep the rules secret until AFTER you submit the form, should be frogmarched straight to perdition.
Completely agree random letter/number/symbol requirements and periodic expiration are extraordinarily lame.
Requiring people to change their passwords often for no reason just encourages them to cheat by necessity of being human in some way.
Stupid complexity requirements that don't understand objective function is maximizing entropy at the least expense to human people actively makes outcomes worse for everyone. The real world outcome of most of these systems is symbols and numbers are typically placed at the end of the password making brute force attacks easier than simply enforcing a minimum length.
There are some points I strongly disagree with.
Requiring hashed passwords and password amplification measures.
In my view the most dangerous aspect is the delusion operators thinking hashed passwords are somehow secure. They are NOT. No matter what you do any sufficiently large and or valuable password database that is hacked will be easily reversed even with SHA-Infinity PBKDF-Infinity key stretching because expecting people to actually chose a password capable of surviving a brute force campaign is asking too much and has a history of well documented failure. It simply isn't a rational option.
My advice for protecting passwords is to break up system to use dedicated authenticators who do nothing but authenticate. Application passes users password (encrypted with keys application does NOT possess) and secure authentication protocol stream to authenticator which authenticates user and passes back a result to app. This way even if app is compromised stored passwords remain are useless even against dictionary attack. The authenticator has a limited attack surface compared to your typical password protected application.
Skimping out on reversible encryption of storage because passwords are hashed is an extraordinarily bad idea that continues to end in disaster after disaster.
The other problem with hashing it actively discourages secure authentication mechanisms. The goal here is to maximize overall systems security not just maximizing one aspect such as secure storage. When you rely on hashed passwords you actively discourage the use of more advanced mutual authentication protocols (Zero knowledge PAKEs) that leverage mutual possession of password to establish end-end trust relationships. Yes you can use hashes by proxy but these systems already have "verifiers" in place which effectively do the same thing.
With these systems:
1. Backend password hash format has to be explicitly supported by authenticators including crazy schemes to transmit salt keys to authenticating user.
2. Knowledge of hash weakens security of these systems because it effectively nulls the "mutual" part of the authentication enabling impersonation attacks.
In short the problem with passwords is not the passwords themselves it is the insane concept users should be required to provide passwords capable of surviving off-line brute force attack to ensure the integrity of YOUR system. History has already demonstrated this delusion to be false.
Pet peeve, those password rules of Microsoft.
At one time, when password rules weren't so strict yet, my password contained some letters (lowercase), digits, and a unicode character you won't find on any keyboard, so it could only be entered by Alt+Num Keypad.
I thought "let those dictionary attacks attack _that_".
Then came the new times, and my password was deemed insecure because it didn't contain tree out of the four categories they *do* know about in Redmond. It contained a fifth, but that didn't count.
by enforcing one of those stupid "passwords must contain..." rules, you're actually mathematically reducing the number of possible variations for a given password length, and also making it far MORE predictable, not less.
All my password have at least one ASCII character which needs the Alt-### to generate. Such as ôA]£ï
Mandatory complex passwords reduce the number possible passwords.
I see this a lot. Required 8 characters, one upper case letter, one lower case letter, and a numeric digit. If someone trying to crack accounts knows the password requirements, that person knows that passwords with all capitals, all lower case, and all numeric digits don't have to be tried.
...is that the more complicated and involved the rules are, the more they invite (require) someone to WRITE THE PASSWORD DOWN somewhere.
I can't count the number of times I've sat at someone's desk and their password(s) were either taped to their monitor, their deskpad, or under their deskpad/keyboard.
So what, precisely, is THAT protecting against?
-Styopa
Summary of the article:
- The author says password rules are bullshit,
- The author presents a hysterical strawman of 8 password rules
- The author says password rules are bullshit,
- The author makes a prescription. The only password rules you need are, (1) (2) (3) (4), many of which are on the original list.
- The author says how embarrassed he was not to enforce some of these four password rules on early versions of his software.
- After saying how important password rules are, the author again says password rules are bullshit.
This is what happens when web designers try to form arguments.
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.
how about deciding if the site needs that level of security?????
if the site has no private information, no e-comerce, etc. why in the heck do I need 1 cap, 1 lower, 1 number, 1 special char. ???????
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 monitor or throttle login attempts. What you may have is people using sticky notes and plain text files stashed on their PCs, but pointing them to a good password manager (keepass/keepassx) fixes most users who find those more convenient than rooting around for files and papers.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
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 ]
One of my student loans just implemented really bad (forced) 2-factor authentication. You log in, it pops up a login box that says it may (not even definite) send you a code by email. If you dismiss the box, the code is never sent and you see the login form again. If you click the OK button correctly, it takes at least 5-6 minutes for the email to arrive, and if you request another one while waiting it invalidates the first one you were waiting on. And they don't necessarily even arrive in the order you requested them.
Why can't _I_ pick and choose?
Incognito ("New Private Window", "InPrivate", Porn Mode, etc) solves this "problem", does it not? Visit one site, log in, do your thing, close browser window. No fuss, no muss, no cross-site anything at all. Built in to every major browser AFAIK.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
so I know what they are and don't have to generate 6 passwords trying to deduce them from the error messages that keep coming back at me.
My institution requires this: Minimum length of 8 characters and at least 3 of these 4 classes ( uppercase, lowercase, number, special chars, UTF-8 chars other than lower/upper) I use the CorrectHorseBatteryStaple method for password generation for all entropy, and use a simple algorithm to "comply" with the rest, which I consider bullshit. In a nutshell, I use a cryptographically-sound PRNG to select 5 words from a list of 2048 common English words, capitalize the first letter of each word, then append them together with a dash (space isn't counted as a special character on all systems here). This satisfies the requirement for 3 of the 4 classes and minimum length while still being easy to memorize. The key to the soundness of this method is to let a RNG (or good PRNG) select the words for you. Users picking their own password is the main criticism of the CorrectHorseBatteryStaple method.
If I use to have 1password as my pass, it worked for me for years (that wasn't really it). Then that stupid rule came by and said I had to have a capital. 1Password . Okay fine.
Then in 2010, that stupid ass rule of the special character had to come in to effect. !1Password .
I think there should be a suggestion, but not a mandate.
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?
A good password manager will not only create robust passwords but integrate into the file manager with the ability of a timed copied to the clipboard of both user names and passwords.
Attackers use probabilistic models to break passwords, but the rules that we typically use to defend against them are typically quite bad.
So, there is a pretty good password strength checker that we can use: https://github.com/dropbox/zxc... .
But we can even do better: a couple of years ago, with a colleague, I've written a paper to show how you can evaluate pretty precisely how much work attacks using probabilistic models need to break your passwords (http://www.eurecom.fr/~filippon/Publications/ccs15.pdf); since then, I've released the code online (https://github.com/matteodellamico/montecarlopwd). If anybody is interested in using it in the real world, please contact me!
matteo
-- Matteo
I've never understood the argument for changing your password monthly. Let's assume your password is attacked on its first day. Surely it doesn't take a month to hack it. What are the odds that it will be attacked on its thirtieth day? And the new one is just as likely as the old one to be attacked, so what's the point?
I understand how they can be a security risk but I think the way I use it won't help an attacker.
Here's an example. My mother's godfather had a nickname that he used to call me. I haven't talked to anyone about this in over 30 years. If my password hint is "D. W. nicknamed you this", I would immediately remember what the password is but no one else would have any idea of what it is.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I found a method that worked for me - pass phrases. Since most sites are hashing your password anyway, why should there be an arbitrary limit on the LENGTH of the password? The most frustration I have had is when a site refused to accept my password, because the original password phrase was 35 characters long, and they had imposed a 16 character limit since I'd signed up for the service. "Oh, and you can no longer use a space as a character!"
I think I used "WhatADumbPolicy!"....
The problem isn't so much the B.S. rules they've chosen for limiting passwords.
The problem is they have a very different idea of the importance of whatever it is they're protecting than I do.
I'm just reading your website, not protecting gold bars. What do I care if someone impersonates me on a random blog?
Who am I protecting when I pick a password for my work account?
Why should I suffer to reduce your risk?
Not only bullshit, but no two sights' requirements are ever the same. Often i just leave and don't return.
People like you think you're so much smarter than everyone else, and mercilessly mock others for not adopting your cavalier atttitude -- right up to the point where you get your identity stolen, or an account hacked and hijacked, then you turn into the Holy Crusader of Security Procedures, preaching on streetcorners about the Dangers of the Internets, and how thieves and hackers are everywhere, BEWARE!!!1!!.
Basically: Shove your 'tinfoil hat' shit up your ass, fuckhead.
... at least put the password requirements on the login page, so that I can remember which password pattern I used to sign up with!
There's research out there that the world is flat as well.
No argument. However, there is research back to the 1970 (can't remember the article) of unix where X% were just one character in length. (no joke). So while the rules 'block' randomly generated passwords that are effective because they don't have a 1 or a ! or whatever, they also block the idiots who don't use a password generator. And how hard is it to just add a '!' to a randomly generated password to make it pass their stupid tests? What Atwood wants is a better verification that a password is randomized rather than just blind rules. (Possible but not an easy task)
Given N characters from a set of C characters, there are C^N combinations. This is polynomial in C but exponential in N, thus you are exponentially better off increasing N than C. I prefer word phrase passwords (nach XKCD) as easy to remember and type. (You can easily meet any stupid special character, number, and capitalization requirements quite naturally in such phrases, eg, "I have 3 idiot sisters!" ) Damn sites that limit you to only eight character or so - they not only prohibit these passwords, but probably store passwords as plain text. .
Having your identity stolen can suck, true. But at the end of the day it's a temporary inconvenience and I don't have to spend my entire life acting like a mouse hiding in a hole with a hawk circling overhead. Life is horrifyingly dangerous, and focusing so much energy on this single risk is just not rational.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
NIST guidelines are not readily available at Indian outsourced IT vendors, nor is it in their interest to waste time reading them.
A simple solution to security questions: don't tell the truth. Or just misunderstand them. My mother's maiden name? "Same as her father's". Fave hero? "Darth Kenobi". First teacher? "Pain". etc etc.
Exactamiundo, and is there any reason not to use the same (nonsensical code) lie for all questions on the same site as i do?
"If dumb people have figured out a way to use a shitty password that meets the 'complexity' requirements... I'm sure you can find a way to create a cryptographically secure password that complies with those same rules."
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 ]
Is this a different Stack Overflow to the one with the most ridiculous password rules in the known universe?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I use 999999999 for all my passwords because it will take an attacker nine hundred and ninety nine million guesses before they get it.
HA! I just wasted some of your bandwidth with a frivolous sig!
Have been around for at least 15 years, and correct the behavior you are referring to. At the DOD we used the John the Ripper dictionary and removed 1,2,3 character passwords. We added company acronyms, system IDs (AH64, M1A2, etc..) as a separate dictionary.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Your password should not be in a commonly used dictionary.
My daughter, after having been hacked by me, multiple times, has come up with nearly unhackable passwords on her devices. The only way you'd crack her iPad is by videotaping her entering it. Something I haven't done yet.
I kid you not, her iPad password is at least 40 characters long. Good luck crackin' that!
My passwords, that matter, are all longer than 15 characters in mnemonics (mostly over 20). They mean something to me, but not to you. I don't do random hard to remember passwords. I do long, easy (for me) to remember mashups of words and word fragments of varying capitalization. Occasionally, I throw a random symbol in at a key location. I even mix languages. I read, write, and speak a dozen languages.
Good luck.
Some sites don't let me use my long hard to crack passwords.
Leave the interpretation of NIST and its relevance to your organization to the Infosec team. Infosec is very aware NIST exists.
If you'd rather not, you can go explain to auditors, customers and executives about your "bullshit" theory.
Realistically, you'll probably just include some mixed case and a number in a password rather than fight this battle, it's much less effort. The news here from an infosec standpoint is that NIST is getting sane about this stuff. No doubt because of the decades of feedback from infosec professionals.
Personally, I disagree with the position on mandatory character classes, but fortunately it's a "SHOULD NOT" and not a "MUST", nor is NIST a rule, it's a guideline. For certain types of passwords and certain types of leaks, mandatory character classes increase the space *required* to break a password. It doesn't matter that 'ahwfovuu' could be randomly generated from upper/lower/symbols/numbers etc, when it could be brute forced with only one character class.
OTOH, I regularly sat on calls and stated flat out to customers that we do not and would not do arbitrary password expiration, regardless of standards. I would highlight it as a point where we're not compliant and would not be compliant. As dumb as it sounds, this statement would appear on reports up to the top.
I'm not looking forward to smart-ass developers raising this as a "counterargument" to why Infosec should bend policies because their favourite password generator tool doesn't support mandatory character classes.
Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!
This is great advice, and considering that passwords must be hashed and salted when stored...
No, that's a terrible idea. Allowing characters outside of what the hashing algorithm will use to be represented by a hash will dramatically increase the possibility of collision. To do what is suggested here would necessitate a complete re-engineering of the way we "store" passwords.
https://xkcd.com/936/
Longer is far more important than complexity.
yes, the password rules are dumb. and useless. And worse, they actually tell anyone who cares to look, what they can leave out of their brute-force searches.
but, without them, you have people who think they are being really clever by making their password "password". or they name it after their cat "garfield" or "morris"
Or the JRR Tolkien fan who things FLADNAG is a good pw cause its got backward masking to protect it
Only post anonymously to /..
Ah ha ha yeah, like we're both truly "Anonymous Coward"s in this day and age.
Only a lizard would suggest turquoise.
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:
I prefer my "obvious" shaken, not stirred.
The only way that password rules enhance password entropy is by forcing the user to supply more entropy. This is the same person who didn't supply enough entropy in the first place, probably someone who really likes A1 sauce.
And now you've got this: habaneroA1!
Sure, a list of the one hundred favourite steak sauces will add six or seven bits of entropy (note: the list won't be uniformly distributed). If you're adding that entropy to a bare word from the English language (rough entropy 13 to 14 bits) you've almost reliably made twenty full bits.
Congratulations! Nelson Mandela can no longer crack your password by hand given 19 years and a heavy rock-hammer slate.
What you really need here is to generate a (conceptual) list of 10^15 strings that best resemble common passwords, and then reject all strings from that list. There are standard methods from information theory to construct such a list given the statistical properties of a large list of previously exposed password strings (requires aptitude). Or you might even be able to train a neural network for this task, using 100% automated pattern inference, and arrive pretty close to the same place.
End result: Joe Sixpack gets rebuffed ten times in a row (he's not willing to do much more to his beloved low-entropy authentication burger than add the ketchup before the lettuce) and then he blows his top, pulls out the sharpest pen he owns, and simultaneously carves his fucking strong password onto a handy strip of paper and the wooden desk underneath it.
Shearing off the low-hanging 10^15 excludes almost every short pattern that half the population regards as even vaguely memorable.
And short patterns are the longest patterns that half the population can type reliably (without a pat on the back halfway through).
The pat on the back system could work. You'd have multiple password inputs providing a mandatory twenty bits each.
Remove six of those bits as a validity congruence (false positives: about 1.5%). You'd need to repeat this four rounds to get 50+ bits of true entropy (4*14=56).
And you'd need to ensure that none of the rounds were simple manipulations of other rounds, or derived from common sequences.
janfebmar / aprmayjun / julaugsep / octnovdec
Here's the problem. By the time the cracker receives two pats on the back for janfebmar / aprmayjun he's probably already onto a shrewd guess about the continuation.
So where you arrive:
There are many people out there where the shortest sequence they can reliably remember with sufficient entropy (which I take as 50 bits) is longer than the longest sequence they can type reliably.
twoshakesofalamb'stail is pretty easy to memorize, but a lot of people couldn't reliably type that b***d better than 10% of the time.
6uldv8!!! is pretty easy to type, but no chance it makes it under the 10^15 bar on any viable model of human psychology. For the sexless, x1k3c3d7 probably doesn't make it under that bar, either (given how well machine translation already works, I think the neural network is onto all of your cheap tricks—up to and including geometric patterns based on common keyboard layouts).
~Oj6ojEb} will make it under the bar and (with practice) is fairly quick to type.
Start memorizing NOW.
Do NOT repeat on any other system.
Prepare to memorize another dozen twisty little passages, all entirely alike in their extreme differentness.
Then multiply by Ultimate IDIOT Winter FAIL.
For bonus marks: take into accoun
People should be required to use a random system generated password and write it down. Better yet a two part password, one they know and one that's generate and they write down. Only way to guarantee password security is to have one part generated. This solves the bad password problem and the reuse problem.
When my passwords get pwned, at least I can change them. When my biometrics get hacked? I'm SOL.
Biometrics should be treat as usernames, not passwords.
I am sad. I am security engineer and I am trying VERY hard to get rid of passwords entirely. I was hoping to see a discussion of alternatives to passwords here but so far, all discussion is about passwords. On topic, but not useful.
So far, the best I can hope for as a password alternative is a Single Sign On solution (that uses passwords) that can be authenticated against with a single password.
Not ideal.
Where are the USB tokens that can read thumbprints and use PKI certificates? Something you are and something you have. Add a PIN in and you get all 3, something you have, something you are, and something you know.
Bullsh*t?
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.
Well how about this -- Assign users their passwords?
So you create an account, and then it says: "OK, your password is: u82r6bz5pe2kxwqqnrbh"
SYMC forces password changes every 90 days with all the 'usual' rigors - Uppercase, lower case, numbers, special characters. On top of that, we deploy 2FA with Symantec VIP.
It's just absurd when to force password changes every 90 days when you have 2FA.
The eternal battle of password complexity hardship vs having 87% of your users' passwords on the latest "most common password" list.
How about taking it out of the hands of users? Find the largest dictionary available in the chosen language of the user, select two or three words from it, randomize which of those start or end with a capital letter, and random selection of a special character in-between them. Complexity attained, difficulty in selecting one gone.
Downsides include how to securely communicate this to a user. If it is shown on a screen it can be over-the-shoulder-checked, if it is sent via email then a hacked email account will supply passwords. Users can usually control the former, in the case of latter the user probably has a whole additional list of problems. But is something that assigns a password of a strength appropriate to the system being accessed better than the two extremes?
Look: some people (celebs) potentially have sophisticated opponents and truly need high security. They know who they are, and should willingly deal with complex passwds. Why impose them on the rest of humanity? People should decide for themselves.
Forcing strong passwds is just laziness and avoiding implemention of other security measures like rate-limiting, IPgeo, lock-out, oh yes, and hashing passwds! Yes, lockout can cause DoS but I'd like the notice and after unlock would have complexity to be able to do without.
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.
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.
Unless part of the password recovery process involves a voice call to the telephone number associated with the account.
Not only does my company enforce BS rules, they force us to change our password every 90 days. So instead of coming up with a reasonably strong password, I use a pretty trivial one and just increment my last number like: dumbpas1, dumbpas2, etc. Totally stupid and a great way for me to get hacked, but I'd be using post-it notes if I had to try and be really creative and learn a complex password every 90 days.
I log into an Oracle system sometimes. One of the rules is no double letter or doubled characters allowed. (hence allowed or any additions to it would NOT be allowed)
So, does not this make the search space smaller by dropping all passwords/phrases with two or three of the same characters in a row?
So this stupid rule actually makes the entropy lower and the search space smaller.
By forcing the user to keep their browser/tab open and entering the code directly on the page
How usable is this flow to inexperienced users, who may not understand tabs? My grandmother sure doesn't, despite my attempts to teach her about them. And how usable is this flow to users of smartphones, whose comparatively small displays don't make the existence of other open tabs obvious?
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...
I do not deploy Linux. Ever.
"No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldnâ(TM)t make them change those passwords unnecessarily."
We make all user passwords expire. Saved our ass last year. One of our admins had written a script with his username/password in it. He'd deleted the script after he used it, but didn't realize an automatic backup had been made. Pen testers found the backup file and tried his password. It didn't work because of our change policy.
What I really hate is when websites disable pasting the password from your password manager into the login field.
How usable is this flow to inexperienced users, who may not understand tabs? My grandmother sure doesn't, despite my attempts to teach her about them.
I understand your concern. If utilizing user session storage, it could (should?) be built to allow the user to navigate away from the page, and then come back to it. In fact, this is how my sites handle it provided the time limit does not run out. Depending on your session implementation and browser, the session may be lost if the browser is closed. Prompting for the code and displaying a countdown timer should caution the user enough to not close the window.
And how usable is this flow to users of smartphones, whose comparatively small displays don't make the existence of other open tabs obvious?
Most, I guess not all, people will not be using their web browser to check their e-mail when on a mobile device. You will still be able to minimize the browser, open your e-mail/sms client, select and copy the code to clipboard, then switch back to the browser to paste the code.
I guess I should clarify that when I say prompt, I don't mean a pop-up prompt box in javascript (that blocks execution, waiting for a response).
I mean simply an input field to put the code into.
8 characters with "rules" may be as good as 12 or 16 characters without "rules".
I don't know why people still go through the pain of storing users' passwords given it has so many problems. Simplest alternative I use is to require users to verify their email address instead of entering a password when they login. Generally a user will have their email open in another tab and they have the link in seconds. Very little effort involved for users or to implement it and you've outsourced the authentication problems to the email provider.
... is when they accept your password, but the password they accepted isn't the password you gave them. This has happened to me several times before.
I created a good strong password from with password manager, and pasted it in once and then again in the confirmation field and submit... It's valid, it's accepted. Great.
I tried to log in the next time and was told it wasn't valid. I chose "forgot password" and set a new different strong password. Same thing again! Why?
One of two reasons, it turns out:
1) When I signed up, the input fields had a maxlength attribute on them. When I pasted the password in, it got truncated by the browser, with no warning at all to fit the maxlength requirement. When I attempted to log in, there was no such restriction and the password (password hash) didn't match. You need to inspect the HTML source to figure it out.
2) They silently truncated the password to some different length before storing (hashing and storing) it but didn't tell me about it.
I can't be the only person that's happened to, surely.
Worse yet are sites which make better passwords difficult by imposing small maximum (yes, said maximum , not minimum) lengths or refuse common punctuation marks as invalid characters. I can't believe that is still being done.
Several rules I absolutely hate for passwords:
* Maximum number of characters (bonus points if it's 8 or less).
* Require a special symbol, but only !@#$%^&* are allowed.
* Can't reuse your last 5 (or some other number > 1) passwords.
* Maximum number of characters plus requiring a number, a lower case, an upper case, and a symbol.
* Last but not least: Websites with maximum number of characters for password that silently discard whatever characters go over the length. And yes, I did encounter this one. At least the limit was 30 characters, so I guess it could have been worse.
The fallacy in your line of reasoning is that there is somehow only a limited set of such rules that anyone could feasibly apply. There is not
Yes, in theory, there are countless ways to apply the rules, thus giving a combinatorial explosion in the search space for hackers
And you are probably one of these precious snowflakes who actually apply these rules as needed.
But in practice, because most of the people are lazy, they tend in general to follow only a handful of patterns.
In the experience of security researcher : when considering a huge treasure trove of passwords, most of them will follow one of the very few ultra popular and ultra simple patterns (like "if asked to use mixed case : simply capitalize the 1st letter. Put the required number at the end [and don't be original, just use the current year]. Put a '!' after the number if required to use punctuation").
To give an example :
let's say you ask people a color and a tool.
in theory you could get tons of esoteric combination, like "tangerine" and "tuning fork".
in practice, when pressed for speed, a huge number of people will pick "red" and "hammer".
For example, let's say I use a rule where a specific sequence of word {...}
Yes, your unicorn of a password might be both secure and follow the rules at the same time.
But in practice the vast majority of people will be lazy and won't produce something original. They'll end up chosing something simple and obvious.
They are bored by the rules and will chose the easiest solution.
and the date that I last changed the password, for example
and that's far from being rare. Guess how many people will pick (parts of) the current date (most of the time they year, in 2 or 4 digits) when required to use digits by the rules ? A lot of them.
You might use a complex word association pattern to ecode it, most of the poeple will just slap it at the end.
but unless someone knows exactly what my thought process is on how I go about this,
Hacker don't target you specifically (usually).
They don't think at the level of individual.
They think on the scale of leaked database.
when they have a collection of a million salted hashes, they won't try to get *your password* specifically. They'll try to get as many password as cheaply possible. And because people are lazy and stupid a very huge fraction of these password will have more or less followed the same though process, and generated a very simple pattern.
So while you're happy that your password was very personal, half a million of other passwords got cracked, because they were trivial (and were modified in a trivial to include the required extra characters) and are currently being tested for password re-use at critical sites (e.g.: banks ?)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Contrary to many common password policies the UK National Cyber Security Centre (https://www.ncsc.gov.uk/articles/problems-forcing-regular-password-expiry) recommends passwords should never expire. Problem with password expiry is that it is not usable, since people having to make new passwords all the time choose weaker passwords.
If you make an attempt every 1.5 seconds, then your first request triggers a lockout for 2 seconds, your second request is dropped without even consideration, and does not reset the period, and 0.5 seconds later the account can be opened up for attempts again. So every two seconds at least *one* guess can get through from someone. Now attacker with resource can stack the deck so that they are almost certainly the ones to consume the guess still, but it's not quite as fatal as resetting the lockout every attempt, even if that attempt occurred during the lockout period.
Now even if it is not timer based, effectively password guesses *should* be an expensive toll on your authenticator (since it should be a one way salted hash with some sort of intentionally intensive delay). So under duress you have to find some way to thwart automation and allow humans to get priority (e.g. captchas, or better ideas).
But instead we have systems that after 3 guesses, lock someone out for an hour. Absolute insanity.
XML is like violence. If it doesn't solve the problem, use more.
i dont know about you guys, but my bank password has a maximum limit of 16 characters.
Any of the penetration tools try simple shit first because people use it ALL THE TIME. They try single letters, they try pw that is the username, they try "password" they try "1234" and so on.
If you are talking ones that try at a system remotely, that is usually all they try, since you can only hit a remote system so fast and you can't just search a keyspace and try and get in feasibly, so it just uses a list of the most common ones to try.
Now when you are talking a situation like when an attacker has compromised something and gotten hashed passwords, you damn bet it tries everything simple. You can hash everything 5 characters or under in a couple seconds. For 8 characters and under you can have a precomputed rainbow table to look them up that is about 500GB.
Go look at L0phtCrack, see how it works, if you want a real world tool.
The hash situation is what you are really defending against so ya, you need some complexity in your passwords. That's also why things like PINs on smart cards don't need to be so complex: You can't recover the PIN (it is stored only in the secure element) and attempts to try it are extremely limited (3 for NIST PIV compliant ones).
Hopefully your bank or whatever allows long passwords like this. (The shortest is 44 characters long.)
These passwords are unique, have lots of characters, and have upper and lower case letters, a digit, and special characters:
this1smyveryverylongpasswordformyBankaccount.
this1smyveryverylongpasswordformyAmericanExpressaccount.
this1smyveryverylongpasswordformyISPaccount.
this1smyveryverylongpasswordformyFacebookaccount.
I've always wanted to see a system that allowed most-anything for a password and selected an expiration date based on the complexity, so "password" gets about 5 minutes, "Denver17" gets about 5 hours and a 32-character generated password gets about 5 years.
They can't or won't remember complex passwords. They frustrate users and IT staff who are forced to deal with the problems they cause. Security professionals get bonuses for this crap. Everyone else pays.
Please do not read this sig. Thank you.
They are for John Podesta
Anthem, the health insurance provider notably hacked a year or two ago, has a typical email/username + flexible password for the online user information stuff, customer service etc. But the billing system that you give your credit card or bank account information to has the classic 3-8 alphanumeric restriction. Scary.
I've had this experience numerous times, several of them with State agencies. The website will let me create a password of sufficient length and complexity when I create an account. When I go to the log on page, the password field only accepts 15 characters (arbitrary example) and I can't even use the password that I was allowed to create. I then have to reset it to a less secure password to fit the field.
Here at NIST, we have bullshit password rules and passwords that have to be changed regularly, so I wouldn't nominate us for that role.
a warning should suffice, wether you do it or not is up to you imo, the responsibility for the servant , i mean serving entity lies with the protectoin of the servers, not the protection of passwords users have to keep in their wallet cos they can't remember them , imo, imo, imo, ... ...
personally for the 99% of accounts i have that dont mean shit i use one and the same password cos it doesnt really matter to me if it gets guess-hacked or not , as for the rest
microsoft just banned my skype / onedrive account for "serious violation of" with a footnote that the agreement i violated says they dont have to tell me what exactly i did.
so password or not
i lost all my contacts across the world and all things stored safely in the cloud
i might as well have used "password" for a passord okay 60% off-topic , im still pissed, i spent a lot of time gathiering contacts , about 1 in 1000 ppl actually talks and half of those not about sex
ah, the agony
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?
After a program I ran at work locked up. I checked the process table to kill it. The process that locked up had my username and password in it. After I noticed how unsecure our passwords were, I decided to just go for one handed speed logins. Why do they make us type in our password every time we run a command if they're going to broadcast it clear text? Within a day, I could have everyone's password. I did a test, but stopped after I learned the name of my co-worker's dog. Don't want to accidently say something in a conversation.
"How's your dog Cody doing?"
Most people don't even bother to change the default password, so it's their username.
For a company that builds fighter jets, you would think they'd be a little smarter with their security.
I'm up to the number 22 at the end of the model of my car. I'm going to need to change it to 23 Monday. Use the same password on my time card. I hope nobody hacks my workorders.
Work in the nuclear power industry... our Microsoft Active Directory passwords are changed every 90 days, and have complexity rules. I just do something like Pas$word1, then 90 days later Pas$word2, etc... so I'm not having to remember a new password. The computers that run the plant systems are on a separate physical network within the confines of the supermax prison-like razor wiring complex that has no connection to the business network. Usernames and passwords on that system are pretty simple without any complexity requirements, easy to guess poorly kept secrets. The catch is you have to make it into the plant without getting shot into Swiss cheese by NATO 5.56 rounds from a classified number of armed security guards to get to said computers.
until someone tells us that two factor authentication is a bad idea, because it'll get used for phishing scams when people think they've been logged out of something. The biggest security hole is between the keyboard and the screen.
This signature has Super Cow Powers
6 char password => expires in 1 hour
8 chars => 1 day
10 chars => 1 week
12 chars => 3 months
14+ chars => 1 year
So making long passwords would make you change only every year.
test: https://password.kaspersky.com...
Atari rules... ermm... ruled.
> Password hashes must be continually upgraded to the strongest hashing algorithms
well, windows still uses unsalted MD4
Atari rules... ermm... ruled.
Uses a list of over 7000 common words.
http://www.diceware.com/
Atari rules... ermm... ruled.