NIST advice: Don’t use SMS for 2FA

Aug 24, 2016

NIST is soon to release new guidance on password management in the form of Special Publication 800-63-3: Digital Authentication Guidelines. You can, if you so, wish keep up with the evolution of the Draft SP on Github or on NIST’s website.

The Special Publication is all about better ways to protect people’s identities online. What it recommends will be adopted by the US Government Agencies and hence become accepted good practice in the USA; although it will of course take several years for guidelines to be fully-implemented. Even so, what NIST says in this SP (Special Publication) should be of interest to anyone who cares about US standards and will impact on the password policies adopted throughout the private as well as the public sector. The guide is also designed to raise awareness of the changing threats against passwords. Most organisations’ password policies rely primarily on password strength—an organization might require, for example, that passwords be a certain length and include a variety of letters, digits and symbols. This was to protect against brute-force password guessing and cracking. Today’s threats are more likely to be phishing and social engineering that get consumers revealing their passwords, so making a password strong against brute force attack is no longer the only concern.

SMS-based 2FA is NOT here to stay (honestly!)

One of the big changes is that NIST has decided to prohibit SMS-based two-factor authentication or 2FA. So what is wrong with mobile phone SMS?

The most prevalent form of 2FA for years has been a security code sent to your mobile phone. We have been encouraged to opt for 2FA, so it will come as a blow to some organisations – for example, Dropbox, Twitter, LinkedIn … the list goes on, that recommend to customers that they provide a mobile number for SMS codes.

Just to remind ourselves how two factor authentication (aka verification) works, here what LinkedIn say about this ‘Privacy and settings’ feature which you can opt to use:

“If you choose to add this additional layer of security, you'll be asked to provide a cell phone number that will be used to send you verification codes each time you sign in to LinkedIn from a device we don't recognize. Once provided a valid phone number, we'll send a text to that number with the code. If you verify the code successfully, then two-step verification will be turned on.”

On the face of it, SMS-based 2FA seems like a very sensible precaution. If someone does manage to hack your LinkedIn account password, then they need your mobile phone to receive the authentication number – usually five or six digits depending on the service provider - before they can verify the access rights to your online account. Since that phone is in your pocket when the text comes in, the hacker can’t see it, and you know that they are on the point of cracking your account and taking control – at least, that’s how it is meant to work. NIST has found fatal flaws in the approach. 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.

Mobile phone ‘hijacking’ seen as problem for SMS two-factor authentication

In many countries it is 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 including those used for 2FA. A worrying thought indeed if your mobile number is listed on your email signature and business card and you do business in countries where phone vendors ask few questions when it comes to making a buck.

Complicated passwords are inherently ‘no-win’ for the consumer and security

From the user’s perspective, the password puts us all in a no-win situation, where we  either create different, complex 14-20 random character passwords for all of our  accounts – in which case we will not be able to remember them unless we have photographic memories; or we have to store them (which we are continually told not to do for security reasons); – or we have to create only one or a few very simple passwords that are easy to remember (e.g. Honey2010, being the name of your partner and the year that you married them, or Rover2011, the name of the pet dog that your partner bought the year after you married them because you are always working late and they hate being in an empty house) which puts you at much greater risk of having your single stolen or broken password used to take over many of your accounts. The result: identity theft, fraud, and other bad stuff that makes you sweat. 

NIST say ‘Favor the user’ – or, stop making password policies too complicated

The NIST viewpoint is that you should put the burden on the verifier when possible. The problem for most of us has got worse in recent years as mobile devices have small and generally hard to use keyboards, and at the same time, well-meaning CISOs and IT managers have insisted on ever more complex requirements for “password strength” when you sign up to sites and apps, and the introduction of security questions that you have to answer before you can reset your password to something that you have a good chance of remembering, for as long as you need it.

‘No pain, no gain’ argument applied to password policies is found to be False

NIST’s argument is simply: we need to stop asking users to do things that aren’t actually improving security. Complicating life for the user does not make things safer.

So for example, when determining their policies for password length and complexity, organisations should consider maximum and likely actual keyspace. If users will be expected to memorize their passwords, then it may be helpful to set policies that make them easier to remember, such as favouring longer passwords over more complex passwords. However well-meaning the ‘best practices’ were meant to be, NIST has worked out that many of them do not help enough to be worth the pain.

On the other hand, in cases where passwords are stored and your users do not have to remember them at all, then both the length and complexity should be maximized.

With passwords, size matters, although 8 characters is considered to be sufficient as a minimum, if the accounts they protect are sensitive enough, use a higher minimum. Maximum length should be a minimum of 64 characters. Applications must allow all printable ASCII characters, including spaces, and should accept all the UNICODE characters as well, including emoji – so, plenty of scope for the user to be creative. The thinking behind this is sound since passwords must be hashed and salted when stored (which converts them to a fixed-length representation) so there shouldn’t be unnecessary restrictions on length. More research needs to be done into how to choose and use your “banned list,” but 100,000 entries is deemed the starting point.

Don’t make 'rules' requirements for your password policy

NIST says no composition rules when it comes to using particular characters or combinations of the type that you often find on password reset pages just at the point when you are in a hurry to log back in. You know, the ones that say “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_.” And so on. The point being that users should be able to choose a strong password freely and create one that is, at least for them, actually memorable. Hard to remember pass phrases and the use of a few special characters to create the illusion of complexity when hackers are fully aware of these old tricks and have rainbow tables full of them to instantly crack your password is largely a time waster.

Hints to remind users of passwords are out

No more password hints. They make guessing a password a lot easier, as was recently shown by Sophos and described in an article published on their naked security site, Anatomy of a password disaster – Adobe’s giant-sized cryptographic blunder.

KBA is out too. It doesn’t work.

Knowledge-based authentication (KBA) is a process which expects you to “Pick from a list of questions such as: Where did you go to school? What’s your favourite Premier League side? Questions that the organisation will use to verify that you are really their customer and not a fraudster. The trouble is the fraudster can guess that Manchester United is your preferred premier league club, especially if you live in Greater Manchester. (Sorry about that, Manchester City, although if City was indeed the correct answer, the hacker would probably get this on the second valid attempt.).

Long live Old Passwords!

There should be a good reason for changing a password. If we want users to comply and choose long, hard-to-guess passwords, which we then hash and salt for added protection, we should not make them change those passwords to help reassure us that – in the unlikely event that we have been hacked – getting the user to keep changing their password like a game of musical chairs will make for better security. Of course, if passwords are forgotten they should be reset. Likewise, if they have been phished, we expect (force) a change. And yes, if our password database has been stolen and could be subject to a brute force attack that could unlock accounts.   

Routinely hash, salt, & stretch

All passwords must be hashed, salted and stretched. 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; NIST reasons being that PBKDF2 is based on hashing primitives that satisfy many national and international standards.

7Safe’s lead penetration tester and cyber expert, Aleksander (‘Aleks’) Gorkowienko, agrees that it is time to reinvent established ideas about what makes for a strong password:

Making life difficult for users only helps the criminals,” says Aleks. “Password policies that do this encourage users to adopt crack-able passwords or write them down. I am in favour of NIST’s recent guidelines in that they allow more freedom to users to create a strong password that they have a reasonable chance of remembering.”

“Ruling out two-factor authentication using SMS may be a little extreme for some applications. Although SMS redirects and unauthorised phone porting are an issue, for many website users, an SMS text message with a PIN is still an effective safeguard in the event that a hacker gains access to the login and password. However, I can see why for Government websites and secure applications it would not be desirable since a mobile phone SIM can be hijacked much too easily.”

“We should also remember that many passwords and hashes are vulnerable to sniffing, which involves using a wired or wireless sniffer to listen to network traffic. This can include active interception such as a man in the middle attack with the attacker serving as an intermediary through which messages between two systems pass. We should remember that the problem isn’t always the user giving up their password as a result of social engineering attacks. When designing systems, we need to think about encrypting the passwords or communications containing passwords using Transport Layer Security, transmitting cryptographic password hashes instead of plaintext passwords, and using protocols that protect passwords such as Secure Shell (SSH) and HTTP Secure (HTTPS). Network segregation and fully-switched networks to protect passwords transmitted on internal networks help, as does replacing a password implementation that exposes the passwords to sniffing with a more secure password based authentication protocol such as Kerberos. Security by design is what we need to achieve and careful thought when developing the application code can save a great deal of embarrassment at a later stage when the website has gone live.”  

#   #   #


Understanding that ‘humans are not machines’ is the key to designing password policies that really work. Don’t put them through unnecessary stress. Rather, favour the user’s needs over your own desire to create the perfect security system, because their behaviour will send you back to the drawing board when they can’t get it right.

Hash, salt and stretch passwords. Always!

Opt for long passwords over complex ones. Let the user create a memorable phrase.

Importantly: revisit why you have rules in place and determine whether your policies still work in your particular context. Remember: NIST’s advice is based on evidence.

That way, you are not going to make it easy for the hacker by alienating your users.

#   #   #

Looking at changing your organisation’s password policy? 7Safe’s Cyber Security team can show you what really works and the best way to implement it.

Call our advisors on and arrange to meet a 7Safe Consultant: +44 (0)870 600 1667

Are you planning to recruit more cyber skilled candidates? Or perhaps looking to retain more of your existing cyber security team in 2017? You can talk to our expert consultants in complete confidence and find out about the services 7Safe and PA Consulting can offer to help you succeed. We have many more CREST and IISP-accredited training courses in the cyber field than our competitors and a long track record of delivering world-class training for fundamentals, core and specialist needs.

Visit: to learn about 7Safe training.

Want to talk to an expert about training your staff to improve your cyber capabilities?

+44(0)1763 285285

7Safe’s Michael Shuff asks ‘Is SMS two-factor authentication dead, and are we going to be left with complex passwords that we can’t remember?
Password panic
"One of the big changes is that NIST has decided to prohibit SMS-based two-factor authentication or 2FA. So what is wrong with mobile phone SMS?"