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

[gumbi west]

Yes, it also appears that biometrics are safe under either of two conditions--that you have another factor. Oddly they didn't specify which one. I would think that the biometrics would be the something you have (e.g. your voice, finger, or eye).

Re:the phone may not always be in possession phone

[__aaclcg7560]

daemon possession

Re:the phone may not always be in possession phone

[FatdogHaiku]

So... if you printed it out you would get:
The phone with a phone lives mainly in a tome*...

*Assumes user has enough paper to print all recursions.

Re:the phone may not always be in possession phone

[Killall -9 Bash]

I have been saying this for years. All biometrics (and smart cards, and RFID, etc) can offer is a false sense of security.

Hackers can't steal your finger print or your eye, but they can steal the digital signature of it.

Re:the phone may not always be in possession phone

[Jason Levine]

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? If someone can do this, they are, in essence, stealing your fingerprint. And once someone has that, good luck changing your "password."

Re:the phone may not always be in possession phone

[Blaskowicz]

Smart cards offer access to cash on my bank account and cell phone identity and have been around doing these very same things since the 90s.
I am sure it could go possibly very wrong, but so far some people must have done something good security-wise.

Re:the phone may not always be in possession phone

[AHuxley]

Biometrics is just another big lump of code down a network that a brand hopes the consumer's hardware created and that no other party has, can recreate, or become, capture and use.
Still the same networks, a consumer OS that is wide open, a few extra trusted chips sold to anyone and some data set created by a user of interest.
A better way is for real world use would be https://en.wikipedia.org/wiki/...
The change seems to be that the old idea was the that phone would be a text device that gets a message from a cell tower.
The phone is now the device requesting and using both messages on the same device or the via same network.
More data via a well understood biometric chip is just another set of data to capture, but for the user something they think is safer.
Once such data is captured, is been traded or sold, a user is left with few ways to just alter or create their own trusted, unique future access.

Re:the phone may not always be in possession phone

[lgw]

I'm not quite sure what BeauHD is being paid for.

BeauHD is old and busted - two generations behind now. Clearly he needs to be upgraded first to Beau3D, then to Beau4K if we're to get good editing.

Re:the phone may not always be in possession phone

[ShanghaiBill]

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.

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.

Re:the phone may not always be in possession phone

[Opportunist]

Unfortunately it's also pretty hard to change. If your fingerprint gets compromised, you can't simply change it as you would with a password.

Re:the phone may not always be in possession phone

[NigelTheFrog]

Technically, most people (with the exception of clumsy carpenters) have 9 alternatives when it comes to fingerprints. Just stick to one until someone steals it, then switch. If [(average time it takes for someone to steal your biometric data) x 10] > (your remaining predicted lifespan), then you win!

Typo

[Anonymous Coward]

...because the phone may not always be in possession of the phone...

Do the editors not even read submissions anymore?

Re:Typo

[gweilo8888]

Do the editors not even read submissions anymore?

You say that like they ever used to.

Re: Typo

[TimMD909]

Do the submissions not even read submissions anymore? FTFY

Re:Typo

[v1]

the editors don't read what the editors don't read.

Re:Typo

[goose-incarnated]

...because the phone may not always be in possession of the phone...

Do the editors not even read submissions anymore?

It's not a typo - it's proof by fight-club assertion :-)

Re: Typo

[Opportunist]

Do submissions not even submit submissions anymore...

Why do I have that odd feeling that our friend with the "app" fetish will be here in a minute?

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:I heard you like phones

[bosef1]

There is no Zuul... only phone.

Re:I heard you like phones

[uvajed_ekil]

There is no Zuul... only phone.

All your phones are belong to Zuul? Uh oh...

Re:I heard you like phones

[ChunderDownunder]

Which is why Firefox OS failed; there was no XUL.

Better vs. Perfect

[1SQ]

So we're throwing out the "better" in search for the "perfect?" Until tokens gain the ubiquity of phones (which seems unlikely), doing away with SMS-based two-factor authentication may just force many users back to the password-only era.

Re:Better vs. Perfect

[Alan Shutko]

Not many organizations are required to follow NIST security standards. Those that do are in a better situation than most to switch to physical tokens or to software-based tokens of one sort or another. Note that "5.1.3.2. Out of Band Verifiers" does not deprecate sending a notification to a smartphone app that can then authenticate the user and provide a secondary authenticator.

Re:Better vs. Perfect

[GeekWithGuns]

Context here - NIST is setting standards for government security. If you are running a government system or are the vendor selling to the government, this will apply to you. DoD and IRS shouldn't be using SMS 2-factor authentication for users of their systems. DoD is not really the problem here, since 2-factor to them is certificates on smart cards (CAC), but I wouldn't be surprised to see IRS using SMS based 2-factor for some kinds of password recovery.

SMS based 2-factor for taxpayers accessing the IRS...that could be harder to replace.

So Google and the rest of us don't have to abandon SMS for 2 factor, but I'm kinda in agreement with NIST - not the best idea due to the ability to intercept the authentication code.

Re:Better vs. Perfect

[retchdog]

Ability? Christ, it's practically a default. I configured my MacBook to handle my SMSes through message.app because it's much more comfortable and ergonomic. A few months later, I get two-factor SMS authentication as part of work. Yeah, not exactly two-factor.

Using SMS for two-factor authentication is an anachronism, and I wouldn't mind the government stopping people from calling SMS "two-factor authentication", anymore than I mind when it stops people from selling industrial effluent as baby formula. It's just plain old fraud.

Re:Better vs. Perfect

[darnkitten]

I'm in the password-only era, you insensitive clod!

Seriously. I live in a rural town without cell service. And with a lot of poor and elderly people who either can't afford or can't effectively use smart tech.

Something these tech wonks never seem to think about.

Re:Better vs. Perfect

[jrumney]

Until tokens gain the ubiquity of phones (which seems unlikely)

Since tokens can be generated by software on phones, even obscure and obsolete phones, tokens are already more[1] ubiquitous than phones.

[1] hardware tokens can be taken into secure areas where mobile phones are banned.

Re:Better vs. Perfect

[Z00L00K]

I can agree that SMS authentication is not really good now that most phones can be compromised. However the alternative of having biometrics is not good either since fingerprints can be cloned, and so can eye irises. Or you can go full "Demolition Man" on it too.

Re: Better vs. Perfect

[Z00L00K]

And certificates can be cloned, so they aren't really good.

A security token not connected physically to a computer and protected by a pin code is still the best alternative.

Re:Better vs. Perfect

[Z00L00K]

The only disadvantage with a separate token is that you will have a lot of them. I have two today, one for my bank, one for work.

Re:Better vs. Perfect

[Chrisq]

So we're throwing out the "better" in search for the "perfect?" Until tokens gain the ubiquity of phones (which seems unlikely), doing away with SMS-based two-factor authentication may just force many users back to the password-only era.

But then, what if you are not in possession of your token?

Re:Better vs. Perfect

[Anonymous Coward]

Exactly. And not being in possession of your token is probably going to take longer for you to realize and report, than not being in possession of your phone.

Re:Better vs. Perfect

[TheRaven64]

You don't need Paypal to do this. You can send SMS to most landlines and the message will be read out by a computerised voice.

Re:Better vs. Perfect

[bluefoxlucid]

Tokens are obtainable. They're afraid someone will obtain your phone, and advocate using another non-phone thing someone could obtain instead. It's weird.

Re: Better vs. Perfect

[retchdog]

eh, fair enough. this is the defense the SMS auth providers would use. it's a fairly weak case imho, but yeah, it is not nothing.

Re:Better vs. Perfect

[Rob Riggs]

So we're throwing out the "better" in search for the "perfect?" Until tokens gain the ubiquity of phones (which seems unlikely), doing away with SMS-based two-factor authentication may just force many users back to the password-only era.

Two words: Google Authenticator.

There is no excuse for using SMS for 2FA when you have TOTP with a well-documented interoperability standard in RFC 6238.

Re:Better vs. Perfect

[pak9rabid]

See also: FreeOTP

Re:Better vs. Perfect

[rjstegbauer]

If I understand this properly...big IF I guess...

I use Google's SMS TFA, which is uses when I logon using a new computer and love it. Google also allows me to print out a set of codes that I keep handy in case I don't have my phone.

Additionally, the second factor could be a call on a preregistered land line. Couldn't it?

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

[GeekWithGuns]

I agree, if your concern is possession of the phone, then soft tokens are almost equal to SMS. The big difference is the ability to intercept the code out on the network (VoIP, Google Voice, etc...).

One thing that I have seen done with RSA tokens that could be done with software tokens as well as SMS tokens would be appending a PIN to the token. That way even if the token is stolen, the thief would need to know the PIN and where to append it. You don't need a biometric to unlock the token, just a password or PIN to be the 2nd factor.

Re:Non-sequitor

[EvilSS]

There is another problem with SMS 2FA that isn't covered in this document, and is much easier to pull off: It is currently too easy to social engineer phone companies to move service to a new device. This has happened recently to several execs to allow script kiddies to take over social media accounts that are using SMS 2-factor.

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

[Ronin Developer]

This, theft or the cloning of the SIM are three possible threat. Another is the display of the SMS on the lock screen which would divulge the token to anyone who has access to the device.

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.

Re:Non-sequitor

[tlhIngan]

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.

The summary is poorly worded. It's not YOU in possession of your phone, it's your PHONE in possession of the PHONE NUMBER. The idea is this - if you're going to do SMS as a verification, NIST recommends checking that the phone number you're sending the SMS to is actually the phone you intend to send it to.

There is another problem with SMS 2FA that isn't covered in this document, and is much easier to pull off: It is currently too easy to social engineer phone companies to move service to a new device. This has happened recently to several execs to allow script kiddies to take over social media accounts that are using SMS 2-factor.

No, that's what NIST is talking about. Your phone may not be in possession of the phone number.

Basically what NIST is saying is that phone numbers don't lead to a specific phone. They lead to A phone, but not necessarily the phone you think it goes to. This is especially as modern phone systems allow trivial movement of phone numbers to anything that can provide voice service.

Re:Non-sequitor

[Vliegendehuiskat]

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.

I would not use a hardware device with biometrics since you can be forced to provide those. I'd rather use a hardware token which requires a PIN to function which only allows you to enter an incorrect number a few times before it wipes the key.

Re:Non-sequitor

[bradley13]

Ultimately the only secure 2FA is a dedicated hardware token that requires biometric authentication to function

Only, biometrics can be faked. A couple of years ago, my favorite computer magazine (German) showed how they could lift and reproduce a fingerprint good enough to fool many fingerprint scanners. For that matter, biometrics are stored as digital data, which can be stolen. And once your biometric data has been stolen, you are well-and-truly screwed, because you can't exactly change your fingerprints, retina, or whatever.

Security is a problem, and there is no perfect solution...

Re:Non-sequitor

[Anonymous Coward]

There was a cluster of hacks of various YouTube channels recently which coincided with a convention.

The mechanism was social engineering of various cell phone providers to transfer a phone number to a new SIM card, together with compromise of passwords via some other method, possibly rogue WiFi APs.

Re:Non-sequitor

[Anonymous Coward]

Too easy for who? I suspect 2FA over SMS would thwart 99% of the account hacks that occur today.

Re:Non-sequitor

[Nemyst]

The NIST deals with recommendations for just about everyone at once, so while it may not matter for Joe Q. Public, it's a good thing to keep in mind for government implementations or sensitive academic work and so on.

If the message is intercepted and not delivered...

[mark-t]

wouldn't the person who is expecting to receive it kind of, you know, notice?

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?

[the_Bionic_lemming]

It's even worse when you DON'T have SMS. Websites and steam keep spamming you with "upgrading security" and refuse to let you OPT OUT of the harassment.

Re:Provide your phone number for extra security?

[ChunderDownunder]

One reason I avoid SMS signups - travel.

I've never done global roaming, picking up a local SIM when I get there. So what happens if my Australian bank detects I've been shopping in Argentina or Portugal and asks to verify I haven't had my details stolen by sending an SMS?

My previous phone had dual-SIM which might have been an option. Although these Asian manufactured things tend to be 4G on one and 2G on the other, which is no help if, as here in AUS, they intend to discontinue 2G capability.

Re: Provide your phone number for extra security?

[Anonymous Coward]

Works fine until they ask you for the answer to your security question over the phone. So make sure your random garbage is still pronounceable and not too revealing about your sexual preferences.

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.

Re:Provide your phone number for extra security?

[Opportunist]

Yes, "security questions" are quite an oxymoron, they DEcrease security considerably. Because they are usually made up from things that anyone can find out about you or that some people who know you may know. Your mom's maiden name? Easy to find out. Your first teacher's name? Not that hard either. Your pet's name? Likely to be found on your Facebook page. Your first car? Probably something I'd know if I had known you for long enough.

So my mom's maiden name is something akin to fRwef12$nu'ka. And don't you DARE disallow me to set that, you xenophobe racist bastard!

Re:Provide your phone number for extra security?

[Opportunist]

I laughed, but still: Waaaay too easy to guess.

Re:Provide your phone number for extra security?

[pla]

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?

You realize that you don't need to give a meaningful (nevermind "true") answer to those security questions?

"Mother's maiden name?" "#10 dual-window envelopes".

Re:Provide your phone number for extra security?

[jittles]

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.

I always make up the answers to these questions using a system based on the question and the site that helps me remember the answer but prevents someone from just Googling my life store too find out the answer.

Re:Provide your phone number for extra security?

[pla]

This adds no additional security to a system secured with a password

Sure it does - It means you have two passwords, rather than a password and a piece of publicly-available information... Though the GP already gets that, I basically just rephrased his "type garbage, and save a copy" as something a bit more user-friendly. :)

That said, I otherwise agree with you completely - Though, I also don't really see the problem here. Biometrics would solve some of the usability issues with passwords, but at the cost of introducing entirely new ones.

Really, I think a lot of this comes down to "how much security is enough"? Sending an SMS for two-factor counts as far, far more than adequate 99% of the time; and that even counts as massive overkill 99% of the time. For virtually all uses, just using something like your favorite porn star's name is good enough.

Re: the phone may not always be in possession phon

[Entrope]

In that authentication paradigm, biometrics is usually called "something you are", while an authentication token/device/badge is "something you have".

WAS

[Kunedog]

phone

WHO?

Re:If the message is intercepted and not delivered

[uvajed_ekil]

wouldn't the person who is expecting to receive it kind of, you know, notice?

Not if your VOIP is hacked and you aren't immediately aware of it.

Re:If the message is intercepted and not delivered

[uvajed_ekil]

oops, if it is read before delivery I mean

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.

Re:that's not a "ban"

[jittles]

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.

The NIST most certainly can ban their use for government projects. Also, you can clone someone's SIM card or use a social engineering attack to get a new SIM issued for a specific number. So it's not just a matter of verifying the phone is a mobile phone. There are more sophisticated attacks that SMS auth allows.

Re:that's not a "ban"

[ooloorie]

The NIST most certainly can ban their use for government projects

Which part of "of course, some organizations may choose to make those guidelines mandatory" did you not understand?

So it's not just a matter of verifying the phone is a mobile phone. There are more sophisticated attacks that SMS auth allows. Also, you can clone someone's SIM card or use a social engineering attack to get a new SIM issued for a specific number.

Those are not "sophisticated attacks" and other two factor authentication schemes are subject to cloning and social engineering. It is exceptionally stupid to give up the extra security and simplicity of SMS authentication because of such objections.

Re:that's not a "ban"

[jittles]

The NIST most certainly can ban their use for government projects

Which part of "of course, some organizations may choose to make those guidelines mandatory" did you not understand?

My point in mentioning this is to say that NIST is a government agency and that certain parts of the government are bound to NIST determinations. Not as a matter of self determination but a matter of law. And that you cannot just say that "NIST can't ban SMS 2FA" because they did exactly that for the US Government.

So it's not just a matter of verifying the phone is a mobile phone. There are more sophisticated attacks that SMS auth allows. Also, you can clone someone's SIM card or use a social engineering attack to get a new SIM issued for a specific number.

Those are not "sophisticated attacks" and other two factor authentication schemes are subject to cloning and social engineering. It is exceptionally stupid to give up the extra security and simplicity of SMS authentication because of such objections.

The problem is not 2FA but doing 2FA over SMS. And those are relatively sophisticated attacks as they require a bit more knowledge and planning than just taking over someone's email account and using the password reset option to capture password reset requests or something like that. You actually have to know who the person is and who their cell phone provider is in order to execute such an attack. If you're overseas, you may need a local accomplice to help you execute the attack. There are better ways to provide 2FA. For instance, you can use an auth system that uses secret information from the server plus a user PIN to help prevent someone from using a auth code captured by something like a MITM attack.

Re:that's not a "ban"

[ooloorie]

There are better ways to provide 2FA.

There are better cars that a Honda Civic. That doesn't make a Honda Civic a bad car.

Mom was phone

[tepples]

In the story about making out with your girlfriend, getting a call from her parent to check on her, and discovering that her dad is dead?

Simple. Mom was phone.

Three factor auth

[Anonymous Coward]

Stop, please stop pushing three factor auth with the "are, have and know". Biometrics = bad = unchangable. Auths have to be mutable in order for plausible deniability. Body parts will be ripped off either to extort a non-body physical item or for the body part itself - never worth it. How many movies have to be made to drive this point home?

Re:Good. Now ban credit cards.

[PrimaryConsult]

People without credit cards or cell phones are actually real people too, believe it or not

Yes but they don't actually matter to to large corporations. Accommodating a few outliers is simply more trouble than it's worth.

Not a big deal

[ITRambo]

The only problem I see with SMS codes is that if you don't have your phone you can't log into your MS, or other, online account from a new device. If you do have it, receiving the SMS is simple. Why would someone steal an SMS double authentication code? They can't do anything with it, except annoy the person waiting for it.

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.

Number portability

[quenda]

In Australia, and presumably other countries with number portability, SMS authentication is a joke.
While a SIM has strong crypto, and cannot easily be cloned, it is trivial to steal someones phone number by 'porting' it to another SIM.
The only 'secret' you need is their account number (dumpster dive, emails, social engineer or mailbox) or date of birth for prepaid.

The only thing less secure is those password resets, that ask for the make of your first car, etc - something guessable or found on your facebook profile.

Re:I think about this sometimes

[Chrisq]

If somebody gets a hold of my phone they could fuck me over pretty good.

Chances are that Apple or Google "owns" your phone. And yes, they could fuck you over pretty good.

Re:Good. Now ban credit cards.

[Anne Thwacks]

Well, if you consider the majority of the worlds population "a few outliers", well then maybe you are corporate America

FTFY

Ban? Melodrama much?

[Opportunist]

NIST isn't your god, you can safely ignore whatever NIST says, unless you are one of the handful of companies that actually HAVE to follow NIST guidelines.

What NIST does in this case is provide best practice recommendations. Nothing more. That's no "ban", not even by a longshot. Hell, if the FCC says "oh, we think you maybe shouldn't..." it is closer to a ban than NIST saying "you SHALL NOT!"

The article doesn't even talk about who has to implement this, only that two-factor out of band authentication shall not be done via SMS anymore in future implementations.

Sorry, but ... the hell, how is this newsworthy?

They can steal your money directly, and your car

[raymorris]

Suppose your car has a fingerprint scanner, along with a keyfob. That's something you HAVE and something you ARE.

Theoretically, could a thief steal your key fob and your fingerprint? Yes, of course. Would it be easier to just a call bring a trailer and steal your car directly? Yes, of course.

People will ALWAYS be able to steal. Security isn't about making it impossible. It's EASIER to steal a key fob than to steal both a fingerprint and a key fob. Therefore, adding the fingerprint increases security.

Re: the phone may not always be in possession phon

[gumbi west]

With this new "knife" technology in the hands of the wrong folks, your finger/eye are suddenly much more like, "something you have."

It really is very insecure

[Murdoch5]

Currently I work for startup and my job is to secure our web based protect, which includes enforcing login authentication, encryption standards, database usage and more.

The method we use to employ was a tri-factor authentication system, password, TOTP and SMS / Email based tokenization, but we've officially taken the SMS authenticator away because just as this post points out, you have to guarantee who has the phone and somehow confirm the phone which received the SMS is the phone which was meant to.

Think of this concept as having an IP Address, you can send a message to IP 1.1.1.1 and you have to assume that where it ends up is the right destination, because you have to assume the person saying they're 1.1.1.1 is who was assigned that IP Address and not someone who basically stole it and is using it in an unauthorized fashion.

The better way to handle this kind of access security is to use AES_CCM based tokens that have TOTP built into them and force a login through use of a mutli-hop path that gets created and is active only for X Minutes after the user tries to login with their password. How this is works is that after you get the password, you generate a path descriptor which can talk with your Secure DNS. You encrypt this information with some form of AES (or any other standard). You put this information into a secured database system such as MongoDB with the FIPS compliance module active, and then send an email to person X with a link that activates the SDNS module, to read the string from the database, unencrypt it, develop a dynamic path to the end point and request the users TOTP from something they have. Once the user is logged in, you scramble all this information, then securely wipe it from both the program, memory and database and start all over.

Re:If the message is intercepted and not delivered

[mark-t]

If you are expecting a message, and do not receive, it, then how would your VOIP being hacked stop you from noticing? You might not realize that your VOIP has been hacked, but how could you not notice that you didn't receive the message?

If the message is intercepted while it is being delivered, but is still otherwise delivered normally while a copy is saved elsewhere, I can see that being a problem, because the recipient gets no cues that interception is occurring. But that's not what I was talking about... the article talked about the problem of messages being intercepted and then *NOT* being delivered, which I would imagine is not going to be a serious problem.