Issues with SMS Deprecation rationale

[cmccolgan]

Organization: TeleSign Corporation

Type: 2

Document (63-3, 63A, 63B, or 63C): 63B

Reference (Include section and paragraph number): 5.1.3.2

Comment (Include rationale for comment): In analyzing the declaration in 800-63B 5.1.3.2 of “OOB using SMS is deprecated, and may no longer be allowed in future release of this guidance” TeleSign reviewed https://github.com/usnistgov/800-63-3/issues/19 and https://github.com/usnistgov/800-63-3/issues/78. We also reviewed the NIST blog entry discussing the proposed deprecation of SMS at https://nstic.blogs.govdelivery.com/2016/07/29/questionsand-buzz-surrounding-draft-nist-special-publication-800-63-3/. In this blog, the comment that “SMS messages” are being intercepted “en masse” is given as a primary driver behind the decision to deprecate. Following a thorough analysis of this and other cited drivers for deprecation, we conclude the guidance to deprecate should be removed.

In issues 19 and 78 a good sampling of the exploits against SMS are made. Per the categorization below almost all of these exploits aren’t against SMS inherently but are either Man in the Browser (MITB) attacks, Man in the Middle (MITM) attacks or Social Engineering attacks. While it is possible for Nation States or hackers with special SS7 access to engineer ways to intercept SMS, these types of attacks are extremely difficult to do in some countries (such as the US) and only possible by Nation States in other countries. If the deprecation of SMS is due to the desire to make Nation State attacks a less prevalent threat for second factors of authentication, then the guidance should be altered to only allow second factor authentication on Single or Multi factor Cryptographic devices and software solutions on smartphones should be deprecated. Smartphones broadly are at risk of MITB or MITM attacks. The threats detailed in issues 19 and 78 apply to SMS OTP, but it is clear that these types of attacks can be leveraged against smartphone apps in general. SMS has become a target because it is the most prevalent form of consumer 2FA and has a high attack profile and as such the literature focuses on these attacks.

Hacks detailed:

Article	Threat Type
Radhesh Krishnan Konoth, Victor van der Veen and Herbert Bos. How Anywhere Computing Just Killed Your Phone-Based Two-Factor Authentication. Twentieth International Conference on Financial Cryptography and Data Security, February 2016. http://fc16.ifca.ai/preproceedings/24_Konoth.pdf	MITB
Collin Mulliner, Ravishankar Borgaonkar, Patrick Stewin, and Jean-Pierre Seifert. SMS-Based One-Time Passwords: Attacks and Defense DIMVA 2013, 19 July 2013. (also slides) https://www.mulliner.org/collin/publications/mulliner_dimva2013.pdf	MITB. (Trojan in article) Suggested solution to this with Mobile OS changes. Also lists various threats to OTP via SMS
"Warning: Why Most Two-factor Authentication Solutions are Unsafe" https://www.linkedin.com/pulse/why-most-two-factor-authentication-solutions-unsafe-falk-goossens	Starts with MITM, then talks about MITB. SIM Swap via Social Engineering.
"Aspect Warns Banks of SMS OTP Vulnerability" http://mobilemarketingmagazine.com/97087-2/	Social Engineering. (SIM Swap)
"'Eurograbber' SMS attack shows Android's vulnerability" http://www.techworld.com/blog/war-on-error/eurograbber-sms-attack-shows-androids-vulnerability-3537952/	MITB via Phishing. Malware on mobile.
"Telcos declare SMS 'unsafe' for bank transactions" http://www.itnews.com.au/news/telcos-declare-sms-unsafe-for-bank-transactions-322194	Social Engineering (SIM Swap)
https://twitter.com/kingladar/status/723224164199358465	Social Engineering
SpyEye Changes Phone Numbers to Hijack Out-of-Band SMS Security ttps://securityintelligence.com/spyeye-changes-phone-numbers-to-hijack-out-of-band-sms-security/	MITB + Social Engineering
https://www.ftc.gov/news-events/blogs/techftc/2016/06/your-mobile-phone-account-could-be-hijacked-identity-thief	Social Engineering , Identity Theft
http://www.cellusys.com/2015/10/20/8-ss7-vulnerabilities-you-need-to-know-about/	Hacks in this guide are theoretical as production SS7 networks are highly filtered.
https://www.wired.com/2016/08/hack-brief-hackers-breach-ultra-secure-messaging-app-telegram-iran/	Social Engineering (SIM Swap)
The cell phone account of the FTC Chief Technologist was hijacked by an impostor using a fake ID. Although the motivation of the attacker was apparently to purchase and resell the phones, it was noted that this could also be used by an attacker attempting to bypass two-factor authentication. The report of the attack also pointed to a New York State website warning against what is called a "SIM swap" scam to defeat OOB SMS	Social Engineering (Identify Theft)
Black Lives Matter activist DeRay McKesson had his mobile account hijacked and used to take over his Twitter account, which had two-factor authentication enabled.	Social Engineering

In recent disclosures around the zero day Trident-Pegasus attacks (https://citizenlab.org/2016/08/million-dollar-dissident-iphone-zero-day-nso-group-uae/ and https://blog.lookout.com/blog/2016/08/25/trident-pegasus/) it has become very clear that nation states have a rich library of exploits in mobile devices due to secretly known zero days. NIST guidance around use or not of SMS and smartphone second factor authenticators should take this into account. Other technologies that may sit on a smartphone that aren’t SMS like Single or Multi-factor cryptographic software are also subject to MITM or MITB attacks when the endpoint that the cryptographic software is running on has been exploited such that arbitrary root CA certs can be injected onto devices and devices settings can be wholly compromised.

_Conclusions on NIST’s suggested deprecation of SMS_

1. While SMS OTP vulnerabilities exist, we believe they are difficult to achieve “en masse”. The threat types cited in the documentation apply broadly against all smartphone based security methods in NIST guidance and given this, SMS alone should not be singled out for deprecation.
2. Security experts agree, SMS 2FA remains the most viable additional layer of account security for _the average consumer_ today due to the ubiquity and convenience of the mobile phone. Having 2FA enabled to protect online accounts is significantly more secure than relying on a username and password alone. We urge NIST to clarify and make distinct how their recommendation does/does not affect the average consumer. Failure to do so willingly perpetuates a perception that “2FA is banned” and other conclusions which are not only false, but also do a disservice to the consumer.

Suggested Change: In 5.1.3.2 Remove deprecation of SMS OOB.

[wpwoodjr]

I agree. The suggested deprecation of SMS is creating big headlines, causing organizations to doubt possibly the simplest, most easy to use method to protect and verify identities. Anyone who has "required" users to sign in with 2FA knows how difficult it is to get users on-board with it. From our experience, secret questions are even worse, especially when used across different languages and cultures, and secret questions should be deprecated. However SMS is widely available around the world, and people already know how to use it. The proposal to deprecate it seems misguided at this stage of the evolution of user acceptance of the need for 2FA, and the notion that deprecating SMS doesn't prevent it's use, or is only for government, is a bit rich coming from NIST, widely known for setting standards that affect us all, and perhaps more influential than it knows?

• Bill Wood, GlaxoSmithKline

[jaxley]

Ultimately, the right approach for the "average user" is dependent on the particular threat models of the application in question.

The articles and discussion above seem to ignore the most obvious and seemingly common attack vector: The telecoms.

See https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/ or https://krebsonsecurity.com/2016/09/the-limits-of-sms-for-2-factor-authentication/ for a summary of some recent example attacks. Many are social engineering or bypassing the terrible call center "authentication" of customers to hijack the user's entire mobile account. And they are quite effective.

However, another attack vector I don't see represented but has been known for a long time is just web MiTM via a fake phishing site. This actually happens so any mechanism (including TOTP and SMS) relying on a user entering data in a supposedly trustworthy site is

So, these real threats have to be considered and weighed against the risk. It would be disingenuous to ignore them because they aren't against "SMS inherently". The "average user" you talk about is prone to fall for phishing attacks. I see it often. Security is often about the weakest link and if you ignore the weak links surrounding SMS in devising your security controls, you're ignoring real risks. Attackers don't need to target SMS necessarily if they can social engineer or just put up a phishing site -- end users will happily give their SMS tokens to the attacker!

Would be nice if there was a software-based U2F option in browsers to cryptographically secure credentials for specific sites. We need better protocols to keep users safe even in the face of a MiTM.

Push-based solutions are another option to consider.

[wpwoodjr]

Users can be hoodwinked into providing an MFA token code to a third party, but its not particular to SMS. A device-generated code like Google Authenticator has the same vulnerability, whether its by social engineering or MITM. And "swipe to authenticate" is possibly even worse, as users may swipe through the prompt just to get it off the screen. No system is perfect.

[jimfenton]

We are not ignoring "phishing" attacks, which we are more generally referring to as verifier impersonation attacks. These are discussed in -63B section 5.2.5. Verifier impersonation resistance is required at AAL 3.

[tonyboo]

The fundamental issue with the identity issue at wireless providers is one of identity proofing. Wireless providers have to make the on boarding process easy for potential customers, and to compound the matter, sales reps are compensated for adding customers, and not for assuring identity. Thus, the identity proofing process is kept to a minimum, and so is open to spoofing. Entities that rely on mobile phone security measures (push notifications and SMS) end up depending on the weak identity proofing mobile carriers perform. Because of the misalignment of incentives, this situation is unlikely to resolve anytime soon.

However, SMS has the additional vulnerability of SS7 spoofing, without the need to transfer the phone account. In addition, SMS doesn't require a password once the phone is transferred, while push notification apps at least require the attacker to have an additional password (e.g. iTunes password) before notifications can be delivered to the new phone. In practice, of course, this can be phished, but at least it's one more hurdle to overcome for the attacker.

So the deprecation of SMS OTP is understandable, as it is more vulnerable.

[readnotify]

It costs about $10 to buy an SDR off eBay, and the open-source software to sniff SMS messages is free, and the security is sufficiently weak that SMS can be decrypted in near-real-time on a modern laptop.

Provider number porting is a huge and growing problem, successfully draining $millions in cash from countless victims.

Links: http://www.rtl-sdr.com/receiving-decoding-decrypting-gsm-signals-rtl-sdr/

The advice to deprecate SMS is absolutely sound.

Here is the acid test: would TeleSign be happy to refund all customers for all monies lost through SMS vulnerabilities?

[wpwoodjr]

@readnotify your victim must be specifically targeted and in physical proximity for that attack to work.

There are many use cases where SMS is "good enough" and certainly better than no MFA. Let's give SMS a low assurance, not deprecate it.

[mschleiff]

I agree with the approach of not deprecating SMS, and giving it a low assurance rating. passwords alone aren't very secure, and the approach is not to deprecate passwords, but to give passwords a low assurance score. I don't understand all the vulnerabilities of SMS; but theoretically speaking, if future technical advancements someday improve the security of SMS I would rather just adjust the SMS assurance rating instead of un-deprecating SMS.

[tonyboo]

@WPWoodJr The trouble is that SMS (in combination with passwords) is used today for use cases where a higher level of security is required, and no-MFA for less intense use cases. Therefore, if SMS is weakened and is now as you propose appropriate for such less intense use cases, then it adds no value over no-MFA. Why would anyone use SMS OTP in that case, if it offers the same security at lowered convenience? Therefore, the rationale for depreciation is sound.

[wpwoodjr]

@tonyboo but SMS does offer more security than password alone. For instance if my gmail password is phished, without my phone the attacker can't get into my account, unless they target me with one of the attacks mentioned above, which isn't very likely.

[mschleiff]

@tonyboo - I don't necessarily consider SMS to be less convenient than passwords. To log into GitHub to respond, I had to open my password wallet to find my GitHub password (I don't use GitHub very often). For me that's no less convenient than keying in a value received via SMS.

[tonyboo]

@mschleiff I wish all users were like you - the unfortunate reality is that the vast majority of users don't use password wallets, preferring instead to memorize their (admittedly weak) passwords, and thus would view SMS as a higher friction authentication mechanism. Therefore, if SMS OTP offers a similar level of security as passwords at less convenience, it is not of much practical value, and hence the deprecation rationale is valid.

[wpwoodjr]

@tonyboo why do you assert that "SMS OTP offers the same level of security as passwords"?

[tonyboo]

@WPWoodJr Updated my original comment to use 'similar' - your point is well taken.

There is accumulating evidence that SMS is insecure and that phones can be ported over relatively easily. Therefore, it is not a very secure mechanism.

The argument that these vulnerabilities have not been demonstrated on a mass basis is irrelevant - an attacker needs to breach just one account to enter, and then can then leverage that account to gain administrative privileges for further subsequent damage.Please see the details of published breaches for how that process proceeds.

Thus for most real-world applications, SMS OTP is no longer a viable mechanism for protection of the network as a whole, which is clearly our shared main objective. If it does not offer a substantial step up in security, and is more inconvenient method to boot, then it should absolutely be deprecated, as that's a reflection of reality. NIST in its role as a neutral arbiter of technology in my opinion is simply acknowledging this reality.

[mschleiff]

@tonyboo - If we want to talk real world, then it really comes down to what the service provider is willing to accept. Different service providers look at risk differently, and different service providers have differing tolerance for risk, and different service providers have differing options for MFA that they can afford/support/deploy/integrate, and different service providers have differing user populations for which differing authenticators are feasible (or not). So, rather than deprecate SMS, just consider all the warts around SMS and assign it an appropriate assurance score (just like the warts of hardware crypto authenticators and the warts of other kinds of authenticators should be considered to determine their respective assurance scores). Then leave it up to the service providers to figure out what's best for them.

[wpwoodjr]

@tonyboo "protecting the network as a whole" sounds like a use case that SMS isn't suited for. On the other hand it is rather useful for protecting against phishing attacks, for example. SMS used in the proper context is substantially better than just username/password. Otherwise you wouldn't see the big consumer companies pushing users to adopt it.

[tonyboo]

@mschleiff Deprecation is another method to do what you ask - 'assign an appropriate score'. We are into the semantic weeds here.

@WPWoodJr The whole point of an authentication mechanism fundamentally is to prevent unauthorized entry into, and thus protect, the network as a whole. SMS OTP is an authentication mechanism that was widely adopted as an antidote to the weakness of passwords. It was effective in that role, and was adopted by many players. It now has lost that effectiveness, and so it's time to move on.

[mschleiff]

@tonyboo - While it may be time for the services under your control to move on, it may not be time for the services under my control to move on. I'm trying to encourage the 800-63-3 authors to keep the guidelines as widely applicable as possible, and obviously several service providers are having grief with the general deprecation of SMS (even if you aren't). The decision to deprecate SMS (or any authenticator) should be left to each service provider. My services have to recognize SMS plus password as at least slightly higher assurance than password alone; and my services cannot deprecate SMS at this time. If the guidance in 800-63-3 won't work for my services, I'll have to use different guidelines.

[tonyboo]

@mschleiff Deprecation by NIST is simply a signal that SMS OTP has lost its effectiveness. It does not mandate an immediate change your practices in any way. It may be removed by NIST at a later date, but for now it may be used, but with caution, which sounds exactly like what you are planning for.

[wpwoodjr]

@tonyboo "In the security industry there is a tendency to let the perfect be the enemy of the good" - from the TrendMicro blog.

Deprecating SMS will have more far-reaching detrimental effects than simply acknowledging its assurance level, because it will prevent adoption of the "good" and reduce the use of 2FA.

[tonyboo]

@WPWoodJr What is the essential difference between deprecation and 'acknowledging its assurance level'? I can't see any.

[mschleiff]

If there's no difference between deprecation and assigning a very low assurance level, then why not just deprecate passwords?

[wpwoodjr]

@tonyboo because as @mschleiff noted above, "several service providers are having grief with the general deprecation of SMS". This happens because stakeholders want to know why SMS is being used if it is deprecated. Never mind that it is user friendly, much more safe than just username and password, and widely adopted... deprecation sends up a big red flag. Now you might say it is warranted, but others will say the benefit of SMS outweighs the risk sometimes. By setting an assurance level the red flag is avoided in favor of a considered discussion of what level of assurance is needed for a particular application.

[tonyboo]

To be clear, SMS OTP is being deprecated as an acceptable SECOND factor. So what was once quite effective - password PLUS SMS OTP - is no longer as effective, and stakeholders should be made aware of this, so they can factor it into their decision-making for the future.

@mschleiff Passwords can be one factor of a 2FA system. What's deprecated is that SMS OTP can't be a second factor. You can I suppose make SMS OTP a primary factor for a 2FA system, but the second factor for such a system shouldn't be passwords. My point is such a system is unlikely in practice, simply because of the cost and convenience considerations.

@WPWoodJr I think this is an internal communication issue. Deprecation as is commonly understood is a yellow flag, with the caveat that the flag is likely to turn red at some later point. Till the latter, it may be used, and preparations should begin for that eventuality. In my opinion, stakeholders would be asking that exact question right now if they were made aware of SMS OTP's declining effectiveness.

[wpwoodjr]

@tonyboo this is not just an internal communication issue. By planting its flag, NIST affects many downstream standards and decisions, including things like FICAM, etc. Deprecating SMS will have more far-reaching detrimental effects than simply acknowledging its assurance level, because it will prevent adoption of the "good" and reduce the use of 2FA.

What is your role here? Are you a service provider?

[wpwoodjr]

I would love to see actual stats from Google and others on how often people with SMS 2FA are hacked vs people without any 2FA. I believe those stats would prove the effectiveness of SMS 2FA (however not for all use cases!)

[tonyboo]

If your concern is whether this is happening in the field - yes it is. For example: https://medium.com/the-coinbase-blog/on-phone-numbers-and-identity-423db8577e58#.qxsjcsg6t

[wpwoodjr]

My point is you can reduce hacked accounts by a significant percentage with SMS, even if its not perfect. A "better" solution would have to demonstrate similar uptake and reductions. A hack-proof solution isn't better if uptake is low.

[readnotify]

Lets face it: if you can receive SMS, you're already holding the device that can provide significantly superior 2FA right in your hand.

SMS needs to be eradicated - except for money-grubbing telco's profiting at the expense of subscriber security, there is simply no reason to retain this obsolete near-useless tech whatsoever.

[robbiemalcolm]

Having read and researched much of cited examples of these exploits particularly those stated in issues 19 and 78 I agree with cmccolgan on this issue that the vast majority of cited examples are actually examples of social engineering, malware, MITB, MITM attacks and not related to cited weaknesses of SS7 or SMS.

I understand from reading NIST’s subsequent explanation on their blog that the reason for the proposed deprecation is the belief that SMS is fundamentally insecure. I also noted that NIST have cited a paper published by Positive Technologies “SIGNALING SYSTEM 7 (SS7) SECURITY REPORT” which I carefully studied to determine the level of risk to US carriers.

The ability to intercept a SMS in OOB authentication comes down to two weaknesses with SS7 used in combination with one another. a.) IMSI disclosure (as cited in section 4.1 of the report) and b.) being able to register a handset on a fake MSC / VLR and thus ‘roam’ the handset to another network without being detected by the user. For ease of use I am are calling the exploit of these two combined weakness ‘roaming intercept fraud’.

Firstly it should be noted that vulnerabilities cited in SS7 only impact GSM networks and as such there is no evidence to suggest that these issues affect CDMA networks of which represent the majority of US carriers. The notable exceptions are of course, AT&T and T-Mobile with a roughly combined market share of 56% essentially making roughly 44% of US subscribers immune to ‘roaming intercept fraud’

I believe that the rationale for deprecating SMS for OOB authentication due to these vulnerabilities would be akin to stating that we should deprecate TCP/IP because of a vulnerability in a firewall or in SSL. Clearly the solution is to fix the vulnerabilities rather than to suggest the phasing out of the use of SMS in authentication.

In addition I believe :

• Not offering SMS as a 2FA alternative to time-based one-time password (TOTP) applications will make it extremely difficult and costly for businesses to deal with users who have had their devices lost or stolen.
• Only 79.1% of US subscribers currently have a smartphone, of which more than half only download an app very very rarely. This leads me to conclude that, without SMS, more than 72% of Americans will be stuck without a viable 2FA solution

My calculations can be found here https://www.clxcommunications.com/blog/2016/08/nist-proposed-deprecation-sms-2-factor-authentication-2fa-may-lead-72-americans-not-adopting-2fa/

NIST highlighting the above concerns has certainly made Mobile Operators and Carriers and the GSMA to take these concerns seriously, which should be welcomed.

Full IMSI disclosure (a. above) is a known issue and has been recognised for some time as many operators no longer provide full IMSI to wholesale partners due to the possibility of other types of fraud. Progress has been slow until recently, on 3rd August 2016 the GSMA Wholesale Agreements and Solutions Group (GSMA-WAS) approved an amendment to the Binding Permanent Reference Document BA.20 – Fraud Prevention Procedures which does not allow the full IMSI to be disclosed for any other purpose than for sending a SMS message. Our tests on 10+ popular MNP providers showed that not a single provider disclosed a full AT&T IMSI for an HLR lookup.

With regards to b.) above being able to register a handset on a fake MSC / VLR we believe this is only possible on AT&T and T-Mobile from a network that has a AA19 roaming agreement in place and has integrated and fully testing handset roaming capability. As such this would therefore only be possible by a rogue employee inside the network of a roaming partner of these networks. As a consequence, this is not a flaw of SMS per se but rather of the security policies and procedures of the roaming partner. Regardless, we are aware of a number of operators that are in the process of signing agreements with vendors to install SS7 firewalls that will be able to detect suspicious roaming behaviour in order to protect against this vulnerability.

Apart from the above, there are a number of risk mitigation actions that can be taken by enterprises to prevent the risk of roaming intercept fraud which are -

• Requesting an MO SMS be sent back as confirmation (this is more complex scenario for a fraudster, particularly in the US due to the use of shortcodes for A2P traffic and the need to know the correct SMSC to return the MO to.
• Doing an MNP lookup (using HLR without full IMSI) prior to authentication to determine the country location of a handset and whether the handset is roaming will allow for detection of this fraud.

Conclusion:

I believe that AT&T and T-Mobile and the rest of the GSM carriers in the world will mitigate these risks sufficiently to prevent the need for SMS deprecation. And as such NIST should remove deprecation of SMS OOB and review SMS again in the next release based on improvements made by the US Mobile Carriers both in terms of processes, and technology.

[readnotify]

It personally sickens me to read phone companies putting profits ahead of user security, cherry picking things they can attack, and utterly ignoring all the problems they can't solve in a desperate attempt to muddy the issue and scam weary readers with their bogus directed comments.

It double-sickens me that someone working for a phone company has insufficient courage to stand up to their company's bad ideas, and actually do the dirty work for them.

SMS is broken in DOZENS of different ways, and despite decades of time to attempt to fix some of these problems NONE HAVE BEEN FIXED.

It is utterly irrelevant what someone "believes" AT&T, T-Mobile, and every other worldwide carrier that those subscribers roam onto, might one day in future attempt to address: the plain fact is that they have not done this despite YEARS of knowledge of the problems, and even if they miraculously did, that's just one problem and doesn't fix porting issues, SDR sniffing, handset implementation oversights, malware susceptibility, and so forth. Lets all keep in mind that these companies are all also required to comply with CALEA and other laws, so even if they wanted to secure SMS, they are legally blocked from doing that properly.

There is no reason to use SMS for 2FA EVER.

Every modern user who can receive SMS is already in possession of the device which can do properly-secure 2FA, without needing to resort to unsecurable antique technology.

[readnotify]

p.s. robbiemalcolm works for mblox - a company that makes money sending SMS messages.

[tonyboo]

@robbiemalcolm Your arguments are not convincing. Your first argument is flawed - one can port a CDMA number into a new phone and acquire control enough to make SMS OTP useless. So CDMA is not really more secure that GSM when it comes to OTP. Second, TCP/IP is insecure, which is precisely why SSL was invented, to secure socket communication. SSL overlays a provably secure layer on top of an insecure transport layer. Without SSL, there would be no e-commerce. In the MFA domain, passwords are weak, and CANNOT be secured by layering on a provably insecure SMS mechanism.

[wpwoodjr]

I'm guessing that you guys (@readnotify and @tonyboo) don't have much experience in rolling out 2FA to people who haven't the slightest interest in using it. As the TrendMicro blog points out, "some 2FA authentication is better than no 2FA at all. We still see a lot of systems in vital industries–ICS and health care, for example–where 2FA ought to be used, but isn’t. In these cases, some form of 2FA is still an improvement ... For system administrators considering whether to adopt 2FA for their own systems, our advice is: don’t rule out SMS as a method just because of news reports that say it’s “insecure”. For systems that need the maximum protection, maybe it’s not appropriate. However, for systems where ease of use, cost, and user acceptance matter–it’s still a viable solution".

[readnotify]

@WPWoodJr - wrong. I have considerable 2FA experience.

This is a discussion about not using SMS for 2FA, it is not a discussion about 2FA - do not try to twist the argument. Just because 2FA in general sucks so badly that most people never want to use it, does not mean it's a good idea to try getting people to use the worst and most insecure kind of 2FA!

SMS should never be used for 2FA - it really is that simple. There are numerous PHONE COMPANIES around the world who themselves warn about NOT using SMS for 2FA - nobody would know better than they do.

Heed their advice!

I notice today how the "SMS Deprecation" is being removed in some current commits. Nothing like a bit of "abuse of power" by those with that privilege to force their agenda on us and bypass the debate and our wisdom and experience eh?

[wpwoodjr]

@readnotify you are missing my point. SMS is important for my business because it is the simplest for recalcitrant users to understand and use. Your business may be different, so don't use SMS, OK? As Trend Micro says, "for systems where ease of use, cost, and user acceptance matter–[SMS is] still a viable solution".

[garciamike]

Thank you all for the many wonderful and informative comments you've provided to this issue. This is, in NIST's approach, about engaging the community to co-develop this document. Simply put, the document is, and will continue to become, a better product because of the content you provide in this forum.

That said, I ask that you please lighten the tone. While many of the comments here have excellent content that helps inform the discussion, I feel I must emphasize that commentary of any nature that is directed toward individuals or individual organizations, or is otherwise disrespectful, is subject to removal.

This is difficult work and, for some of the countless decisions that go into this document, it's hard to get the right balance. That's why we need help from those with experience in the community. Undoubtedly various individuals will have different views. At NIST, our rule is to listen to any view that is provided respectfully and professionally. A comment that veers even slightly from that basic rule is, to us, no comment at all.

Thanks, and keep your contributions coming!

[IDmachines]

Thanks Mike. This forum is very encouraging and appreciate git as way to engage.

[tonyboo]

@garciamike Thanks for doing all that you and the team do, thinking about these issues and conducting the hard work of creating standards, and especially for providing a space for comments on GitHub. My view is this process cuts through a lot of the noise and advances the state of the industry.