In May of this year (2016) NIST published the document "Draft Special Publication 800-63-3: Digital Authentication Guideline". Among the many changes to the digital-authentication guidelines was the long-overdue decision to deprecate short-message service, one-time pads (SMS OTP).
A few eyebrows were raised by this move but to my surprise, rather than embracing the guidelines and pushing for reform, many information security people continued supporting SMS OTP, even if half-heartedly, by noting "it's better than nothing."
When pushed on the question of SMS security, some suggested "use a burner phone number". Others downplayed the risk by arguing SMS-interception attacks are rare and difficult to execute.
I'm disheartened to see the security community failing to take the lead on this opportunity to meaningfully improve security by pushing for better two-factor authentication.
"What's wrong with SMS OTP?"
First let's get on the same sheet of music. SMS OTP is the practice of sending a code, PIN or other one-time-use authentication token to a user's cell phone using the short-message service. The token is entered without transformation as a second authentication factor.
That last part is critical. Neither NIST, nor I, have a beef with SMS OTP that treats the value as a nonce that is transformed into the second factor. The problem is when the value is sent in the clear using public modes of communication and then used without further transformation.
The issue, of course, is that anyone who can monitor SMS communications can get the code. Once that's done, the jig is up.
"The probability of success is low."
First, SMS OTP isn't used just for two-factor authentication. Many sites use SMS OTP for account reset and password recovery. Get access to the user's SMS stream, request a reset code and in you're in. The risk in this case is extremely high.
Secondly, even for two-factor authentication SMS OTP is risky. We know user's reuse account ids and passwords. We also know there are dump sites attackers can mine for credentials. The only thing blocking an attacker from taking control of an account may be a single SMS message.
"Ok, but that's the hard part, right?"
Not really. Attacker's don't have to monitor all SMS communications to get one user's SMS messages. They just need the target user's SMS messages. And that's distressingly easy to accomplish.
First let's take off the tin-foil hats. Let's set aside nation-state actors. Let's also set aside state and local government's and their ability to clone cell phones legally. Let's not talk about SS7 or GSM eavesdropping. We won't even discuss phone hijacking.
Let's talk about plain old social engineering. Let's talk about stealing every account a user has by convincing their cell-phone service provider to move their phone number to another phone.
That's the problem with simple SMS OTP. Had the user in the story been using Google Authenticator or one-tap authentication in Google Search, his YouTube account would not have been compromised. Had Twitter, Instagram and all his other social-media sites been using real two-factor authentication, he wouldn't have lost years of work. 
I'm not blaming boogie2988. I'm restating his own conclusions. He did everything right according to received wisdom. He did what the sites suggested. No, boogie2988 is not to blame.
Supporting SMS OTP 2FA is Irresponsible
This is why I have said and will continue to say:
#InfoSec saying SMS #2FA is "better than nothing" is irresponsible. It's false security. The attacks are real.
Not only is SMS OTP not "better than nothing". It's actually worse than nothing. It gives users a false sense of security. (Theater, anyone?) And supporting its continued use or downplaying the risks provides cover for companies who won't do better.
Before the wide-spread availability of password dumps, two-factor authentication for public sites seemed like over kill. Google Authenticator seemed a bit esoteric even for many InfoSec people. At some point it ceased to be odd.
I don't think anyone in InfoSec really liked SMS OTP for two-factor authentication. But the need was real and it was easy to implement and use. It made sense to tolerate if not support it. But we knew it wasn't secure.
Today, however, in light of what we know, in light of the draft NIST guidelines, continuing to support SMS OTP is irresponsible. It's bad practice that puts users and companies at risk of compromise.
If we in InfoSec continue to do so we will continue to fail users like boogie2988. And we'll compromise our own integrity and authority.
What's the Answer, then?
This is the best part. The technology already exists.
As much as we in the security community might want true "something you have" two-factor authentication, the reality is cell phones are ubiquitous and user prefer them. The solution, then, isn't to abolish the use of cell phones and the convenience they provide. The solution is to use them more intelligently, more securely.
There's are several options. And they're about as easy to implement as SMS OTP.
Google led the way with the introduction of Google Authenticator (HOTP/TOTP). Yes, Google Authenticator is annoying, but it works. But it's not our only option. Google, Apple and others are working on more convenient solutions.
Recall that the problem with SMS OTP is that the second factor itself is sent in the clear without transformation. The obvious answer is to quit sending the second factor in the clear and to start using SMS or mobile data to create a challenge-response system.
That's what Apple and Google have implemented. They're challenge-response systems with easy-to-use UIs. When a user logs into a new device, a challenge message (that can be authenticated) is sent to to an app on a trusted device (or devices) of the user's choosing. The user then approves or disapproves the request for the new device in the app.
One of the strengths of this solution is that almost all the services that matter have cell phone apps and the others can add them. What could be easier than adding secure, authenticated messages to an existing app and asking the user to approve a login from a new device or browser?   It's a win for users and the sites that serve them.
It's also a win for the InfoSec community. We wouldn't be arguing against the convenience of cell phones. We'd be arguing for real, secure use. And that's good practice.
 Some might say, "boogie2988 and the others are a handful of cases." I might remind everyone that Mat Honan's "Epic Hacking" was the case that woke the community up. I would further remind everyone that nothing in boogie2988's story is implausible. Every detail is right out of the playbook.
 boogie2988's PayPal account was also compromised but PayPal locked the account pretty quickly. I imagine their fraud-detection systems noticed the unusual spending pattern. Perhaps high-value sites like Twitter and YouTube could implement fraud-detection-like systems that detect unusual patterns of behavior and freeze the user's account for a period of time.
Of course regaining control of one's account assumes some way of authenticating one's identity. Companies like PayPal have an advantage in this regard in that they often have harder-to-obtain details like full credit-card numbers and credit history.
 The irony in boogie2988's story is that it was the attacker who took over his account who explained the problem with SMS OTP to him.
 I'm not here making an argument that it rises to the legal standard of malpractice, but one could argue that it's minimally negligence. In cases where one recommends SMS OTP knowing it's not secure (or sufficiently secure) the case for malpractice (or its equivalent in the field of InfoSec) could be very strong.
 Mozilla Firefox had a similar system based on pairing devices. Because of the problem of device availability, or lack thereof, they dropped it in favor of a pure login-id and password system. I understand their concern but think they through the baby out with the bath water.
 Yes, there's a chicken-and-egg issue here. How does one verify the first device? The first answer must be, that initial identity verification is beyond the scope of a two-factor authentication discussion. But assuming we're not concerned with legally-binding identification, there are several options. One option would be to present a code, perhaps a QR code, on the website the user could enter in the app at sign-up.
 Though I will personally be bitterly frustrated if I have to install a dozen new apps on my phone to handle two-factor authentication. I'll keep my Google Authenticator, if you please.
 And, "No", this won't mitigate physical-theft risks. But those risks always exists when the second factor is a "something you have" factor. Also, let's not forget that most modern phones have fingerprint readers and that apps can require a fingerprint before unlocking.
 One can also imagine Apple and Google adding APIs to support such features. Or companies that currently implement federated OAuth authentication providing second-factor authentication apps to their offerings.