Questions…and buzz surrounding draft NIST Special Publication 800-63-3

Here’s the backstory: You may have noticed that we've been getting a wee bit of attention on the proposed deprecation of SMS as an out-of-band second authentication factor in section 5.1.3.2 of draft NIST Special Publication 800-63-3: Digital Authentication Guideline. First, we're happy to get the attention. Sure, this is a NIST document, but the point of public comment—and our extended public preview of the draft on GitHub—is to make sure the community is a part of creating it. The more eyes the better. The team here at NIST wouldn't quite say many commenters make lighter work—but they sure do make a better end product. All that said, accurately communicating information on technical standards can be pretty difficult, so we want to make sure folks know exactly what we mean with this proposal. Here’s what we mean: There are really two separate changes worth explaining… First: VoIP and other IP-based services. In today’s Identity Ecosystem, we worry especially about threats that are scalable and threats that can occur remotely. Yes, getting your phone stolen is a threat to all mobile-based two-factor authentication, but the cost to an attacker to steal a password and then steal a phone is much higher than when said swindler can access your accounts from their couch. It takes time and physical mobility, and they have to do the damage before the victim can act—which is typically much quicker when your phone is missing than when they're remotely in your account. So while no security approach is perfect, truly tying authentication to a physical device makes a real difference. These days, not all SMS is a mobile phone-based communication. It's a beautiful thing about SMS interoperability that we can send a message to a “phone number” without really caring if it's an SMS, MMS, iMessage, or data message to some other internet service. An SMS sent from a mobile phone might seamlessly switch to an internet message delivered to, say, a Skype or Google Voice phone number. Users shouldn't have to know the difference when they hit send—that’s part of the internet’s magic. But it does matter for security. That's why we're proposing that federal agencies first verify that the phone number is truly attached to mobile phone. If not (and the user happens to protect her or his VoIP account with a password), the user might now be protecting sensitive personal information with two passwords—that's two of one factor type (two of ‘something you know’) rather than actual two factor authentication (‘something you know’ and ‘something you have’). So we felt we had to propose ruling VoIP out. Second: SMS to mobile devices. Let's move on to the case where we’re confident the SMS is really going to a mobile device. We're continually tracking security research on the evolving threat landscape. Following on our approach to limit scalability and remote attacks, security researchers have demonstrated the increasing success (read: lower cost in time and effort and higher success rates) of redirecting or intercepting SMS messages en masse. While a password coupled with SMS has a much higher level of protection relative to passwords alone, it doesn't have the strength of device authentication mechanisms inherent in the other authenticators allowable in NIST draft SP 800-63-3. It's not just the vulnerability of someone stealing your phone, it's about the SMS that's sent to the user being read by a malicious actor without getting her or his grubby paws on your phone. Because of the risks, we are discouraging the use of SMS as an “out of band authenticator” — which is, essentially, a method for delivering a one-time use code for multi-factor authentication. This is why we suggest that the use of SMS as a second factor be reconsidered in future agency authentication systems. But what’s this “deprecated” business all about? Deprecation is standards-speak for “you can use this puppy for now, but it’s on its way out.” It’s a way of balancing the practicalities of today’s implementations with the needs of the future. While SMS is a popular and convenient option today, the security concerns of SMS as a second factor should be part of agencies’ decisions. Leveraging a SMS to mobile as a second factor today is less effective than some other approaches—but more effective than a single factor. This balancing act is difficult and inherently imperfect, which is why we propose changes to the community and seek comment before making guidance final. We proposed a deprecation rather than a removal in hopes of increased efficacy for agencies’ investments in upgrading existing systems and building new ones. It's up to agencies to make the risk-based decisions that best serve their constituents today and future-proof systems for tomorrow. The market is continually innovating in this space; but so are adversaries. We're fortunate to have innovators that have given us many authentication options just as convenient, yet more secure, than SMS. We don’t take these decisions lightly, and we're always looking for better approaches from our stakeholders. If you think deprecating SMS is a step in the right direction, let us know through our public preview on GitHub. If not, we need to hear from you. If you have another idea, it won't come to fruition if you don't share it. In this way we hope to do our part for a better Identity Ecosystem that serves all users and providers of digital services—and these days that covers just about everyone. Speaking of our GitHub public preview site, we wanted to clear up some confusion… We have mentioned before that we hope to receive critical comments to draft 800-63-3 and finalize the document by the end of the year (we expect to close the public preview period by September 17, 2016). This approach has many benefits, one of which is to engage experts early in the drafting process so that we can accelerate release of a final publication. But we’ve heard from many valued stakeholders that think this summer public preview is intended for individuals only—but this is not the case; this document needs organizational input as well (federal agencies: this also goes for you!). To comment as an organization, feel free to create an account representative of your ‘orgname’ or include your organization name in the comment itself. We can even update the issue template to include your organization name if you’d like us to. Don’t let the term ‘public preview’ stop you. Public means open to all. We introduced this new phase to be as responsive as possible as we engage with the public and private sectors. We’d love a steady stream of substantive comments throughout the open period—so please help us keep things running smoothly and efficiently by submitting your comments as soon as possible. Thank you for your comments and for joining us in this quest to make this document the best it can be! Twitter: @NSTICnpo