NIST Prepares To Ban SMS-Based Two-Factor Authentication (softpedia.com)

An anonymous reader writes: "The U.S. National Institute for Standards and Technology (NIST) has released the latest draft version of the Digital Authentication Guideline that contains language hinting at a future ban of SMS-based Two-Factor Authentication (2FA)," reports Softpedia. The NIST DAG draft argues that SMS-based two-factor authentication is an insecure process because the phone may not always be in possession of the phone number, and because in the case of VoIP connections, SMS messages may be intercepted and not delivered to the phone. The guideline recommends the usage of tokens and software cryptographic authenticators instead. Even biometrics authentication is considered safe, under one condition: "Biometrics SHALL be used with another authentication factor (something you know or something you have)," the guideline's draft reads. The NIST DAG draft reads in part: "If the out of band verification is to be made using a SMS message on a public mobile telephone network, the verifier SHALL verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service. It then sends the SMS message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change. OOB using SMS is deprecated, and will no longer be allowed in future releases of this guidance."

Comments

the phone may not always be in possession phone

[Anonymous Coward]

recursive function overflow

Re:the phone may not always be in possession phone

[goose-incarnated]

Hasn't it been shown that you can take a fingerprint left by someone (say, on their phone) and use it to fool a fingerprint scanner?

It has been shown that this works for old, cheap or crappy fingerprint readers. Modern, state-of-the-art scanners can check for a pulse, or use other techniques to detect tampering. Anyway, the whole point of multi-factor is that each individual factor doesn't have to be perfect. Two layers that are each 90% secure are as good as one layer that is 99% secure.

Biometrics are the worst factor; they reduce the efficacy of the other factors because they can never be changed while there will remain a nonzero number of devices that can be fooled (hence, they reduce the efficacy).

The "modern state-of-the-art" that you refer to doesn't yet exist, but I'm sure that it will be secure when they install it in the future, in my flying car.

I heard you like phones

[Edis Krad]

So I put a phone in your phone because the phone may not always be in possession of the phone

Re:Typo

[gweilo8888]

Do the editors not even read submissions anymore?

You say that like they ever used to.

Non-sequitor

[Todd Knarr]

The recommendation doesn't make sense. Yes, your phone may not always be in your possession. That would rule out software authenticators too, since they reside on the same phone that may not always be in your possession. Even dedicated hardware tokens may not always be in your possession, they can be lost or stolen just like a phone. So if not being always in your possession is the criteria, then all of the NIST's recommended methods fail to meet it.

As for VoIP lines, yes they can be intercepted. They do however share one characteristic with cel-phone lines: they don't normally share a path with the network connection being authenticated except possibly at the user's ISP and computer (if the VoIP line terminates on their computer as opposed to their cel phone). That limits the ability of a single attacker to intercept and alter both paths, which is the central facet of what 2FA does.

Ultimately the only secure 2FA is a dedicated hardware token that requires biometric authentication to function. Anything less than that is insecure, the question being merely whether the insecurity reaches the point of being unacceptable.

Re:Non-sequitor

[Nemyst]

The recommendation doesn't make sense. Yes, your phone may not always be in your possession.

I'd recommend re-reading the actual recommendation: "The NIST DAG draft argues that SMS-based two-factor authentication is an insecure process because the phone may not always be in possession of the phone number". It's not the user having the phone on them, it's the phone having the number associated with it. They're essentially saying that it's too easy to hijack the phone's number (or simply get it when the user changes it) and receive the SMS instead of the legitimate user.

Re:Non-sequitor

[PrimaryConsult]

RSA has software tokens too. The app prompts for a pin and regardless of what you enter, will generate a token code. The catch is, the resulting token code will simply not work if the wrong pin is entered. No way to brute force that, you'd have to take the software token and submit that to the login form to see if the combination was correct (which after 3 tries will still lock you out). Pretty ingenious, the app doesn't need network access and will still work when you change your PIN.

Provide your phone number for extra security?

[Tokolosh]

Many websites ask this - Facebook is top of the list. I fail to see the reason. It is just another part of their project to collect data on you.

Also, security questions are a joke. Where was I born? The whole world knows by now. Why would I provide yet another vector for compromising my account?

If the site insists, I type garbage, and save a copy in Lastpass.

Sheesh.

Re:Provide your phone number for extra security?

[Alan Shutko]

Having password reset happen with a text to your phone is more secure than the typical security questions that websites and (worse) CSRs ask. The text message is intended to help prevent what happened to Mat Honan, where his google account, twitter, and Apple ID were hacked, and his MacBook and phone erased remotely. This happened because a hacker was able to convince help desk folks he was the legitimate owner of the accounts, using info scraped from different places.

Cell phone numbers aren't as good as hardware or software-based authenticators for applications that require more security. It's part of a continuum, where the more security is needed, the more of a hassle it can be to get in.

Re:Provide your phone number for extra security?

[Anne Thwacks]

My bank decided I did a suspicious transaction because I was away, and used a UK (my homeland) website to buy something. They sent a text to my UK phone (running software to reply by SMS saying"my phone is out of order, send me an email") . I did not know about this, so they blocked my card.

I asked if it was possible to advise them to use a different number if I was away. They said NO.

that's not a "ban"

[ooloorie]

NIST can't "ban" the use of SMS for two factor authentication in general. Those are NIST guidelines (of course, some organizations may choose to make those guidelines mandatory). Furthermore, they don't seem to have a problem with SMS verification per se, but as the announcement itself says, they merely want people to verify that the phone number is an actual mobile phone, a reasonable recommendation.

Software Defined Radio

[Orgasmatron]

Part of the cell phone security model was that it was expensive and difficult to build the radio gear necessary to spoof a cell tower. Fast forward to the last few years, and you can get an excellent board for SDR for like $500. The guidelines list steps you can take to reduce the risk of SS7 routing shenanigans, but there isn't much you can do about a highschool kid (or an organized crime outfit) playing MITM with a cheap radio, which is why it will be deprecated soon.

If you are in IT, and your environment demands security compliance, this will reach you eventually. It might take a few years if your structure is slow.

I'm not using secondary device auth anywhere because I believe that dedicated hardware is more secure, but many of my peers are.using this. They will be switching off the SMS option and pressing on with online OOB methods, at least until their next cycle. We suspect that online OOB will go away entirely soon as tablet/phone malware matures and starts emptying phone-2FA-protected bank accounts.