It’s no secret. We’re really bad at passwords. Nevertheless, they aren’t going away any time soon.
With so many websites and online applications requiring us to create accounts and think up passwords in a hurry, it’s no wonder so many of us struggle to follow the advice of so-called password security experts.
At the same time, the computing power available for password cracking just gets bigger and bigger.
OK, so I started with the bad news, but this cloud does have a silver lining.
It doesn’t need to be as hard as we make it and the government is here to help.
That’s right, the United States National Institute for Standards and Technology (NIST) is formulating new guidelines for password policies to be used in the whole of the US government (the public sector).
Why is this important? Because the policies are sensible and a great template for all of us to use within our own organizations and application development programs.
Anyone interested in the draft specification for Special Publication 800-63-3: Digital Authentication Guidelines can review it as it evolves over on Github or in a more accessible form on NIST’s website.
For a more human approach, security researcher Jim Fenton did a presentation earlier this month at the PasswordsCon event in Las Vegas that sums up the changes nicely.
What’s new ?
What are the major differences between current received wisdom about “secure passwords” and what NIST is now recommending?
Some of the recommendations you can probably guess; others may surprise you.
We’ll start with the things you should do.
Favor the user. To begin with, make your password policies user friendly and put the burden on the verifier when possible.
In other words, we need to stop asking users to do things that aren’t actually improving security.
Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause.
Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.)
Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”
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 (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.
We often advise people to use passphrases, so they should be allowed to use all common punctuation characters and any language to improve usability and increase variety.
Check new passwords against a dictionary of known-bad choices. You don’t want to let people use ChangeMe, thisisapassword, yankees, and so on.
More research needs to be done into how to choose and use your “banned list,” but Jim Fenton thinks that 100,000 entries is a good starting point.
The don’ts
Now for all the things you shouldn’t do.
No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”
Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.
No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen.
People set password hints like rhymes with assword when you allow hints. (Really! We have some astonishing examples from Adobe’s 2013 password breach.)
Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”
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’t make them change those passwords unnecessarily.
The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.
There’s more…
NIST also provides some other very worthwhile advice.
All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.
You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.
Password hashing enthusiasts are probably wondering, “What about bcrypt and scrypt?” In our own How to article, we listed both of these as possibilities, but wrote, “We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.” NIST followed the same reasoning.
Additionally, and this is a big change: SMS should no longer be used in two-factor authentication (2FA).
There are many problems with the security of SMS delivery, including malware that can redirect text messages; attacks against the mobile phone network (such as the so-called SS7 hack); and mobile phone number portability.
Phone ports, also known as SIM swaps, are where your mobile provider issues you a new SIM card to replace one that’s been lost, damaged, stolen or that is the wrong size for your new phone.
In many countries it is unfortunately far too easy for criminals to convince a mobile phone store to transfer someone’s phone number to a new SIM and therefore hijacking all their text messages.
What next?
This is just the tip of the iceberg, but certainly some of the most important bits.
Password policies need to evolve as we learn more about how people use and abuse them.
Sadly there have been more than enough breaches for us to see the impacts of certain types of policy, such as the evidence shown above from Adobe’s 2013 hack about the danger of password hints.
NIST’s goal is to get us to protect ourselves reliably without unneeded complexity, because complexity works against security.
What are your thoughts on these changes? Will you implement them for your organization? Tell us in the comments.
LEARN MORE ABOUT PASSWORD MYTHS
(Audio player above not working? Download MP3, listen on Soundcloud or access via iTunes.)
As a user, I’m very happy with these guidelines, but I imagine they will cause a few problems for the providers. For example, a provider is now going to wonder what to do when a user forgets their 64-character password, if they can’t ask them to answer their difficult challenge questions like, “Which is better, cake or pie?” Does NIST have any suggestions when you have a million users and can’t possibly verify them in person when they forget passwords?
This probably warrants an entirely separate post to address. There are many bad practices and few good ones for safely resetting a password. Most often the safest is to use the password reset email approach, but it must be done carefully. If it is for a primary credential the help desk with at least 2 factors to verify your identity should be involved.
Hmm. I feel like that “most often the safest is to use the password reset email approach” vs. SMS needs to be statistically or experientially validated for me. I *feel* like someone’s external email account is far more likely to be compromised than someone’s SMS *at the time*.
You’d think that, but there have been many documented instances of calls/SMS being forwarded to a new number as a result of social engineering (calling telco’s servicedesk and pretending you’re the account holder).
Great summary, Chester. As I was reading it the big question it raised for me was how a service provider should implement account recovery (lost password, etc.) given that KBA should not be used. To me that is a big industry issue that needs a solution, so I’d welcome the separate post idea you mentioned.
No issue at all. Just give people a recover key like: “YRNMD-92832-BSQWP-10348-ORIFJ-12914”, make sure to suggest them to write it down and keep it in a safe box, safe at a bank or similar, and make sure they have it by requesting them to enter the code manually (without copy & paste) in the next screen. Store that on the database using something like “PBKDF2 with Scrypt as its PRF”.
This allows recovery in a secure way… as long the attacker doesn’t have access to where the person has the recovery key.
If the person lost its login credentials and the recovery key make them create a new account. Depending on the service, if the country of the person have it, use the national ID card to sign something digitally to proof their identity… this would allow at least the government to fake the information, but with luck the government can already have access with court order or similar… so government isn’t probably the enemy in most situations… and in the situations it can be, maybe request more things no government can fake easily.
FIDO Alliance products unfortunately are using the elliptic curves from NIST (that came from the spy agency NSA) (P-256 and P-384) and can not be trusted by the people… at least outside United States of America.
My hope to end this password nightmare is the new open protocol (not yet released to the public) called SQRL (Secure Quick Reliable Login) based on Curve25519 elliptic curve, that should be secure, as long their isn’t technology able to break it (it would also break at least NIST P-256).
Just one private key, that the user protects (with no password, some password, just the fingerprint, 3D scanning of the face, blood analyses… whatever is enough for that person). The program generates a different key to every web site, and even to different accounts on the same web site. The recovery/ change of key of access is also included in the protocol to reduce the support calls and the need for backdoors like questions and answer/ sms/ e-mail/ letter to home.
Many bad comments exist on SQRL, but most (not all), have been solved. The great exception is phishing attacks, it is possible, if the user doesn’t check carefully the place where it is logging in. The SQRL is being design to end the use of thousands of username & password, not to address phishing attempts. For that a second factor like FIDO keys would be great (specially if they start supporting just secure elliptic curves like Curve25519, Ed448-Goldilocks or for example E-521).
The author wants to have SQRL work done once it is officially presented to the public, to move on the the projects that give him money (SQRL will not give him money, even if it succeeds).
What’s the difference between putting a recovery code in a safe deposit box and putting your password in a safe deposit box? All the recovery code does is make the account easier to compromise; it’s just a security question with a high entropy answer. Beyond that, I don’t think you’ll find that many people who forgot their password remember their recovery code. Most people don’t have safes or safe deposit boxes. If they have access to the recovery code, it’s because it’s on a post-it on their computer– a security concern of its own.
If we want to start getting nations involved in account recovery– well, I’m not sure how I feel about that. Unfortunately, there’s just no good solution to account recovery, not in my opinion.
This is great and all, but until the companies that make the programs get their act together, these recommendations really don’t make one iota of difference. As long as the only option on my domain controller is “enforce password complexity = yes/no”, with no simple way to change the actual requirements for the passwords, my users will be stuck with Microsoft’s hard coded requirements.
I think you missed one of their points: Use long passwords instead of complexity rules. So, the right answer is to say “no” to that MS yes/no question, but require 16 character passwords. Then, encourage your users to make them phrases or sentences. (You can even get special characters by telling them to include punctuation in their PWs.)
You can change the password complexity requirements other than just turning it on and off. It is enforced through group policy.
If two-factor using SMS is out, what are some other options other than email which is just as bad? I’m not sure a stack of key generators for every bank and brokerage account is going to be the way to go. Seriously, what are organizations moving to in order to meet the needs of two-factor authentication that is convenient as SMS?
Authenticator apps (one app can serve many accounts), for the most part, like the Authenticator in Sophos Free Anti-Virus and Security for Android (link at the end of the article, or search Google Play).
We compared SMSes and Authenticator aps recently, so this is probably a good read:
https://nakedsecurity.sophos.com/2016/08/12/sms-or-authenticator-app-which-is-better-for-two-factor-authentication/
Just waiting for all the security flaws which needs to be fixed in authenticator apps. 2FA SMS is only week if they are sent to the same device as are being used to login with (i.e smartphones). For computers and tablets where the sms are sent to 2’nd device (another phone), I think it beats a “secure” authentication app.
SMS-based 2FA has some handy qualities: you can receive the messages on a dedicated $5 feature-phone; in some parts of the world, especially in the developing world where people live online via SMS because it’s easier to afford than internet access, delivery is almost always instantaneous; rogue messages indicate someone is trying to hack you; and each message stands alone so there is no random number “seed” to steal.
The downside is that in some countries, SMSes are easy to hijack by “porting” someone’s SIM, especially if you have dodgy contacts in a mobile phone shop. (Phone shops can “port” SIMs so that they can give you a new SIM with your old number when you switch providers, or upgrade your phone, as part of customer service. But that’s ripe for abuse, sadly.)
Of course to use this, you need a smartphone. Not everyone has one.
I know. I am not against SMS 2FA myself, for many reasons including that my SMS-receiving feature phone is 5x lighter and has a 10x battery life compared to my smartphone 🙂
(Above I was just answering the OP’s question about what to use instead if SMS is banned.)
We recently touched on slow adoption here. If SMS is banned we’ll still enjoy a nice five-decade grace period.
just hoping that my company stops demanding that i change my password ever few weeks. I think these guide lines are very good.
One way you may be able to convince them (using cost rather than value 🙂 is that unnecessary password resets mean unnecessary calls to IT every time a new password is forgotten, and that costs money.
Yeah, and the place to start is by doing the math comparing 8 character mishmashes against 20 character sentences. If the mishmash uses everything on the keyboard, that’s about 100 characters. 100 to the 8th power is 10 to the 16th. Using JUST lowercase letters is more than a trillion times that effective. JUST with lowercase letters. Capitalize words and add spaces and punctuation and it’s going to be effected for decades.
Of course, 8-character mishmashes don’t even give you 1008 choices if the mishmashes are themselves a side-effect of “forcing” complexity by applying structure to randomness 🙂 If you hsve to have at least one upper, one lower, one digit and one wacky, then an 8-character password that starts
QWBLMcan’t have any more characters from A-Z in the last three places. If your sixth character is, say,w, then the final two can’t be anything in A-Z or a-z: you’ve got only about 100 combinations left (one digit, one wacky) instead of 10,000 (1002).It’s like number plates (tags). In the UK, standard plates are 7 characters, which feels like 367 choices all up. Except that there’s a pattern (XX99XXX), so it’s only 265 x 102 at most. Anyway, the first two letters aren’t uniformly represented, because they depend on the region where the car was first registered, and the regions don’t have equal populations. Also, the letters I and Q are never used, and Z can only show up in the last three characters. And the digit pair is determined by the year of registration, changing every six months from 2001 onwards, so only about 30 out of 100 combinations have so far been used, with older ones becoming decreasingly likely as cars get crashed or scrapped. In other words, the more “combination rules” you have, the more you eat away at the apparent maximum entropy.
GOOD point! I hadn’t thought of that.
20 character “sentences” are not random though, so there’s much less entropy than alphabet_size^char_count.
this is the one discussion point I get stuck on….not having an automatic password reset.
If LinkedIn or MySpace users had to change their passwords every few months, a database of passwords from 2012 would be useless. In these cases (LinkedIn, MySpace), the users didn’t know they had been compromised and thus had no reason to change their passwords.
This scenario easily translates to the workplace – e.g. if a user doesn’t know a colleague shoulder surfed their password, they have no reason to change it. The colleague can sit on the known password for an indefinite time.
That argument makes sense. But my inclination is still to say, “Forced change doesn’t do what you think.”
I think that trying to solve the problem that someone stole my identity in 2012 by forcing me to change my password twice in 2016…well, it seems the wrong way round to me. I’d rather that you put some effort into protecting me proactively, or invested in some sort of 2FA to give me some continuous resilience against a stolen password.
Well FIDO and SQRL are the way to go… FIDO is already available [but I don’t like it because it uses NIST P-256 or NIST P-384 elliptic curves created by the spy agency NSA, and no one independent in the area thinks they are really safe (see SafeCurves web site for example)], SQRL (Secure Quick Reliable Login) is still in development, and may be available in 2017 or 2018 or even later (the author is really taking time to get things correct the first time so that users don’t reject all the idea because something wasn’t made properly initially.
Except enforcing regular password changes mean the vast majority of users simple add a number that increments because that’s easier to remember than creating a strong, secure password. “passw3rd” is easier to surf, and provides only a token amount of extra obscurity than a strong, static password
I agree with a lot of these changes, except the 8 character minimum length. Too wimpy. If you tell people their password only needs to be 8 characters in length, then they won’t abandon the habit of just picking a word/name (or some stylized version of it). In order to make people embrace the concept of picking a phrase or a list of 4 words, for example, you need to increase the minimum length.
We recommend (in the video linked to in the article) “aiming for 14 or even longer”:
https://nakedsecurity.sophos.com/2014/10/01/how-to-pick-a-proper-password/
Thing is, people who “get it” already have passwords longer than 8. Those who have shorter passwords…well, you want to get them on board first, and making them jump from say, 6 to 14 sounds scary. And, as mentioned in the article, 8 is not a maximum minimum 🙂
How about some including some sense on the part of administrators?
I maintain pages on a non-profit server running Drupal. There is absolutely no financial or medical information on the server–at most, a membership list of names, email addresses, and phone numbers. The administrator has chosen (possibly a Drupal default) minimum 8-characters, must include at least one uppercase, one lowercase, one number, and one special, expiration every six months, no re-use (including forgotten passwords) of the buffered last 20 passwords.
Pretty excessive for a server with nothing of value on it. Yet you can be sure the administrator would take the moral high ground if challenged.
There are a couple of reasons why you might want to cut your administrator a bit more slack.
Privilege escalation vulnerabilities are relatively common in the popular CMS platforms and their plugins. If a compromised user account can turn itself into an admin then it can turn the site into a malware delivery platform or spam relay.
Also, if any users are using the same password on your site and another site that stores more critical data then your site is actually a gateway to more sensitive information.
On the other hand some of the things the admin is doing are making things worse for both usability and security.
The password expiration leads users into adopting easy to remember passwords (perhaps with a digit on the end that escalates by 1 twice a year) and the policy – one uppercase, one lowercase, one number, and one special – reduces the number of guesses a password cracker has to make.
If you do challenge the admin, let us know how you get on!
The old “server with nothing of value on it” argument eh? That is a losing argument before it even starts.Bad enough for a desktop, but a SERVER? The bad guys would be rubbing their hands together in glee and wondering where your server is located, since with that attitude they are sure to find an easy lock to pick.
This is interesting, given that it is supposed to apply to all US government agencies, yest starting this month, the Social Security Administration is requiring users of My Social Security to use 2FA with the only option ts to receive a text via cellphone (no cellphone, no access to your account). Here’s the meat of their message:
When you sign in at ssa.gov/myaccount with your username and password, we will ask you to add your text-enabled cell phone number. The purpose of providing your cell phone number is that, each time you log in to your account with your username and password, we will send you a one-time security code you must also enter to log in successfully to your account.
Each time you sign into your account, you will complete two steps:
Step 1: Enter your username and password.
Step 2: Enter the security code we text to your cell phone (cell phone provider’s text message and data rates may apply).
Guess they can’t follow their own rules.
Well, the rules are new…it will be worth watching to see how long it takes to change the system.
If the speed with which the US got rid of magstripe credit cards is anything to go by, you can expect to be using SMSes for many years yet.
It’s already been changed. They gave up on this scheme before it even got started. The problem is was supposed to solve was bad guys creating SS accounts in your name using information they had obtained elsewhere like SS numbers, your name, address, etc. It’s easy to come up with enough info to successfully create an account *** if one does not already exist ***. 2FA did nothing to prevent this because the bad guy could just use his own phone number to authenticate the new account. Once the bad guy has an account he can get your income history, copies of your previous tax returns, change your address, change your bank routing info, file a false return for a giant refund, pick up the money at his bank and be out of town before you even know what happened.
Fortunately they have rescinded this policy. The guidelines I write about above are proposed, not the rule. NIST is asking for public feedback before finalizing these changes. Express your opinions at the NIST website and hopefully departments like the SSA will fall into line once the new guidelines are established.
Very good standard, but 8 min is nothing like good enough. I’m very pleased to see that SMS is out. It has always troubled me that the second factor is a message to the same phone that the login request is being made from! Where’s the 2FA in that?
I use four UK banks/finance houses and all their logins are significantly different, and while they now all have their good points they each have at least one really dumb feature. It really is time for the regulators to set some good standards and enforce them.
Actually, an Authenticator app has exactly the same “no second factor” problem, because 99% of users have the app on the same device as where they receive SMSes…so that’s swings and roundabouts.
In real life, it’s easier IMO to carry around a second phone just for SMSes (with a prepaid SIM for that purpose only) than to carry a second smartphone just for your Authenticator app.
I have a $5 phone weighing 65g with a two week battery life that I use for SMSes, and I carry it everywhere anyway because it’s a fantastic alarm clock, timepiece, emergency phone, and bedside torch when on the road. I don’t leave my iPhone next to my bed because it’s a crappy alarm clock and I might spill water on it 🙂
There are Oath TOTP/HOTP apps for feature phones, too. You don’t need a “smartphone” for your 2FA device. Not to mention the classic 2FA device form factor is the simple keyfobs and there are keyfob form factor devices that support Oath standards too.
I was saying people should not be forced to change their password in deference to password complexity 8 years ago but was met with howls of protest. It is ridiculous to even force complexity when this can be handled by the programming routines but again no one seems to understand this and because people fail to understand this I will continue to be ignored and treated with undeserved suspicion and ridicule. I continue to be amazed by how so many people who think of themselves as educated are ultimately ridiculously conservative. What we need to understand is that much of what we have been taught is often wrong and we need to be just a ready to unlearn so we can move forward more effectively.
You were wrong 8 years ago, and you still are wrong in thinking that people shouldn’t have to change their password regularly.
I my self have access to many passwords created years ago in a web site where I was administrator… if people still use those password after all this years in other services.. you guessed it… I can enter on their accounts, specially if they don’t have a second factor of authentication enabled. And their are thousands of databases being stolen every year… so changing passwords makes sense, even if it is a pain for the users.
Solutions like FIDO and SQRL can end this password problem.
So you administered a website in which you gained users’ trust, then instead of following anything like industry best practices to irreversibly obscure those passwords from yourself and any potential attackers, you abused that trust and stored passwords and emails in a fashion you can easily retrieve? Nice.
And you expect people to trust your recommendations for new security paradigms? That’s ballsy.
I was just an administrator, wasn’t me doing the code of it… I would never allow plain text passwords in a web site made by me… and I have made several of them… in fact I even improved that web site security at the time because there were many ways to bypass the security… but I couldn’t correct the password problem.
The point is, if people use the same password in other places I can enter those services if the login credentials are the same, and they have no 2FA, even after 10 years, because many people will never ever change the password they use.
So demanding people to change their password at least once a year is a good advice for people like me that have legit access to databases that have plain text passwords, and others to not be able to enter their accounts at least after some time, because not all attacks happen immediately so it is still valuable to change the passwords.
Even to this days, it is a bad practice to not cipher the password in some sort of way in the databases… but is not illegal in most country’s around the world.
And lets not forget: users must assume that at the very least the web site administrators have access to the passwords, unless they explicit state that they don’t have it and how they are protecting it. You (the user) are using the web site, you are not supposed to use the same exact credentials on other web sites unless is a system design for that like FIDO U2F or SQRL for example.
I myself even before making my own web sites when I used third party web sites I always used different passwords for everything and changed the passwords regularly… never ever any of my accounts were compromised because of me not being careful with the passwords. Some accounts were attacked but they were server issues and I know that because the company’s later admitted or other users also complaint about attacks on their accounts in the same time frame… but other services where never affected since passwords were unique.
So the password change policy makes sense until something better is used (like FIDO U2F and/ or SQRL for example).
Currently, the major threat for passwords are not offline guessing, but online guessing. Previously, sites tend to place the responsibility of protecting web accounts on users, and let users choose complex and long passwords. Actually, sites shall be responsible for protecting user account by using slow, iterated hash like PBKDF2 and do not leak users’ password file. This is why I think the majority of the NIST advices are wise. Users only need to select passwords that can withstand online guessing. Unfortunately, according to an ACM CCS’16 research, normal users’ passwords are far from secure against targeted online guessing attacks (e.g., as low as 100 guesses).
NIST claims that “Online attacks where the attacker attempts to log in by guessing the password can be readily addressed by throttling the rate of login attempts permitted.” This claim has been invalidated in the ACM CCS’16 paper.
Remember that NIST’s advice about rate limiting online guesses doesn’t stand alone. It must be seen amongst all the other advice, including how passwords are selected in the first place.
Perhaps the word “readily” could be dropped from NIST’s statement above, because it suggests that rate limiting alone is enough, but I’m not sure that the advice you mention is “invalidated” because some users make very poor choices.
I’d be interested to see the paper you refer to – you don’t give the title, and as the conference hasn’t happened yet, I can’t find it.
I am guessing you are one of the authors, or at least have been able to read it ahead of time – if so, has the paper been sent to NIST for consideration? IIRC the NIST guidelines are still a work in progress. Perhaps NIST’s advice about evaluating passwords using a “no go” check before allowing them to be chosen could build on the research?
I too am very interested in this paper — I’ve always thought that basic brute force protection for online attacks (ie, account is locked after N attempts within M minutes) took care of a lot of our password issues. Add some automatic intelligence to that (“Hmm; we’re seeing a lot of N-2 attempts over M minutes…” and “There have been X login attempts since your last login”) and you have a system that helps protect even weak passwords.
I’m sure I’m overlooking something; I would love to see the paper in question to help round out my understanding.
From seeing the abstract, I’m guessing that the authors used a dictionary attack (where you try the most likely passwords from a list in order) but with a *very cunningly-constructed dictionary for each person*. The utterly weird and super-long name you gave to your pet rabbit won’t be in any conventional dictionary. But it might be on your Facebook page! In other words, even with only 100 goes, attackers may be able to guess a password that seems incredibly complex at first sight. It doesn’t have to be in the world’s 100 most likely passwords…it only has to be in *your* 100 most likely choices. (Quick fix? Use a password manager and let it pick passwords randomly.)
You are right at the key point. The cracking results in the CCS’16 paper suggest that if passwords are chosen by users themselves, allowing 100 guesses to attackers seems risky. However, if we reduce the threshold 100 to a smaller one, e.g., 50, the success rates of DoS attacks may significantly increase.
B.t.w, The CCS’16 paper is available at: http://bit.ly/2bmhHnT
Maybe for starters we should just stop calling it a passWORD. We can ask users to set a “pass phrase” instead of a “password”, and give them a subliminal semantic nudge in right direction.
I work for an IT company and we are seeing an increase in targeted attacks using social media info. Companies love to post their ceo and head of accounting on the same page making it easy to research and make a targeted password list or craft phishing emails. We share way too much online and we need to stop.
One problem you’ll be working against here is a “lowest common denominator” one. Because of the historical tendency of computers to reject passwords with too *much* complexity, there is a “lowest common denominator” password-construction pattern that works almost everywhere, while anything that strictly exceeds it is liable to be rejected in a lot of places, and that lowest common denominator is 8 alphanumeric characters plus underscores. Any other character will get rejected somewhere. Any greater (or lesser) length will get rejected somewhere. So you can expect 6 mixed-case letters, a digit, and an underscore most of the times.
Until it’s almost unheard-of for, say, a 47-character passphrase with commas and spaces to be rejected, people will just stick with what they know is least likely to need to be done over again.
And one other thing nobody mentioned is password complexity requirements that are *erroneous*. I had the unpleasant experience recently of trying to sign up for some site that demanded “at least eight characters with one each of an uppercase letter, a lowercase letter, a digit, and a symbol”. I gave it exactly what it asked for: there was one uppercase letter, one digit, an underscore, and five lowercase letters. It rejected it and claimed that it did not meet the criteria of “one each of an uppercase letter, a lowercase letter, a digit, and a symbol”, even though of course it did. I emailed their tech support and they were completely useless, claiming that I must have mis-typed something or the problem was otherwise at my end. Even though I’d actually typed it into a Notepad, then copied and pasted, so I could *see* that there was indeed an uppercase letter, a digit, and a symbol in there. So, the site was applying additional, unstated criteria or in some other manner their instructions were erroneous, or else it was just plain outright broken.
Things like that, plus the burden of having to keep track of passwords, are the major reasons why I hate hate HATE having to sign up anywhere and prefer places I can participate anonymously.
I’d get a password manager app, but for the fact that there’s no way for one to generate a password guaranteed to be accepted at any site until there’s a standard in place! The closest they could come is the same 8 characters from A-Za-z0-9_ mentioned earlier, with at least one of each, and which would *still* be rejected by at least one site.
If anything, we need a standard API for these things. Web site signup and change-password forms should include a snippet of JS that will generate a random password that the site will accept. It would run client-side, of course, and suggest a password to the user. And browsers should include built-in password management that will detect such JS and use it to generate and save a password for the site, and that won’t do nasty things like forget all but the most recent 50 passwords used. (Firefox’s password memory seems to be limited to that.) Encrypted store and option to have to type in a decrypt password each use, of course (Firefox, to my knowledge, lacks that too). Export to encrypted file in some standard format that any other browser can also read (when given the decrypt password). Implement such a standard Web-wide and people will no longer be reusing passwords, writing them down on office cubicle Post-It notes, forgetting them, calling IT because they forgot them, or limiting the number of sites they create accounts at to minimize the amount of credential juggling they must manually perform.
I don’t get the need for “a password guaranteed to be accepted at any site”. Any decent password manager will let you have a different password for every site, and let you configure the length/allowed characters rules differently for each site. I let my password manager deal with it. I start off with “huge random password, all characters”, and back it off for sites that are more restrictive.
I have used 1Password for years. I work at a software company. Only a few people there have taken the time and effort to adopt this technology. If professional engineers are not willing, the typical smartphone user will not be, either. We must put ourselves in the shoes of real people, none of whom are reading this article, and certainly none of whom are commenting.
The value of a server may or may not be the data on it. Usually, it is the access it provides to other networks or to be used for C-n-C of other systems (perhaps millions of drones) used to attack other systems/companies/nations.
Any cracked server is 1 too many, IMHO. We implemented 20+ character passwords in 2010 – the CEO screamed, but didn’t mandate we remove it, because at the same time (within a few weeks, we had cross-platform solutions for SSO and 2FA). He saw progress.
Personally, I’ve been using 40+ character, randomly created passwords for over a decade with a different one for every machine/network that allowed it – not SSO.
The idea that 1 password is enough is ludicrous these days, but there isn’t any reason to memorize 150 passwords either. Get thy a trusted password manager. I only know about 3 passwords. The rest are stored in a password manager. It is set to never auto-fill, since spoofing a website can force those autofill tools to give up your credentials. I have to manually request the autofill every time. Which isn’t much effort. Of course, if the master passphrase for the password manager gets out, the keys to the kingdom are gone. Don’t use a cloud-based password manager folks. Doesn’t matter how reputable those companies may be – they have an interest in marketing their “security claims.” Do you believe what a preowned vehicle salesman says too? Same thing exactly.
> The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.
If password reuse (reusing the same password at multiple websites) was not so commonplace, then I would agree. The problem is when a 3rd party website that you’ve signed up for has been compromised and now your email/username/password is for sale, and you happen to also use the same email/username/password at your bank, in your email, or in your work applications. Do you want to put your security in the hands of another company who may or may not disclose the breach? What if they don’t even know about it?
That being said, there are circumstances when you could justifiably eliminate periodic password changes (e.g., 2FA is required, the login is not exposed to the internet, you don’t reuse passwords).
Forcing password resets periodically is a surefire way to end up with a lot of IT department work handling forgotten password complaints, *and* a lot of passwords like PWDAUG16, PWDSEP16, PWDOCT16 …
I was very enthusiastic until I read the part where they are suggesting sha3 for password KDF. Sha3 should never ever be used for password hashing as it excels in hardware compared to software. I’m surprised there is no mention of bcrypt, scrypt
The issue of bcrypt and scrypt, and why NIST plumped for PBKDF2, is mentioned in the article.
As for hardware acceleration of password cracking…I’d have thought you’d be more worried about SHA-256 (a SHA-2 variant). After all, that’s what Bitcoin uses, and there must be zillions of under-utilised Bitcoin mining rigs lying around these days 🙂
If hardware acceleration worries you, you could go to 100,000 iterations or more. Our current [updated as at June 2016] recommendation is PBKDF2 with HMAC-SHA256 with 20,000 iterations as a minimums
Sophos mentions the use of SHA1,SHA2 and SHA3 for password hashing using PBKDF2. This is not mentioned in the standard at all, they do not specify which hashing primitives are to be used.
Also note that using SHA3 for password hashing is considered worse than SHA1 and SHA2 because of the speed it can achieve.SHA3 was never intended to be used for password hashing and because of its properties should never be used as such.
Is there anything about timing attacks on password comparison functions in there?
Dumb question, I couldn’t actually find anything in the linked to NIST documents that supported this line, can anyone tell me where that is?
“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’t make them change those passwords unnecessarily.
The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.”
Section 5.1.1.2 states “Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.”
https://pages.nist.gov/800-63-3/sp800-63b.html
Does that seem ill-conceived to anyone else? What if the user is using a password on another site and that site gets hacked. Letting the password stay the same for a long period of time increases the chances that a malicious user figures out that the user was using the same password on two sites.
It would be ill-conceived if password reuse was the only thing we had to worry about. The advice is the result of balancing a number of conflicting concerns.
Changing password is a pain! Especially if there is no SSO! I have to change password in 5 different places EACH TIME password expires…..Ouch!
Where does it say that passwords shouldn’t expire?
“6.3. Expiration
CSP’s MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.”
Sadly government documentation can be confusing. I believe the section you reference is talking about authentication tokens like an RSA fob or a YubiKey, not passwords/passphrases. Which page is the above section from?
The section I reference is below:
Section 5.1.1.2 of https://t.co/XbDLkKIMYv states “Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.”
I really have a problem with this one “No more expiration without reason”. Even if you set a 6 month expire time surely that’s better than not setting one at all?
If thieves sit on a stolen password database a few months/years before releasing the details then you could have mitigated some of the damage by regularly changing your password without waiting to be informed by the website admins that you’re password has been compromised (because we all know how good they are at doing that)? And they can only tell you that your account has been compromised if they are aware of it?
I’ve heard this counterargument a lot and I have sympathy with it, but what you are describing is not really “expiry without reason” 🙂 It’s an informed assumption that there *is* a reason.
The problem I’ve got is that most forced expiry policies are more frequent than that, and often predictably regular. So you end up with predictable waves of forgotten passwords (new passwords are hard to remenmber for a bit) and corresponding helpdesk calls, security logs full of failed logons (“muscle memory” takes a while to adjust to the new pattern) that need ignoring, and passwords that are changed predictably with -01, -02, and so on.
Another counterargument is that if you have the same password at your company for too long, the chance that someone untrustworthy will end up shoulder-surfing it in its entirety goes up with time.
At any rate, if you do decide that it’s a good idea for everyone to change their passwords every year or so, regardless of NIST’s advice, try to add a random element into it so that you don’t make things too algorithmic.
I notified my co-workers about this and someone said oh this is just for end users not administrators. Looking at the 800-63-3, it seems like it applies to all memorized secrets whether end user or administrator user. I work in Common Criteria and 15 char are the min which I think is good and mirrors DOD UCAPL admin password requirements. I do think the password complexity should be dropped based on the studies 800-63 are based upon. I would like to get these changes into the PPs/cPPs which are used internationally as baseline security. Also the required hashing and stretching.
Since no-one has mentioned it, What about the Fido U2F system? The little USB keys can be had for as little as $7.
They would be nice… if they weren’t using spy agency NSA created elliptic curves (NIST P-256 and NIST P-384) that no one independent can verify they are really safe. In the SafeCurves web site they even say that this elliptic curves fail in four security related parameters (ECDLP security: “rigid” and ECC security: “ladder”, “complete” and “ind” parameters).
Also those really cheap FIDO keys have some fame of destroying usb ports because of the bad quality of manufacturer.
Should I put Correct Horse Battery Staple on my known bad list?
Unequivocally yes.
Yes.
Yes, some people do use that password — it shows up on some lists of compromised passwords.
emojis??? that’s not standardised across platforms, no better way to never be able to log in again once having changed of devices/OS.
Any suggestions on where to get a dictionary of 100,000 bad password choices?
I’ve been studying Digital Investigations and through much research, I have found that most devices are more vulnerable when they first come out. The security and investigative technology usually has to catch up them. Most hackers know how to expose these vulnerabilities such as weak passwords and security features. There are products that you can use to generate a password that you don’t have to remember. They can also generate a new password for each time you log into an account that will not work but once.
SMS is bad for 2-factor auth for multiple reasons.
1) It usually requires a high-cost device and a “not insignificant” monthly fee to maintain — which further requires a means of paying that bill, with credit cards often required as part of the process, but at least some payment account (both of which require giving out your SSN to a 3rd party — another hack risk). The amount of data one has to give out to support payment for a smartphone should be enough to give a large concern to those highly worried about privacy.
2) I said ‘usually’, since with some free email services, you can also get a free “virtual SMS phone” based anywhere in the US. So no device is _really_ necessary — and how does one prove they got a message — a text message goes to your virtual SMS box, which then gets forwarded to the associated email, which then is forwarded (perhaps indirectly) to your real email address.
In other words — SMS, at *BEST* is only as secure as email, and for people w/o the savvy to navigate getting a virtual SMSbox, it requires many privacy disclosures to 3rd party companies, opening one up to hacking as well as forced disclosure to law enforcement officials who are increasingly corrupted via the self-enriching aspects of asset-forfeiture rules and the easy abundance of illegally obtained “evidence” acquired through spying programs such that “parallel construction” of evidence chains has become common place.
Basically, bogus rules encourage work-arounds which lower security.
So for some of the most critical logins – financial related – banks have to comply with PCI. When will that requirement change??
How does author reconcile conflicting goals of “make your password policies user friendly and put the burden on the verifier when possible” and make passwords longer. Also where does one find references, data, proof points to the claims being made to support the recommendations?
Microsoft really needs to update the settings in GPO for settings such as these. Right now you can only turn on complexity or not, set length, and such. Nothing really to meet these standards.
I love the idea of this, however until Windows AD enables salting, I don’t understand how companies can implement this without a huge change in their core technology (if like many companies they are using AD!) . Or is a good/easy solution I am missing for this?
Ultimately chip & pin has to be implemented. The card readers are very inexpensive & it ought not to be long before the price of a smart card is low enough as well. All this keyboard entry stuff is nibbling around the edges.
Here are my current personal password policies, based on tests using a password cracker (which is how all apps and websites should evaluate password strength) These may change in the future as password cracking methods change.
Use long, random passwords generated by a password manager wherever possible. For passwords that must be remembered, like your Windows password or the password to the password manager, do one of two things:
1. Use a randomly generated 8-character salt value with both characters and digits (e.g. xhg2cq26) followed by a mnemonic for the particular instance like “Aspire” for your laptop password. If you use at least one of these passwords daily, you will quickly memorize the random part of the password.
2. Use the serial number of a piece of equipment or generate a pseudo-serial number consisting of digits and a few letters. Such a password can be hidden in plain sight on your computer (send an email to an appliance parts website inquiring about a turntable coupler for your microwave oven, providing the model and serial numbers.)