NIST Rules on Two-Factor Authentication & Influencing Banks

One of the best things about being retired is having the time to talk to companies on the phone. When I was working, I would simply let things go that were irritating me because there just wasn’t the time.

This week my mission became talking to every bank I deal with about their security model. For reasons that are irrelevant to the discussion, (and highly annoying to me) I’m associated with four different financial institutions, and each of them got some messaging from me this week.

Their current service varied from two of them having no two-factor authentication, and two having SMS, email and phone call verification. None of them use a software authenticator method like Google Authenticator or the one built into 1Password.

Before I spoke to them, I decided it would sound a bit weak to say, “My friend Bart is real smart on this stuff and HE says…” So I started to do my research. I wanted to make sure I had a crisp explanation of why using SMS is a bad idea for two-factor authentication.

At first I found articles on lots of sites talking about the problems with SMS. I also remembered that the problem is so publicly known that 60 Minutes actually had an article where they had a hacker break into a Senator’s phone while they were taping the show. But that didn’t seem like the right kind of evidence to hold their feet to the fire.

I found an article at the Register from around a year ago about the problems with SMS and followed links in there to the best source possible.

That source is NIST, the National Institute of Standards and Technology. NIST doesn’t create any governing laws but is responsible for setting the standards for all technical industries. Still the right resource and important to know how they impact the institutions with whom we deal.

From the Register I was able to find NIST Special Publication 800-63B at pages.nist.gov/800-63-3/sp800-63b.html. 800-63b is the Digital Identity Guidelines for Authentication and Lifecycle Management. Rolls right off the tongue, doesn’t it?

While I’m sure it would be riveting for me to read the entire 69-page document to you, let’s dig into just the pieces that are relevant to our two-factor authentication questions. We need to start by defining a couple of terms.

I’ve been calling this topic two-factor authentication, but in the guidelines they’re more generic and refer to this as Out-of-Band Authenticators.

The initial NIST guideline went up for public review last year, and it included statements indicating that SMS as an Out-of-Band Authenticator was deprecated but in the finalized document, it has been modified and is now called SMS restricted. We’ll get into what restricted means a bit later, but listen for that word.

Another term is PSTN, which stands for the public switched telephone network. PSTN is the aggregate of the world’s telephone networks, including analog landlines, voice over IP (VOIP), fiber optic cables, microwave transmission links, cellular links, satellites, and undersea cables. So pretty much every way on earth that you can talk to each other across the globe is connected and switched and is called the PSTN. (For more read: Public switched telephone network – Wikipedia)

And finally, the document uses the term CSP. I had to go to another NIST document to find out that it stands for Cyber Security Practitioner. That’s the poor joker who’s going to get blamed when the company doesn’t properly fund its security organization.

Ok, I think we’ve got enough terms defined. Let’s look at just some excerpts from each section that applies to two-factor authentication, aka Out-of-Band Authenticators.

5.1.3.1 Out-of-Band Authenticators

The out-of-band device SHOULD be uniquely addressable and communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). For additional authenticator requirements specific to the PSTN, see Section 5.1.3.3.

So it shall be encrypted, unless it’s sent over the phone network. Looks like we’re going to have to read some more over in section 5.1.3.3. But before we leave Section 5.1.3.1, it goes on to say:

Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.

So we know that it’s inadvisable to use email or a phone call to a VOIP phone to get your authentication.

Let’s move on:

Section 5.1.3.3 Authentication using the Public Switched Telephone Network

Use of the PSTN for out-of-band verification is RESTRICTED as described in this section and in Section 5.2.10.

There’s that word restricted we were looking for. Let’s learn about the restrictions:

If out-of-band verification is to be made using the PSTN, the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device.

Now we used to believe that you having your cell phone in your possession did mean a call to that number was associated with a physical device. But we’ve learned that it’s just not true. Section 5.1.3.3 elaborates:

Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.

Note that it doesn’t say the authenticator can’t use the PSTN anyway, even after considering the risks of using it.

Let’s keep going though. We’ve still got 5.2.10 about restrictions on authentication using the PSTN to look at. I’d like to pull out a couple of interesting sentences in here.

The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used.

At first read, that simply says, IT Security should be allowed to do their job. Assess the risk, and come up with mitigations. Then be prepared for the probability that the risk will become unacceptable, and if so, to stop using this method. Reasonable advice. But NIST puts some more teeth into the statement:

Furthermore, the risk of an authentication error is typically borne by multiple parties, including the implementing organization, organizations that rely on the authentication decision, and the subscriber.

I like where they’re going here, sounds like fodder for a future lawsuit, doesn’t it? It gets even stronger:

Because the subscriber may be exposed to additional risk when an organization accepts a RESTRICTED authenticator and that the subscriber may have a limited understanding of and ability to control that risk, the CSP SHALL:

1. Offer subscribers at least one alternate authenticator that is not RESTRICTED and can be used to authenticate at the required AAL. [Authenticator Assurance Levels]

2. Provide meaningful notice to subscribers regarding the security risks of the RESTRICTED authenticator and availability of alternative(s) that are not RESTRICTED.

3. Address any additional risk to subscribers in its risk assessment.

4. Develop a migration plan for the possibility that the RESTRICTED authenticator is no longer acceptable at some point in the future and include this migration plan in its digital identity acceptance statement.

Let’s summarize here. We learned that SMS messages to your cell phone, which are over the PSTN, are restricted. We learned that a voice call to a VOIP phone is also part of the PSTN and therefore restricted. We also learned that using email is restricted.

But point 1 of the section I just read says that they shall offer you one authenticator that is not restricted.

Bottom line, after reading all of this, NIST Special Publication 800-63B says that they darn well better give you a software authenticator method like Google Authenticator!

Time to call the banks:

• First bank I didn’t know anyone, so I used online chat to ask for a contact to talk to about IT security and two-factor authentication. Kaitlin told me she’d forward it and I’d get a call in 1-3 days. We’ll see about that.
• Second bank had a form I could fill out so I gave a brief description and said I wanted to talk to someone. I tweeted them too. They tweeted back that they did SO have 2FA, but I said, “huh, uh, do not!” They responded with, “We apologize for the confusion. We require multi-factor authentication when logging in with a new device, new browser, or if a password has changed. We have shared your feedback to help improve our products and services moving forward”. I suggested they contact me directly about this, we’ll see how they do.
• The third institution was more interesting, because I tortured them on this very thing a year ago. I dug around online until I found the corporate leaders page, found the name of the CIO, then called the institution and asked to talk to her. They told me they’d have her call me and she actually did. We talked quite a bit and she emailed me some stuff that showed that they were going to be implementing out-of-band authentication. But guess what? It’s been a year and they haven’t done it yet, not even cruddy SMS! So she got yet another email from me
• The last one was more satisfying. They have two-factor authentication, but it’s either SMS, email or a phone call. I was able to get on a call with the project manager in IT security, along with his boss. They said it was on their roadmap for 2018. I wasn’t thrilled with that answer, so I kept chatting with them.The project manager said something really interesting when we were talking about NIST. He was super knowledgeable about it so that was fun. He was the one who taught me that it’s a guideline to financial institutions, but part of federal regulations for the government. But then he pointed out that there are laws in Europe that require better authentication, so they comply with them there! I was a bit rough on them then – pointing out that they could do this for us but only do it when the government makes them!

  I asked the boss what barriers were in the way of helping the project manager be successful. As I got her to dig into that, I discovered that my phone call (along with my depth of knowledge) was actually going to help her provide urgency to the project. It became evident that they both wanted this up higher on the priority list. She asked to quote me and I, of course, said to quote away! I’m hopeful but I’m not delusional that it will happen in a month or anything like that. But when it does, I’m totally taking credit.

I did find a cool site while I was working on all of this It’s twofactorauth.org. It’s a list of websites and whether or not they support 2FA. You can search for a site, or peruse by category, like banking, backup and sync, government, IoT, and more. It’s cool because they have columns for what type of 2FA each organization supports, including SMS, phone, email, hardware token, and software token. They even have buttons to help you tweet or Facebook the companies if they don’t support two-factor authentication.

I looked at the banking section and sure enough, pretty much the only ones with hardware or software tokens were in Europe.

Like I said, one of the great joys of retirement is having time to do stuff like this. I hope maybe I’ve inspired you to torture your banks and any other institutions that hold something precious to you.