NIST is no longer recommending two-factor authentication systems that use SMS, because of their many insecurities. In the latest draft of its Digital Authentication Guideline, there’s the line:
[Out of band verification] using SMS is deprecated, and will no longer be allowed in future releases of this guidance.
Thoth • August 3, 2016 7:24 AM
SMS should have been removed long time ago considering the SS7 problems. Better to use a secure token.
Paul Renault • August 3, 2016 7:36 AM
There’s an unwanted ” at the end of the URL for the ‘the latest draft’ link.
Bill • August 3, 2016 7:48 AM
Dis anyone tell the Social Security Administration?
Loyal Citizen • August 3, 2016 9:01 AM
@bill, from the article: We expect to provide additional options in the future, dependent upon requirements of national guidelines currently being revised.
Clive Robinson • August 3, 2016 9:05 AM
It’s about time…
As far as I can tell I was the first person to publicly discuss the use of SMS as a “side channel” or “out of band” authetication system back last century.
As long term readers will know I had problems with the idea –SMS being a “secondary service” being just one of many– and have put my hand up to various other failings of the idea over the years. However in my mitigation back then access to SS7 was jealousy guarded by the telco’s so was not realy an issue then. However “money talks” thus not just access was given as an extra stream of income, the mobile service providers slashed costs on all sorts of areas that had adverse effects on security, thus alowing easy social engineering attacks.
What I am worried about though is that this NIST change in requirments will be misread by many that ALL side channel authentication systems –which are the only ones that realy work– will get “tarred with the same brush” and thus “the baby will get thrown out with the bath water”.
Oskar Sigvardsson • August 3, 2016 9:07 AM
What about TOTP apps? That still good?
Burl • August 3, 2016 9:09 AM
So what’s the alternative?
Thoth • August 3, 2016 9:16 AM
@Oskar Sigvardsson
No serious security flaws are known for TOTP or HOTP if used in a separate tamper resistant token (not in a smartphone app !!!!).
Bob Dole • August 3, 2016 9:25 AM
No way it’s going to be deprecated in the final version. Calling it now.
Mike Glendinning • August 3, 2016 9:30 AM
Indeed, I raised such concerns on Bruce’s own “Crypto-Gram” mailing list back in 2005. See the last “Comments from Readers” at the end of the following:
https://www.schneier.com/crypto-gram/archives/2005/0515.html
I’m rather surprised it has taken so long for people to realise the flaws in this approach. Other, less easily compromised side-channels need to be considered.
WhiskersInMenlo • August 3, 2016 9:33 AM
The link
https :// pages.nist.gov/800-63-3/sp800-63b.html%22
Should have the extra trailing quote edited out.
https://pages.nist.gov/800-63-3/sp800-63b.html
The solutions make sense but application security on a smart phone is the next risk:
“Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. 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 may no longer be allowed in future releases of this guidance.
“If out of band verification is to be made using a secure application (e.g., on a smart phone), the verifier MAY send a push notification to that device. The verifier then waits for a establishment of an authenticated protected channel and verifies the authenticator’s identifying key. The verifier SHALL NOT store the identifying key itself, but SHALL use a verification method such as hashing (using an approved hash function) or proof of possession of the identifying key to uniquely identify the authenticator. Once authenticated, the verifier transmits the authentication secret to the authenticator. Depending on the type of out-of-band authenticator, either: * The verifier waits for the secret to be returned on the primary communication channel.”
In some states the requirements for ID to get an ID are very Kafkaesque.
I can see serious issues with the elderly and new social security security monkey motions.
So far Facebook has yet to question my 7/4/1776 personal birthday but when they do…
This is a related issue concerning Telegram specifically:
http://www.reuters.com/article/us-iran-cyber-telegram-exclusive-idUSKCN10D1AM?sp=alcms
Clive Robinson • August 3, 2016 10:47 AM
@ Thoth,
No serious security flaws are known for TOTP or HOTP if used in a separate tamper resistant token (not in a smartphone app !!!!).
Which begs the question of how you securely transfer information from one device to another…
On the general principle the interface needs to be independently mediated to avoid covert channels and the like, it is going to come down to human typing etc, due to “cost concerns” by banks etc… Made worse by the average human has a very poor ability to secure and make available another device.
The problem with humans as I’ve noted a few times when talking about authentication is they can not easily “copy type” gibberish. Which generally causes issues to do with low entropy overall not just per key press, which can be down in the 1-2bit range any way. Thus whilst 140 chars are available, more than five or six words are going to be beyond most peoples abilities / patience.
Thus the question of “Is sixty to eighty bits of entropy going to be sufficient?”…
Vesselin Bontchev • August 3, 2016 10:47 AM
@Thoth SS7 attacks aren’t The Problem, since for them the attacker needs telco-level access (nation-state, telco, or someone who has hacked a telco). Bad enough to be a concern, not bad enough to panic about it.
The Problem (worth panicking about) is smart phone malware that can intercept, relay and/or suppress SMS messages. The attacker just needs to convince the victim to install an app from a shady app store – or even from the official store, if the shadiness of the app hasn’t been discovered yet. (Talking mostly about Android here – examples are myriad – but even iPhone isn’t totally immune.)
OTOH, please note that (insecure) SMS-based 2FA is still way better than no 2FA at all.
Darron Wyke • August 3, 2016 10:58 AM
I don’t see why they’re doing this. SMS is still very secure, obviously dependent upon your mobile network’s security (in a country that does not have mobile encryption per export laws, obviously it wouldn’t be very good). Since both the device and the network have to be trusted for there to be communication, it would be rather hard to spoof something. Of course this is irrelevant of a state actor, who can have a copy of the encryption keys stored to decrypt traffic realtime, but more realistically can just do a direct tap at the tower or backbone site and bypass that.
Or am I really missing something else here? Is the concern about malware on the phone? At which point it really does become an example of throwing the baby out with the bathwater, since you’re saying one thing is insecure because of another insecurity. We should get rid of SSH too, since it’s just a blowfish wrapper around command sending (in plaintext!).
@Darron Wyke,
Maybe you say that now, but wait until the lawn mowers (somewhere over the rainbow(horizon)) come out and your phone starts dropping to 2G.
Let’s see how you feel about 2FA via SMS then, what is it: a 12 dollar chipset now?
CDMA may be security through obscurity for a short while longer, but don’t expect GSM to cover your loses.
Darron Wyke • August 3, 2016 12:18 PM
@r
What are you on? So what if my phone drops to 2G? The two-way trust is still there. That’s built into the communication protocol, irrespective of EDGE, CDMA 2K 1X, etc. The device trusts the tower and the tower trusts the device.
Maybe next time you should come up with a real argument.
War Geek • August 3, 2016 12:23 PM
I’ve used app ‘Signal’ by Moxie Marlinspike’s open whisper systems as a second factor for authorizing password changes to privileged accounts in lieu of SMS for a while.
Not fantastic since it both requires that the parties already be contacts of each other, and assumes physical possession of the phone can be part of the trust. But, works for me because anyone I use that with is also someone who’s voice I’d also recognize over the call to said phone.
Beats SMS hands down for my purposes especially considering its a free app.
Where GSM is concerned, your device trusts the tower: any tower, every tower, all the time. Maybe you’re right that those ‘independantly operated substations’ aren’t authenticated well enough to perform a full MiTM and impersonate your IMEI off-site of your actual handset. But I do seem to recall inclusive of the SS7 exploit that some of them are, the proximity of your device to these fake-towers IS part of the problem – as being connected to a non-routing 2G synthesized service provider is effectively a DoS when someone else is running intercept on your actual IMEI.
Did I get that right?
Anon • August 3, 2016 12:42 PM
Why using SMS is a bad idea:
http://www.scmagazineuk.com/natwest-online-banking-suffers-sms-smishing-scams/article/481378/
Robert • August 3, 2016 12:49 PM
When I use [HT]OTP to authorize bank transfers and the machine I use is compromised, the attacker can wait until I want to make a transfer and substitute its parameters. No additional compromise is needed.
When I use second factor via SMS to authorize bank transactions, the text message I get may contain all the important details of the transaction. In that case the attacker cannot fool me into making a transfer I didn’t intend just by compromising my machine: I’ll see that the SMS is about a different transaction than the one I wanted.
In this particular case SMS authentication seems to be better than [HO]OTP. Obviously, a specialized app that receives the data that I would otherwise get by SMS is even better.
Anon • August 3, 2016 12:49 PM
The old hacks are still the best:
Darron Wyke • August 3, 2016 1:54 PM
@r
“Where GSM is concerned, your device trusts the tower: any tower, every tower, all the time.”
BZZT! Wrong. There’s a two-way trust. The device validates the tower, and the tower validates the device. As I said before. They each exchange keys, which are hashed and compared to known good hashes. If that key is compromised, yes, that’s a problem. But these keys are the lifeblood of the mobile provider so they safeguard them. As someone who took the security keys off of cards and loaded them into systems in a past job, I know the level of security that’s implemented there.
“Maybe you’re right that those ‘independantly operated substations’ aren’t authenticated well enough to perform a full MiTM and impersonate your IMEI off-site of your actual handset.”
What does an IMEI have to do with anything? The IMEI identifies the handset’s hardware, it doesn’t identify the SIM card used to authenticate on the network. SIM card stores the network information, preferred network list, and more. You might be thinking of the ICCID, which is a hardware identifier of the SIM card, and basically impossible to duplicate properly due to the multitude of keys and access control in each SIM card.
“But I do seem to recall inclusive of the SS7 exploit”
And as Vesselin Bontchev explained above, SS7 basically requires you to be a nation-state attacker, at which point it doesn’t matter since they can just tap the copper that runs from the tower to the trunk. Big friggin’ deal. Or hack the telco, which…isn’t easy.
So you’re 0/3. I suppose it’s still not a good idea to argue with someone who worked for one of the largest SIM card manufacturers and still knows the security measures used by cards and devices.
Wael • August 3, 2016 2:17 PM
@Darron Wyke, @r,
SMS is still very secure…
No, it’s not! When using SMS for an OTP, the weaknesses of the OTP “design” and the weaknesses of SMS need to be considered. It’s not earth-shattering to design a secure protocol over an insecure transport. Rather, I would say that the majority of OTP implementations over SMS are insecure.
What does an IMEI have to do with anything?
IMEI is an identifier of the device. MNO’s can do “things” with the IMEI.
Freezing_in_Brazil • August 3, 2016 2:20 PM
It`s a wonder that SMS has been chosen as an authentication factor in the first place. It was a somewhat stupid thing to do.
yoshii • August 3, 2016 2:24 PM
I agree with “Bill”.
It is ridiculous that the Social Security Administration just recently implemented and mandates SMS for people logging into their accounts on the Social Security website(s).
This is really annoying.
It seems obvious to me that anything that uses wireless technology and/or cellphones would be inherently insecure and pretty much just caters to data miners who want your telephone number as well as all of your other personal info.
I can’t believe anybody who would believe it provides any more “security” in this day and age.
It’s just more bidirectional doorways and passageways to your personal info.
I say good riddance to SMS, and yet now it will be lingering for decades probably.
@Darron Wyke,
Okay, you may be entirely right. You are right to assume I have zero experience with any of the hardcore technical aspects of this stuff.
But then how do you explain the ‘Stingray’ devices?
@Vesselin Bontchev,
You forgot one:
@Darren Wyke,
http://imsicatcher.info/article/imsi-catchers-practical-knowledge-for-activists/
If you haven’t seen this stuff, I’m sure some of it is speculative as not too many people own these 2-300,000$ devices. Obviously, generally speaking the problem isn’t coming from your end (SIM Manufacturer?) but that doesn’t mean you haven’t been targeted (see above) or have been targeted (see Stringray/2G). Like I said, I’m pretty sure these are GSM only attacks – you seem to make me feel like you’re in CDMA somehow… maybe I read that wrong. Either way, I know I’ve seen SDR work in the CDMA arena recently. But Mr. Bontchev is right, all it takes is one Dark Avenger and you’re pwned anyways.
🙂
@Vesselin Bontchev,
Actually,
“The Problem (worth panicking about) is smart phone malware that can intercept, relay and/or suppress SMS messages. The attacker just needs to convince the victim to install an app from a shady app store – or even from the official store, if the shadiness of the app hasn’t been discovered yet. (Talking mostly about Android here – examples are myriad – but even iPhone isn’t totally immune.)”
Is an incomplete statement too, have you ever gotten SMS spam? Alot of it comes in the form of links, and considering the level of fragmentation and spoilage within android itself I wouldn’t expect those url’s to not be backed by something like the blackhole exploit kit and a root exploit.
So: Unofficial Stores, Official Stores and “insecure storage” are practically moot.
@Darron Wyke,
Those are nation state actors, if you work in the SIM community you have a target on your back.
@All,
Correction to my above statement:
Those (specifically) are not nation state actors, they are miscreants using existing repurposed nation state techniques.
de La Boetie • August 3, 2016 4:10 PM
@yoshii – “pretty much just caters to data miners who want your telephone number as well as all of your other personal info”
Exactly – SMS authentication is going to persist precisely because it gives the service your crown jewels (from the marketing perspective). You can tell with the usual suspects, they are DESPERATE to make you give them your mobile phone number (usually because of some excuse like recovery, let along 2FA).
Not only is the SMS side channel vulnerable, the whole phone is because it’s complex and the OS pre-owned (presuming smartphones).
Seems to me sensible fob-based (and cheap) solutions based on U2F are NOT being adopted because they do not allow that marketing exploitation, are refutable, which is also why one should reject biometric and SMS as second factors. I think the banks and payment merchants will be keen on biometrics so they can pass the liability for fraud onto you.
tcmJOE • August 3, 2016 4:13 PM
And yet the only service I use regularly that accepts my Yubico U2F key is Google…
(GitHub accepts it as well, but I found doing 2FA for them more of an annoyance, and my personal GitHub account doesn’t have that much on it…)
Millicent • August 3, 2016 9:32 PM
Vesselin, re: “The attacker needs telco-level access (nation-state, telco, or someone who has hacked a telco)”—could you be overestimating the difficulty here? How hard is it to start a telco? There seem to be lots of them, and when there are lots of targets there are probably a few with weak security.
Thoth • August 3, 2016 10:17 PM
@Vesselin Bontchev
Yes you are right. Malwares are one of the problem. I have forgotten to mention that since I was in a hurry when I was replying.
@Clive Robinson
That is more of a Usability vs. Security problem. The security lines in the authentication server setting a limit on how many wrong OTP code tries before requiring the user to manually re-synchronize the OTP token again which would bring up more questions whether the security of synchronization is fit for securing the future transactions.
Asking a user to type in hexadecimal 160-bit SHA1 outputs would not be acceptable by users either since they are not adapted at typing more than a couple of characters correctly. The better options would be using PKI tokens (for added security) but here is the pain of pushing out requirements to all banking customers or users to adapt to using PKI infrastructure which neither of the web browsers provide a usable interface.
I guess it all boils down to how much Security vs. Convenience needs to be set in place. From highly secured physical tokens that are capable of PKI to 6 to 8 digit OTP codes, consumer behaviours drives market practices and security standards.
Just to add a little side note, if you still remembered the National Authentication Framework the Singapore Government tried to roll out but toppled over like a tortoise being flipped on it’s back (in a very pathetic and sarcastic manner), the SG Govt attempted to revive the plan many times and this time round they settled on SMS authentication to protect national infrastructures …. just only shortly before NIST kicks SMS authentication out of the door.
The NAF framework is crucial to the local National Security because of a national authentication implementation called the SingPass which the service is controlled by the IDA (controlls all Government electronic standards including security – across the board including military domains which is comparable to NIST with a bit of NSA) and outsourced to a contractor running the SingPass service.
The current SingPass authentication service only uses complex passwords and once authenticated it opens gateways to all government services tied to that account. They attempted to spawn a front company to sell a branded TOTP tokens from Vasco called OneKey token (simply a rebranding of Vasco’s OTP token) and they vigorously push the sales of the OneKey token for the NAF/SingPass framework. The end result was a flop. Few bothered to purchase the OneKey token and the plan fell apart. They attempted to revive the plan by using SMS authentication and the deadlines for registration was moved back again and again due to poor reception until it was made mandatory for all SingPass accounts to use SMS authentication otherwise access would not be granted and the application for the SingPass account by citizens are really a pain in the bottoms taking around 1 to 2 weeks to get the access while having to apply via a badly designed application webpage or by physical presence. One of the side goals of the NAF is to collaborate with banks as well to provide a single authentication framework.
As the SingPass SMS 2FA rolls out, Singapore Government services would become vulnerable to attacks on the SMS services by SS7 vulnerability and malware intercepting OTP codes and not to forget the SingPass is the Government’s authentication gateway and once that is breached, National Security and integrity locally would be placed at high stakes as the attacker would be able to traverse all the Government services associated to that account breached. For protection of high stake government access portals, I would have expected something more robust (continual push for OneKey token adoption).
In fact, I recently thought that our mandatory national ID cards we carry in SG should be upgraded to include an embedded on-screen (H/T)OTP function so that it becomes more binding to a particular individual. For added security, the OTP code could be used with extended code length 8 to 10 digits output or more according to different portions of Government services being accessed in accordance to the level of security required.
Clive Robinson • August 3, 2016 11:59 PM
@ Freezing in Brazil,
It`s a wonder that SMS has been chosen as an authentication factor in the first place. It was a somewhat stupid thing to do.
Not at all read my earlier post in this thread.
The problem back then was the banks had piss poor online authentication, and they were not going to spend even a dime doing anything about improving it for their ordinary personal customers (even less so for most business customers).
Likewise most personal customers could not tell you where their cheque book was or how many cheques they had written out. Thus there was little hope of them using a hardware token any more rationally.
Thus a solution was needed that the banks would find cheaper than mailing out Transaction Authentication Number (TAN) lists, the German banks favoured, and that customers would keep with them or under their control for most of the time…
A TAN list had the advantage that “it fits in your wallet” so any “token” solution had to be similarly “keep with you at all times” technology. RSA or equivalent “tokens” were a non-starter back in the 90’s so a “key ring” option was out. This left “mit handy” as the only viable alternative to the TAN list.
Most people do not remember mobile phones of the 90’s or the levels of security the mobile network service providers went to. But back then phones were neither smart or cheap and the networks had been suffering significant income loss due to stolen or cloned phones. Oh and there were no VOIP or equivalent suppliers.
Much has changed in the intervening couple of decades. From the network operators perspective stolen or cloned phones are nolonger an issue and customer retention is. So as a consequence security has gone out the window compared to customer relations. Phones that are not “smart” are a rarity these days and have almost “Machismo Status” with those to young to have owned a mobile phone in the 90’s. But also technology has changed, back in the 90’s the Internet was still “dial-up” or “leased line” mobile Internet was for “rocket scientists” with VOIP and similar just “proof of concept”. On-Line banking was not on the Internet at the start of the 90’s you “dialed-in” to the bank, and got a “bulletin board” or “Video Text” type interface, thus most modern on line security risks were not thought of back then.
As has been observed occasionally by engineers “Different times, different problems, different solutions”.
So if you want to “call out” or blaim somebody, it’s the banks out of date technology usage you should be targeting. Not the engineers, who can only solve known problems at the “design time”, not those yet to be thought of long into the future. Even if engineers could fully future proof designs, without regulation enforcing it the market will enter a race for the bottom and the “profit today” cost will ensure managment will not let them to do so. It’s why the economists idea of “free markets are efficient markets” fails to translate into “socialy efficient” as people are going to find to their cost with “Smart Meters”, “Internet of Things”, “Medical Implants” and other “connected” technology with more than a one year market life cycle.
kevinm • August 4, 2016 4:57 AM
Many people here do not seem to be aware how easy it is to hijack SMS texts and how low is the barrier to getting SS7 access. Please watch a few minutes of “SS7: Locate. Track. Manipulate. [31c3] by Tobias Engel (SnoopSnitch)”, starting from https://www.youtube.com/watch?feature=player_detailpage&v=lQ0I5tl0YLY#t=296
Thoth • August 4, 2016 7:02 AM
@r, Vesselin Bontchev, kevinm
If a malware can access SMS auth codes, it could as well even change them and delete them. If a malware stole the SMS auth codes and deletes notifications on the usage of the SMS codes, the user would become oblivious for most part. No need for hacking the A3/5 ciphers used in GSM.
All it needs is hacking the already weakened endpoints (i.e. Android) and quietly intercepting, replacing and deleting SMSes as needed. Although SS7 is for nation states, as @Bruce Schneier likes to put it, these vulnerabilities would quickly spiral out of control if left unhandled (which is mostly the case in the industry and one good example being EMV payment) until it becomes common place and probably even the script kiddies could download scripts to mess the entire SS7 when the opportunity arrives.
John • August 4, 2016 1:40 PM
This is hilarious…
So NIST bans SMS as 2FA and Social Security just changed their authentication scheme to 2FA using SMS…
Thoth • August 4, 2016 6:27 PM
@John
It shows just how slow standards are adopted and changed.
StingRay • August 4, 2016 7:44 PM
Has anyone used the apps that supposedly protect ones phone from Stingrays? I suppose they require additional authentication?
Wael • August 5, 2016 2:18 AM
@r,
They only work on specific phones.
They don’t work on these phones! Next revision will!
Wael • August 5, 2016 2:19 AM
That’ll be called: StringRay 😉
@Wael,
Also note that MIT’s ultra-fast camera and potato chip bag hack would work on any visible component of the string.
https://people.csail.mit.edu/mrub/VisualMic/
I think that’s the right link? not sure.
Wael • August 5, 2016 4:39 PM
@r,
Also note that MIT’s ultra-fast…
Me likes it. It needs to have its own thread! Will check the pdf later. I’m glad the engineer is good because his voice sucks when he says “Marry had a little lamb…” 🙂
@Wael,
Just in-case that wasn’t sarcasm,
https://www.schneier.com/blog/archives/2014/08/eavesdropping_b.html
Odd, I didn’t think it was that old.
Even funnier,
“In other experiments, however, they used an ordinary digital camera. Because of a quirk in the design of most cameras’ sensors, the researchers were able to infer information about high-frequency vibrations even from video recorded at a standard 60 frames per second. While this audio reconstruction wasn’t as faithful as that with the
high-speed camera, it may still be good enough to identify the gender of a speaker in a room; the number of speakers; and even, given accurate enough information about the acoustic properties of speakers’ voices, their identities.”
Screams what I said last week about steganographically modifying ‘artifacts’ by manipulating digital jpeg’s and raw.
https://www.schneier.com/blog/archives/2016/07/friday_squid_bl_536.html#c6729627
As usual, I may be wrong.
Wael • August 8, 2016 3:06 AM
@r,
Just in-case that wasn’t sarcasm
Definitely not sarcasm! I just got stuck with some things. I’ll be there hopefully soon. It’s bookmarked and on my queue. Real engineering work, the kind of “hack” that has interesting implications. For example, suppose some “bad guy” or gal publishes a video without sound…. Hmmm, a lot of applications.
Thiago • August 8, 2016 4:23 PM
Much more interesting than the deprecation of SMS is the recommendation AGAINST password complexity requirements in appendix A.3 https://pages.nist.gov/800-63-3/sp800-63b.html#appA
@Thiago
Specifically, they recommend against putting an upper limit on password complexity. NIST:
“Password length has been found to be the primary factor in characterizing password strength.”
and
“Users should be encouraged to make their passwords as lengthy as they want. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes.”
I don’t know of any substitute for a long password or passphrase chosen by a geniunely random method.
The NIST document doesn’t go into this, but requiring users to include uppercase, numerals, etc. decreases password complexity because it forces users to sacrifice entropy elsewhere in the password. It’s a subtle point about human cognition that seems to be missed by a large number of commenters on the subject.
The NIST document goes on to recommend placing a strict lower limit on password complexity by requiring a minimum length and checking against a library of the most easily guessed passwords.
@Thiago,
We’re all just going to have to switch to smart cards.
I see no other route, god help us all if they chooce biometrics.
Rob • August 9, 2016 8:57 AM
So there is a media frenzy about the NIST SMS A2P proposed deprecation, take a look at my latest blog, I explore the options and recommend practical way forward. These the proposed guidelines may lead to 72% of Americans not adopting 2FA at all. Take a look – https://clxnetworks.com/nist-proposed-deprecation-of-sms-for-2-factor-authentication-2fa-may-lead-to-72-of-americans-not-adopting-2fa-at-all/
GnstheGЯain • August 11, 2016 8:27 PM
Had a talk with a senior dept. agent at Paypal over the phone on that very specific subject. My question was simple. Why using such a vulnerable, weak, and old MFA for securing user’s paypal account ? Why not providing something more secure, yet even more adopted: TOTP
Agent kept saying he can’t disclore the reason behind this choice, and that they makes all the possible effort to keep user’s account safe blabla..
Jarrod Frates • February 1, 2017 8:59 AM
I know it’s five months later, but it’s worth noting that the current revision no longer deprecates SMS. There was discussion about it in this issue thread:
Kevin Mitchell • February 8, 2017 11:10 AM
Facebook won’t allow Time-based One Time Passwords unless you also supply a backup plan. Storing one-time codes in my password wallet doesn’t seem to count as a backup plan, and I don’t have a hardware key (which I consider risky anyway: No passcode on the key?).
So they insist on SMS. Or you don’t get login verification at all.
Where’s the best place to bring this to the media?
Afshin • November 17, 2017 1:25 PM
It has been removed from the final version:
https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/
jeff birks • June 25, 2019 12:37 PM
There are many of possible alternative factors that can be employed.
Biometrics can be problematic, but are gaining popularity
Hardware tokens are still very practical.
OOBA push techniques are also an option.
Ryan McNally • August 12, 2019 12:44 PM
Amazon have apparently missed the memo on this. They allow the use of TOTP apps, which is good, but they also insist on an SMS-based backup to that, which is bad. They also offer no way to remove your mobile number from your account or to change that number to something invalid (attempts to edit the number must be verified by SMS).
I’m currently sitting through the second round of customer service calls to get them to delete my number from their system. I am not optimistic on the outcome.
In an unrelated issue, they also seem to use payment card expiry date for user verification, which is an … interesting approach to securing PCI-sensitive data.
Ryan McNally • August 12, 2019 12:59 PM
… and my pessimism is richly rewarded. Apparently there is no way to remove the phone number from the account as it is part of the dataset used for security purposes.
- • September 2, 2019 11:46 AM
@ Moderator,
The above from “Jeff Birks” is unsolicited product advertising.
John Smith • September 3, 2021 12:20 AM
NIST no longer recommending SMS in favor of Biometrics is kinda like jumping out of the frying pan and into the fire. Not a fan of biometrics at all. It’s a novel convenience unlocking or id mechanism, but secure?….err not really.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
r • August 3, 2016 7:19 AM
Or over VOIP.