NIST deprecates SMS as an out-of-band authentication method

Posted by:

root 8 years, 3 months ago

When we started WiKID, we looked at using SMS to deliver one-time passcodes.  We chose not to for the simple reason that there was no way we could control the encryption and thus demonstrate the security of our solution to customers.  There wasn't any data about the possible risks or probabilities of failures (except for reliability/delivery percentages)   We looked to basic security design principles and best practices when we developed WiKID.  Could we control the encryption?  Could we generate the keys on the devices instead of using shared-secrets?  

Since then, there have been attacks against specific user's accounts,  devices capable of intercepting SMS messages being sold to attackers, and SMS privacy concerns about giving firms your cell number (at least where we were concerned).  We've pointed out that SMS relies on the security of the telcos and that they are dis-incented to increase account security.  And the latest: SMS is deprecated by NIST as an OOB solution.

But these are all just anecdotes and not actionable data (as pointed out by Wendy Nather in Dissed by NIST).  There are plenty of examples of attacks against systems protected by two-factor authentication that do not include a cost/benefit analysis.  We cannot find any example of a service that turned off two-factor and I assume they (especially banks) do cost/benefit analysis.

We know that FISMA stated that two-factor would have stopped 52% of attacks against the Federal government.  And every year, the Verizon DBIR points to the use of abused credentials in attacks.  But we don't know if these attacks used user credentials or privileged credentials and we don't know if SMS 2FA would have stopped them (or some impactful percentage).

So, what's an organization to do?   Here are our (biased!) recommendations given the current state of available data:

1.  Implement 2FA for your smaller, technically proficient internal privileged user base first.  In particular, if you are a consumer service protect the database of your users' passwords!  Thwart attackers as they attempt to escalate, not just when they try to infiltrate.  Escalation is a nice choke point and an easily logged, monitored event.  Remember, asking users to use 2FA after you've lost their password database is a form of victim blaming.  Plug: WiKID can do 2FA for Windows and Linux admins.  In this area, PCI-DSS is ahead of NIST.

2.  Remember to avoid setting up identity silos.  Keep your users in your directory where they are supposed to be and use a RADIUS server like NPS to proxy the authentications to a 2FA server.

3.  Any 2FA is better than none, but you should evaluate your choice based on your organization's risk profile, threat analysis, and general preferences (on-premises or cloud, willingness to switch or tendency to stick to a solution, etc). 

A long time ago, we pointed out that banks should be using strong authentication for transactions, not sessions.  Now, we're talking about 2FA for privileged accounts.  Perhaps it's more important where we implement 2FA than what kind. (But still, use WiKID.)

• Tags:
• Two-factor authentication,
• Transaction Authentication,
• pam,
• pci

• ← Praetorian report on Top Attack Vectors points to two-factor auth for remote users and admins
• Users: before you use two-factor authentication, make sure the admins do! →