Slashdot Mirror
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."
recursive function overflow
...because the phone may not always be in possession of the phone...
Do the editors not even read submissions anymore?
So I put a phone in your phone because the phone may not always be in possession of the phone
phone
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.
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.
wouldn't the person who is expecting to receive it kind of, you know, notice?
File under 'M' for 'Manic ranting'
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.
Prove anything by multiplying Huge Number times Tiny Number
In that authentication paradigm, biometrics is usually called "something you are", while an authentication token/device/badge is "something you have".
TFA should not be about the ability to track you or your money. I'm looking at you Facebook.
Stupid twats will not give an app id without your cell phone number or your credit card number.
People without credit cards or cell phones are actually real people too, believe it or not.
And you never leave a finger print on a glass that could be 3d printed or jelly moulded into a fake replacement? I am sure your optometrists is securely storing the pictures of your eyes from your last check up. What happens when government department is hacked and your finger print files are leaked (omb), you can't change your finger prints or rentinas.
phone
WHO?
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.
This is a hacked account, for which the owner can not be held responsible.
oops, if it is read before delivery I mean
This is a hacked account, for which the owner can not be held responsible.
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.
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.
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?
is ensuring any keys stored on them can't be exfiltrated from the card itself (are the electronics on the card trustworthy and emissions shielded?), and that any keys stored within them were generated/are backed up on an airgapped computer, ideally in an isolated room (meaning visually, acoustically, electrically, and physically. Failure at any of the four can lead to exfiltration or generation compromise as well.) If those mitigations are taken, then short of very expensive 'active' surveillance from an extremely well equipped foe it is unlikely for the keys to be compromised. Assuming you have a smartcard that is 'programmable' (javacard, basic card etc.) you could also use non-standard algorithms on them to ensure your encrypted/decrypted/signed output is quantume hardened, although likely at a significant throughput penalty.
I'm not sure what the patent/copyright situation is on smart cards today, but they, sim cards, and sdcards (now that the memory/device industry is looking to abandon them for that incompatible new sd-card replacement) would all make good candidates for open source electrical/protocol compatible equivalents with fully documented and vetted designs for security related purposes. SD cards, esp multi-device SDIO cards would be perfect for a combination storage/crypto device with a protocol standard that could be used on almost any device with an sd card slot and open source firmwre (IE most cell phones, tablets, and some media players.) Done properly you could have the keys stored in protected memory on the sd card and have plaintext data encrypted *ON* the sd card and read/written as the OS provided necessary lock/unlock instructions. While data could still be extracted in three corner cases, under normal circumstances the data would not be in a usable state except when an authorized application/kernel had provided the identity information needed to unlock it (which could be scripted for a card by card authentication method.) Done right it would raise the bar to data exfiltration significantly, outside of already compromised devices. (Any modern x86/x86_64 or arm chip is probably compromisable if not compromised by the factory firmware by default though :/)
4ry4nbr0sb4pUr3bl00d3dh03z :^P
If somebody gets a hold of my phone they could fuck me over pretty good.
I don't care if I don't own them. I'll just hire different ones.
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.
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.
See that "Preview" button?
Packers Movers Bangalore Packers Movers Electronic City Packers Movers Marathahalli Packers Movers Whitefield Packers Movers Mysore
At the risk of sounding very paranoid, I wonder if 2FA SMS isn't being doubted by NIST because LEO cannot effectively hack it as it has tokens.
Naaa. Too far out there to be true. I mean, that would assume that US security organs have weakened encryption or something silly like that.
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.
As people use phones for browsing, the second factor in phone-based 2 factor auth is essentially moot. Any attaker with root on the phone can get both the password and the SMS (or token, what ever). Less likely: if a phone is stolen, the thief could possibly get in, if the user used some kind of password manager. How can routing of SMS messages be a bigger problem than this?
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?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Who was phone?
With this new "knife" technology in the hands of the wrong folks, your finger/eye are suddenly much more like, "something you have."
It is EASY to steal a fingerprint, if you're ruthless.
Just hack the finger off with a machete. Simple way to steal luxury cars or empty rich guys bank account. The rich guy won't come after you - he'll be on his way to the hospital. Oh, and he won't be pulling a trigger either . . .
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.
Still, the best factor is "something you know".
It's the easiest to invalidate if stolen, the easiest to make arbitrarily complex to defeat brute force, and the hardest to reconstruct from casual observation or theft unless you are carless.
Something you have, is the second best because it's the easiest to detect when you have lost it, only marginally harder to revoke and replace if lost, and can be hardened against unauthorized reproduction to some extent. It is also the very best second factor to include as it is strong in ways "something you know" is weak and "something you know" is strong in ways it is weak. The authentication device + password is the best overall solution, and even weak implementations like using your phone as the device and allowing 4 diget numeric pass codes are very strong compared to other common systems.
By far the worst factor is "something you are" because you can't revoke it, you can't hide it from casual observation, and you won't know is someone else is using it. Hell in some cases it can't even uniquely identify you (facial recognition vs twins).
The only use case where biometrics makes any sense are when you would seriously consider "no security" (say to unlock your X-Box or keep your sister out of your diary) or in cases where you are adding additional security to a system that already has the otehr two (like adding a retina scanner to a key-card + pin lock ).
Laypeople think biometrics are the strongest factor because they mistakenly assume that it being hard to revoke makes it hard to forge (they're assuming you ahve to get plastic surgery to fool facial recognition for example). That isn't true as the forgery can use any method to produce a fake (like a mask or photograph), but revocation means changing the way the actual person reads on the scanner.
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.
File under 'M' for 'Manic ranting'
>SMS messages may be intercepted and not delivered to the phone.
It shouldn't take NIST to make you aware of this though.