Hacker News new | past | comments | ask | show | jobs | submit login
NIST declares the age of SMS-based 2-factor authentication over (techcrunch.com)
298 points by Osiris on July 26, 2016 | hide | past | web | favorite | 227 comments



I don't think eliminating SMS authentication is a good idea. While it is vulnerable to social engineering attack (and sniffing if you are near the receiving phone), SMS authentication has proven to be invaluable for most ordinary users. Those users are everything but eager to use anything more secure then their 6 letter password. With tricking many users into using SMS authentication, companies like Google have improved the overall security of most account by a lot. While it is possible to remove an SMS authentication mechanism, it is a lot harder and probably not worth for most accounts.

Most people will not bother to install Google authentication and just not use 2FA (who wants to steal their account anyways /s). Even if they did install it, recovering their authentication codes if they have lost their phone is incredible hard (because too many won't use backups – even if it is as simple as apples iCloud backup).

What I think companyies should do is give their users a choice not to use SMS authentication. Power users (and hopefully most high profile users) will make use of that and normal user can just use SMS.

In the end it is always a trade off between convenience and security and sadly convenience almost always wins for most users even for easy solutions. So we (the developers) should provide them with the most convenient way they accept which offers the maximum security and SMS does just that.


SMS auth is atrociously bad compared to offline 2fa:

- Requires a telecom provider in the first place (in some countries, that legally requires a passport/national ID tied to the phone number)

- Offers no means of backup

- Forgot to disable 2fa on that one account you log into once a year, before changing your phone number? have fun with that

Nevermind Google Authenticator. Android and iOS should have a high quality TOTP app installed by default. One that permits backups. "Users won't install it" should NOT be a factor and if Apple/Google want their users to start using 2FA it's in their own interest to do this anyway.


It's still better than no 2FA, which I imagine is the alternative for the vast majority of people.


I would assume this depends on the nature of your account.

On most of my accounts the probability * cost of getting hacked is much smaller than the probability * cost of loosing access.


Meta: Why is it that in one thread, I'm saying "same-machine 2fa is better than no 2fa" and getting "but but it's not secure!" as replies, but when I complain about sms auth being insecure, impractical, nonstandard and more expensive than TOTP I'm getting "it's still better than 2fa" as a reply?


Different people are responding to those threads, and those different people have different opinions?


I agree, it is bizarre to be taking different sides of the argument in different threads...


I want to call this out, because I feel it's a big issue we have as humans trying to engage in reasoned debate - the idea that an inconsistent or changing view is somehow "weak" or invalidates the argument.

If someone is changing their opinion, that's a good thing. It means they are taking on board new information and not blindly following their original opinion.

If someone appears to have an inconsistent view, perhaps their position is simply more nuanced than the simple "for or against" buckets the debate actively tries to lump all participants into?


Yeah, I was sarcastically pointing out the absurdity of bitching about different people on HN having different responses whilst he himself has slightly different perspectives on subtly different issues...

I don't care that his view is inconsistent, I just think the complaint of people disagreeing with him (in a comment format which encourages disagreement more than agreement) was kinda ridiculous :)


The point I was (clearly too subtly) trying to make is that if you're going to use an imperfect solution in the name of getting it in the hands of more users, you might as well use TOTP and make concessions - it can be more accessible than SMS auth, which has so many problems attached to it, it's hard to understand why it's getting defended on HN anymore.


> Nevermind Google Authenticator. Android and iOS should have a high quality TOTP app installed by default.

True, Red Hat has made FreeOTP which is available for Android and iOS and works really well.


Also, Microsoft Authenticator is already on every platform and getting even better on every platform soon. I know it would freak a lot of people out to have an app with the M-word in the name, but it's a good, solid TOTP app.


Is it open-source under GPL and immune to patent suits? Lock-in, EOL's, and lawsuits are biggest risk Microsoft poses. If they GPL'd it, then Microsoft being the source probably doesn't matter.


It's OATH/IETF standards compliant, which mitigates (if not removes) risk from lock-in and EOL's, thanks to industry standards. [1]

I don't think Microsoft is patent suit immune, but they are certainly capable of handling patent suits without disrupting user capabilities/security. Unless you are suggesting Microsoft owns patents in using the standards and somehow might sue users over that, but both OATH and IETF have patent grants in place regarding the standards.

Open source under any particular license (esp. and inc. the GPL) is orthogonal to it being immune to patent suits and/or lock-in/EOL. It's also orthogonal to security and/or privacy you can have secure apps both with and without open source. Certainly there are reasons where technically inclined users would prefer to have access to the source, but within the larger context of this discussion where the question is if there is an app available in any app store that matters that you could point a non-technically inclined friend/relative to, Microsoft Authenticator is one option and whether or not it is open source, it's still a better cross-platform option than SMS (and Google Authenticator which isn't as cross-platform, but has as many risks as you mention here as Microsoft's option).

[1] https://openauthentication.org/specifications-technical-reso...


"Unless you are suggesting Microsoft owns patents in using the standards and somehow might sue users over that, but both OATH and IETF have patent grants in place regarding the standards."

Exactly what I'm suggesting. Both Microsoft and IBM regularly file plenty of patents pertaining to about anything they create. They also regularly sue companies over them with Android alone producing hundreds of millions in revenue from such suits. So, one shouldn't use anything from Microsoft that might need to be cloned or ported later unless having a copyright and/or patent license. The risk with them is too high.

"Open source under any particular license (esp. and inc. the GPL) is orthogonal to it being immune to patent suits and/or lock-in/EOL."

A number of OSS licenses specifically include a patent license for use of that tech. It's implied by GPL for forks, too, which is not the case for OSS clones of a closed but free product. So, it's not orthogonal but directly involved via creation of patent licenses & protection of forks. It eliminates a good chunk of the type of liability that Microsoft likes to create.

"It's also orthogonal to security and/or privacy you can have secure apps both with and without open source."

I've made the claim myself & my background in high-assurance security lets me know the difference. This app isn't high-security or evaluated to it by any trusted party. So, we have to assume it's not secure by default like anything else. Nonetheless, this tangent doesn't matter at all to my point that Microsoft + closed-source offering poses risks that Microsoft + GPL offering don't. And that Microsoft makes such risks real for companies often enough for it to matter.

"it's still a better cross-platform option than SMS (and Google Authenticator which isn't as cross-platform, but has as many risks as you mention here as Microsoft's option)."

I don't use these products at all. So, I can't evaluate their features, UX, portability, etc. I'll take your word for it as a user that it might do a good job or offer advantages. My starting point based on comments here would probably be FreeOTP as it's free, open-source, and Apache includes patent provisions. I can imagine it not having Microsoft or Google's features to point I'd use them for overall cost-benefit analysis but I'd certainly have fall-back option.


The applicable tech is already under a patent license (see OATH and IETF documentation). The IETF patent literature seems particularly strong and particularly binding. (Which is good because a lot of the internet relies on IETF standards.) There's no greater risk with a Microsoft option than a Google option; it's open standards and all the options interoperate (regardless of what Google and other TOTP and HOTP apps have accidentally and intentionally told people and what confusion exists about the technology in general).

FreeOTP looks like a good option. It doesn't support every platform yet, and it doesn't have a mainstream recognizable brand name. Yes, it's a great fall-back option, though, for folks that want to "graduate" from the Google/Microsoft/other options.

I am just pointing out that of the mainstream brands that the public in general knows (and trusts to any degree) Microsoft's option has the best cross-platform reach and is the easiest to find in the respective app stores. That carries a lot of weight in getting a security feature that everyone should be using into more hands. I realize a lot of technical folks are still highly suspicious of Microsoft and feel there is a lot of risk in Microsoft's name.

Yes, it would be better if it were open source, but it is patent unencumbered, as much so as open standards typically get. I realize it might not be your preferred option. I was hoping, however, to point out to people that is a good option (not a perfect one, but a good one) to spread the gospel of Real Two-Factor Authentication.

(«I don't use these products at all.» You probably should be using at least one by now, if not several. OATH TOTP (RFC 6238) and OATH HOTP (RFC 4226) are the best options we have right now for Real Two-Factor...)


"The applicable tech is already under a patent license (see OATH and IETF documentation)."

There's patents that cover a specific tech, for its uses, for underlying mechanisms, and for vague extensions. These are the risky types that show up the most with most of it obvious to point it shouldn't be patented. Expensive to fight, though. Microsoft goes for all three. So, either IETF would have to own patents for all use cases and underlying techs or Microsoft would have to issue patent license for all such categories if they have any. A patent license for the whole product to be used or cloned however, as in the open licenses, is still safer.

"There's no greater risk with a Microsoft option than a Google option"

Unbelievable. You've looked at the court histories to find that Microsoft and Google have caused about equal damage to companies with patent suits, lock-in, or obsoleting core products. They haven't. Google doesn't even compare, esp the billions Microsoft extracted with legal suits, except on encouraging lockin where Google at least stays ahead of most competition in terms of capabilities instead of stagnating. Virtually no comparison in actual damage done although I'll concede Google is becoming more like Microsoft every day in terms of sneakiness & lock-in strategies.

" I realize a lot of technical folks are still highly suspicious of Microsoft"

You should try the non-technical folks who've been burned by them with Windows activation failures, forced upgrades of hardware, forced ads on their paid Xbox Live, BSA developing snitches in organization, licensing schemes, lawsuits over nonsense patents, and so on. You don't have to be technical to be suspicious of an organization that pulls as much BS as Microsoft. I've met many non-technical people using Mac's (or enterprise Linux) because they didn't want the trouble of dealing with Windows or Microsoft. Worst horror stories I hear from Apple users in terms of company are the "Apple tax" and issues with non-Apple hardware. Also the PPC to Intel transition at one point. Collectively not in same ballpark as Microsoft's behavior, esp in financial risk.

"Microsoft's option has the best cross-platform reach and is the easiest to find in the respective app stores."

This could be true. Again, if it's usable, better than others, and you can avoid lock-in, then sure go for it as it's best option. Also, go for it if others are so bad they wouldn't use them anyway. Better than nothing. These are potential use-cases.

"You probably should be using at least one by now, if not several. "

It usually means they hit two targets instead of one. My opponents can do that. I just don't trust the accounts at all. I assume my machine is compromised then work from there. Far as riff raff, I use a Linux desktop, update my software, secure the wireless, make randomish passwords, and so on. I could improve it but the few times I've had to change something was when online service itself was compromised. Yahoo and LinkedIn being only ones I know recently. I'm not saying other people shouldn't do it necessarily but little benefit for me given threat profile.


OTOH it's much better if you're authorizing single operations.

My bank in Poland has a scheme where it sends me a one time password together with some details on every mutating operation I do (e.g. on a transfer it sends the amount and account number of the target account).


Then you travel to a country where your mobile provider isn't working and all of a sudden you can't buy an airline ticket. SMS verification is also a terrible user experience.


All banks in Sweden have a similar scheme. It sends a token and a description to your phone on any mutating or authenticating operation, you input your code, and it signs the token and sends it back to the bank.


The BankID app? Most banks also have hardware TOTP tokens.


True, most banks have both. But the hardware tokens seem to be dying, slowly.

Personally I consider the transaction description a pretty killer feature of Mobilt BankID compared to the hardware tokens.


I know I can backup the contents of Google Authenticator on iOS if I perform iTunes backups with the "Encrypt backup" option checked. I'd wager that many who are backing up their phones don't have this checked, and don't realize if they have to restore their phone that the gAuth app will pretend you just installed it from scratch with no codes.

I'm not sure what the backup situation is with Android.

I've started backing up the actual strings that the app uses to generate the codes in an encrypted vault. You usually have to manually have these strings shown to you in lieu of a QR code. While creating another avenue for someone to hack you, at least I have a backup as well as a way to add a second device go show me codes. This is definitely beyond the capacity of the average user.

I think there might be online services that handle keeping codes for you? Like you can install an app on your phone, log into an account, and it presents you with all of your codes. Anyone have a recommendation for one of these that works well for them?


A lot of services also provide backup codes when you perform first setup. If you actually take those and put them in a safe place (maybe offline) like they say, that should mitigate a lot of the problems.

Let's pretend I'm a dummy user and I print all my backup codes out and throw them in a drawer somewhere. Now the only situation that locks me out of my account is both my home becoming damaged/unavailable AND my phone at the same time.

While a house fire or something could reasonably accomplish both (although I imagine most people would grab their phone before running out!), I think this reduces the risk to a point well below the "I dropped my phone in the toilet." level of not having backup codes.


> legally requires a passport/national ID tied to the phone number

Some may consider that a feature rather than a bug.


some also welcome fascism. heck, back home some still say the time with a dictatorship was better because there were no buns on the streets.


> Forgot to disable 2fa on that one account you log into once a year, before changing your phone number? have fun with that

It's even worse because with offline 2fa. Just reinstalling the phone means loosing the secret keys. I know it's possible to back them up but nobody does that.


> I know it's possible to back them up but nobody does that

Yeah that is a problem and that's why I'm arguing a high quality TOTP client should be shipped out of the box with Android/iOS and be synced with the Google/Apple account by default. A lot of the friction and backup issues would disappear.


but if TOTP is sync'd on with your google account, and you reinstall your phone... How do you do the first android login after reinstall, when you lost the TOTP ? Chicken and egg problem inbound ^^.


Permanent backup codes are a thing. You can generate those at any time. It's a UX problem, not a technical one.


I'm intrigued. The problem: you want to secure your access codes. The solution you appear to be proposing: permanent backup of your security codes somewhere.

But... how do you authenticate to this backup of your codes? It can't be through the same method that these codes unlock for you. Right?


> It can't be through the same method that these codes unlock for you. Right?

That depends who you're warding against. Any attacker sufficiently motivated has access to everything you have access to, so in theory, nothing is safe. If you're warding against MITM for example, logging in with an OTP code is enough, you don't even need a password. If you're warding against malware, then the OTP seed should be on a different (airgapped) machine. In both those scenarios, assuming you don't have a webcam, a post-it note with your backup codes is sufficient.

But yes, ideally the codes should be on a different machine, or at the very least in a different safe (eg. two separate KDBs with a different passphrase). And to answer your other comment, yes, they'll usually be safer on paper under your mattress.


Print them on paper and store them in a drawer in your house. That way it's legally protected more strongly and is immune to hacking.


Have we really resorted to "hide it under your mattress" as the best we can do for security?


For last chance backup it's a great way to handle it.

I have a waterproof, fire resistant chest that important papers live in. In the event of a disaster like a house fire, where my phone and tokens would likely be destroyed, it's a "Plan B" option. In the event of an accident or other event that results in my untimely demise, my wife or other loved ones can also access that chest and get backup credentials to access accounts with critical information.

The other nice thing about the analog world is that the legal path is well worn and understood. An online, service-based resource could be shutdown at any time and custodial disputes are either impossible or driven by some arbitration process on the West coast (I live on the east coast). Accesses to physical goods is clearer, and disputes get resolved by a local judge.


Excellent points. I'll add that physical safes and human-level protections have been standard in INFOSEC since Schell et al invented it as a formal field. All the early SCM for high-assurance systems was basically safes, locked rooms, and vetted people. Black programs (SAP's), like NIPSOM manual, also depend on such methods at some point.

Cool thing is that there's less laws of physics trying to break your security model if you take transistors, wires, and wireless comms out of your implementation. Paper without a line of sight has excellent security properties against remote attackers. :)

Note: Your point on the legal angle is wise and rarely made. I probably need to bring it up more often myself with these ridiculous rulings on privacy & data protection.


For awhile I ran a really large email system for an enterprise with lots of different lines of business -- right after the change in Federal rules of civil procedure that made email the best place to hunt for evidence in litigation. At the same time, we were working with archivists on some of the issues around preserving documents -- the ODF vs Microsoft format thing was a hot item at the time.

That really opened my eyes to the often ignored downsides of electronic media. In the US, we have constitutional protections around our "papers" in our homes, but third party doctrine dramatically weakens the protections around all sorts of things.


I don't get it. Many people don't use a smartphone at all, and anyway smartphones are much less secure than ordinary mobile phones (w.r.t. criminals), so this seems even less reasonable than requiring the SMS-based method for sensitive operations like confirming money transfers when online banking.

In fact, you should use a dumb phone for SMS-tokens if you want be on the safe side. (It would make more sense if the vast majority of Android phones wasn't insecure due to running an old OS with no updates, but that's not the case.)


>in some countries, that legally requires a passport/national ID tied to the phone number

Isn't that BETTER compared to anybody getting a phone number and using it to hack into your 2FA account?

>-Offers no means of backup*

That has nothing to do with SMS for 2FA. There are websites using SMS for 2FA that DO offer a backup way to authenticate in case you have an issue with your phone.

- Forgot to disable 2fa on that one account you log into once a year, before changing your phone number? have fun with that


> Isn't that BETTER compared to anybody getting a phone number and using it to hack into your 2FA account?

Huh? Are we talking about the same thing?

> There are websites using SMS for 2FA that DO offer a backup way to authenticate in case you have an issue with your phone.

A backup is not the same thing as a master key (even if we call those "backup codes"). I'll grant you that those are usually enough.


>Huh? Are we talking about the same thing?

What I'm saying is that a potential attacker that might divert PINs to their mobile phone, would at least have to be registered to get that phone account in the first place.


I want ubiquitous support for U2F / UAF, which would probably be the easiest solution.


That will probably in the form of Web Authentication API (https://w3c.github.io/webauthn/) which started out as version 2.0 of the FIDO specifications.

Microsoft will release prefixed support of the draft spec in Edge in the upcoming Windows 10 Anniversary update on August 2: https://blogs.windows.com/msedgedev/2016/04/12/a-world-witho...


How would that work with multiple devices? If the private key is stored in a TPM on the machine you used to register, then you can only ever use that device, or you have to go through some process to add additional devices.


How does backing up your keys in a server somewhere is better than SMS auth?


It's not, most likely. A working 2-factor scheme needs two devices and communication channels to the end user that are completely independent of each other.

If your mobile phone links to an account somewhere (e.g. Google account) that you can also access from the other device (e.g. a PC), and security-related settings can be changed from the other device, too, then that's insecure out-of-the-box.


You can encrypt them. I have no control over the idiots at my telecom who will reroute my number for anyone who provides the correct answer to some easy 'security questions'.


I see what you mean but if you encrypt them you will end up with an extra encryption key... that you'll need to store somewhere else.. otherwise, holding just an encryption passphrase is pointless as it's just the same as having two login passwords.


Another advantage of sms over dedicated 2FA apps is that even a 10 dollar phone or decade old phone running palm OS can be supported through it. (provided there is network coverage).

A problem with sms though is that you need cell phone coverage. I have been in situations where my transaction has timed out while waiting for the sms text to arrive.


You don't need a phone at all with TOTP. Just a TOTP client, which could even run on the same machine.

Fun story about this: When Blizzard introduced TOTP, I wrote a Blizzard Auth library and client so that I could use their 2fa on my desktop (https://github.com/jleclanche/python-bna). Why? Because I was sharing my Blizzard account with someone else, but still wanted to use 2fa. And people kept telling me "2fa must be on a different machine otherwise it's not secure", so I was using 2fa wrong and shouldn't use it at all.

Well that's bollocks. Same-machine 2fa is more secure than no 2fa at all. There's another comment below that talks about "perfect being the enemy of good" and that's exactly it.

So we absolutely should start promoting the fact that you can use TOTP on desktop, even if it's less secure. A lot of users don't use 2fa because they either don't have a phone, or don't have their phone constantly with them.


My point is someone should have written a TOTP client for your particular platform. Also different services use different TOTP systems. I am not well-versed in the matter. For example Steam uses its own app, many apps use google authenticator, microsoft uses its own, others still use authy. AFAIK they aren't interchangeable. I can't be bothered installing all these apps, each of them has their own nefarious agenda to hoover data off my phone.

SMS just works. (except when it doesn't)


TOTP is a standard. It just works, and it always does, even if you don't have internet on your phone. Even if you don't have reception. Even if you're out of credit. Even if you're out of the country. Even if your telecom provider hates you. Authy is TOTP. Google Authenticator is TOTP. They are all interchangeable. You can use FreeOTP if you don't want to deal with those: https://fedorahosted.org/freeotp/

Steam is SMS, and I heard they now have a shitty custom 2fa but what you're describing is services that don't use an established standard, which is compatible with hundreds of established clients. SMS isn't merely nonstandard (and now deprecated), it's more expensive for both the user (requires an active sim card) and the server (requires sending SMS to numbers all over the world).


The argument I've heard for why steam requires a custom 2fa is to do with trading on the marketplace [1]

The custom component makes sure that marketplace activity is valid (somewhat like the custom banking dongles you get that require both your pin and some transaction identifier).

They'd be better off allowing the option of standard TOTP auth for login, so users can use a standard authenticator app, and then layer on a custom app for trading if needed.

1: http://steamcommunity.com/discussions/forum/0/49463187366895...


Right their needs don't really justify a custom 2FA at all. Security through obscurity isn't all that much of an advantage and bundling the trade approvals and 2FA into the same app is maybe nicer for some users, but technically unnecessary. If anything it just scans as Valve's traditional NIH syndrome being exhibited here.


Can you elaborate? I don't use the marketplace; how does the custom component achieve any of that?


Detail: Google Authenticator is TOTP or HOTP, depending on how the service owner set it up.


Can "same-machine 2FA" be still called 2FA? Where is the independent second factor if it all runs on the same machine?


Factor 1 is the password, factor 2 is an ephemeral 1-time-use token.

If the token's seed is secure (YMMV), it doesn't matter if it's on the same machine.


A practical attack against users is malware on the machine, which would allow screen viewing and key logging

An attacker can then compromise both factors at the same time.

To me, this weakens the point of 2FA a lot.


And another one is to try passwords from previous database dumps against your email/etc. This is even more effective then using malware.

If you are able to use a second device for your 2FA, great but it is not always possible and 2FA on the same device is still better then no 2FA at all. I don't want to carry around a key just for all my 2FA passwords but still want to use my phone for common tasks that require 2FA.


It's pretty irrelevant nowadays anyway. People log on their google, facebook, etc accounts from their phone as well as their desktop so for a lot of user, 2fa is done on the same machine anyway - that machine just happens to be the phone.

Additionally, the keylogging threat is severely reduced against most 2fa (because the login has to happen before the user sends the OTP) and can be eliminated completely by ensuring the token code is on a separate screen and creating a 30 second lock on the account while the user is entering the code.


Mobile device security (well for IOS anyway) is waaaaaaaay better than PC security (for ordinary users), so I'd disagree on that point that app+phone is the same as browser+PC.

In what world is malware which has full control of the PC stopped by having the token code on a separate monitor but the same logical system (if that's what you're talking about).

An attacker with control of the PC can just get access to any app. on that PC...


Maybe on a $300 phone.

This is fun, I have a tablet here on my desk I was given to repair a couple days ago. It's a mainstream tablet here in greece, sold for 70-90€, the sort of thing you'd buy if you are an "ordinary user" who doesn't know any better.

Well it's running a 4.x android with a custom marketplace and it is FULL OF ADWARE. Seriously. There's fullscreen porn popup ads on the OS itself. There's hundreds of spam notifications, a "fake" screenlocker which captures your taps into ads, etc, etc. Seriously, this thing is like a Windows XP SP0 PC from 2005 after heavy adblockless porn usage with flash and java on. I actually haven't seen anything like that this decade.

This is what you get if you buy an off-the-shelf tablet or phone here. This is what "ordinary users" get. We gave up control of our own devices in the name of security, yet shit like this can still happen.

(Sorry for the OT rant. Seeing that tablet pissed me off.)


Your confusing Out of Band authentication with 2FA. They are not mutually exclusive, and solve for different issues.


How does that mitigate against the one machine being stolen?

The convention is that the chances of two devices getting stolen together are smaller. That's why offsite backups are a thing.


It can, eg. if the seed is encrypted, but that's not what you're warding against. If the machine is stolen, one might install a custom CA or even custom web browser to MITM any https connection and just steal all your credentials, sessions and what not.

When Battle.net authenticators were introduced, the primary threat was keyloggers and leaked passwords (from reuse). Both of those threats are eliminated by TOTP, wherever it is.


If the machine is stolen and someone changes your software (browser, CA, whatever), that only hurts you if the machine is later returned to you and you don't wipe it.

But this discussion was more about if the machine was stolen and the bad guys logged in to your online accounts from it.

In that case it is true they would have your OTP, but they shouldn't have your Blizzard password.


It doesn't.

Passwords (on the OS account and on the Blizzard account) mitigate against the machine being stolen.

OTP mitigates against the password being stolen.

It is what you know and what you have so that if someone gets one they don't automatically get the other.


As an aside: The "What you know and what you have" paradigm is failing, imo. We often say passwords should be autogenerated, unguessable and unlearnable, stored in password safes like Keepassx. This removes "what you know" and you end up with "two things you have" (An OTP seed and a password in a safe).

When both the password and the TOTP seed are on the same machine - assuming you autogenerated your password - they are both autogenerated and out of your sight so they really are just two things you have, and you have them in the same place. The difference is, it's impossible to capture the TOTP seed from the TOTP token being input - passwords are vulnerable to that.

Am I crazy or does that make the password completely redundant?


If you lock your password database with a long, secure password that you know, then you are still doing it "right".

If your password database is not encrypted with a strong passphrase, then you are right, they both become "what you have".


Ah, that's true.


NIST does make a difference between the two, which is why it calls it "out of band authenticator."


I'm confused. Both of these are just "something the user knows," right? Making this explicitly not 2-factor.

Or, are we treating the ephemeral 1-time-use token as something the user has?


edited: But if your machine is compromised, attacker gains access to both factors.

edit: I don't know. Maybe your implementation meets the definition of 2FA. Regardless, it certainly reduces the security


Your problem isn't with 2FA, TOTP or SMS, it's with sharing an account that isn't meant to be shared. When you use a feature in a way it isn't meant to be used, sometimes you're going to get some sub-par user experiences.

Should Blizzard support multiple users of the same account? Perhaps, but that's out of scope here.


The reasoning behind why I wrote the library is completely and utterly irrelevant. I regret mentioning it.


There are TOTP clients for both PalmOS and J2ME phones: http://developer.sysco.ch/php/mobile-dispatcher/mobile.dispa...


As others have pointed out SMS has issues. You need a phone contract.

Forget to pay your bill this month? No logging in for you.

Switch providers and forget to change all your services over? Oh well, all your data is lost, make new accounts.

Don't have a roaming on and go overseas? Guess you aren't accessing your travel plans. Even if it's on many ISPs charge 0.50+ per SMS. Why should have to pay just to log into unrelated services?

Go overseas and get a local sim? Welcome to swapping sims anytime you want to login (have had to do this for certain things that currently require SMS verification)


Also, don't like linking all sorts of on-line accounts to a single uniquely identifiable number? Tough luck!

It is disheartening that in an area of mass-surveillance by governments and advertisement networks alike, the notion of separate identities for separate purposes is seen as obsolete and suspicious.

At least with hard-token 2FA technologies such as FIDO U2F, services you access with that key cannot correlate it with other services accessed with it (by design).


You're missing the biggest vulnerability. SMS means you're tied to a phone company, which has a tech support line staffed with people who's main job is keeping their call times down. It's shockingly easy to socially engineer them into sending a copy of your SIM to some random address and completely defeat the 2FA on your system.

And once they have your texts, getting a CSR to reset the password on all of your important accounts is super easy. By far the biggest security vulnerability on major services is the customer support representatives.


SMS messages are trivially interceptable remotely using SS7 vulnerabilities. These capabilites are sold off-the-shelf. Suggesting that SMS is even remotely secure is a very dangerous idea.


But this isn't a guide for everyday users. This is a standard for government agencies to comply with. The very people who those weaknesses in SMS will be used against.

It is entirely appropriate that the NIST and Governments lead the way in information security as they have the biggest threat landscape. Therefore they should be the ones to constantly raise the security bar, and lead the way. In many ways that has been the saddest impact of the Snowden leaks is that the Government has abandoned that philosophy. That no longer can government recommendations be accepted in good faith.


What you're describing is a UX problem that Google and Apple could easild solve, using the phone camera to scana QR and call some URL. I think that for the avg user that would be simpler, and in terms of security it would be better.


I don't think the social engineering/sniffing is the real problem. From what I recall the signaling system they use (SS7) is just a shitshow and everybody with $1000 can buy access somewhere in eastern Europe and send/receive all sorts of SMS.

At least that was my impression a while ago. That might be completely wrong though :)


On the mac/iOS platforms, SMS is not really 2FA since text messages land straight in Messages.app, as Apple forwards the SMS onto iMessage. Granted, the phone needs to be nearby but it doesn't need to be unlocked.

Should we call that 1.5 Factor Authentication? :)


> While it is vulnerable to social engineering attack (and sniffing if you are near the receiving phone),

And anyone with SS7 access.


This is the perfect being the enemy of the good.

They should be calling for secure, validated SMS.

Thinking that "Joe and Jane Six-Pack" are going to use Google Authenticator, is frankly laughable to anyone who does end-user support. But everyone understands "get a text and enter the code here"


The problem is - none of the Telcos have any profit motive to provide secure, validated SMS.

For _them_ easy phone number porting, customer service reps being able to "fix" a paying customers message problems, and making it as easy as possible to have their customers send and receive more SMS messages are all directly bottom-line positive things.

Making any of that _harder_ for their customers will only reduce their profits and increase their support costs - at zero benefit to the Telco.

Your bank or ISP or email provider's security is not the Telco's problem - and they can't be expected to invest effort into it on behalf of non-paying 3rd parties...

This is what my local Telco Alliance told the banking industry here in .au back int 2012 (and 've kept it bookmarked ever since for all these discussions...):

"Stanton told iTnews that the telcos have decided not to extend the security mechanism protecting the mobile number portability database for reasons of competition and database performance.

Apart from making the porting process more time-consuming and less convenient for hundreds of thousands of Australians every year, additional ‘security’ may be seen as a tool to lock in customers, hinder number portability and thus be deemed to be anti-competitive," he said"

http://www.itnews.com.au/news/telcos-declare-sms-unsafe-for-...


If telcos can't do it, senders can switch to Whatsapp when possible. And everybody is able to understand Whatsapp (although the delivery isn't reliable). And that may even give them more information about the profile of the user, and that could be billed by Whatsapp as a service to senders.


Sure, but at the loss of the ubiquity of people capable of receiving SMS - Googling suggests ~4.5billion mobile devices worldwide, but only ~1billion Whatsapp users (a number high enough to surprise me, but still under 20% of the total potential market for SMS 2FA...)

It also introduces yet another 3rd party reliance and avenue for attack - Brazil and Turkey have blocked Whatsapp recently, and India and the UK have discussed it as well. I doubt Id want to rely on my Whatsapp 2FA tokens arriving in China either...


Does WhatsApp have any kind of API for sending messages to their users?


Yes, they do.

Almost all the newspapers in Germany have WhatsApp newsletters, and you can get TV news as video message every hour via whatsapp, and so on.


They all use third-party service to send those messages through actual WhatsApp clients with real SIM cards (I think each serves around 500 recipients). They also sometimes get blocked by WhatsApp for spamming, loosing customers subscribed to that number. Some examples are https://www.whatsservice.eu/ and https://www.whappodo.com/

WhatsApp announced some API for those use cases though.


Agreed. The choice isn't between SMS and TOTP for most users. The choice is between SMS and just a 6 character reused password (maybe an old pet name with an exclamation point on the end for extra security ;-)).


> maybe an old pet name with an exclamation point on the end for extra security

Nope, this is the answer to the recovery question ;-) which amounts to a password anyway. I wish recovery questions would just die finally.

A pattern I've seen often is people not remembering their password and just resetting it via SMS each time, making SMS 1FA. Although very real, taking the real-world risk of SIM cloning is pragmatically still better than reused, ridiculous passwords and/or ones that end up in leaked lists which amount to no auth.


100% agree. Several products that offer two-factor auth have data to support the fact that accounts with SMS-based TFA enabled are compromised at a substantially lower rate than those without it.

TFA has been empirically proven to be effective, why is this recommendation being made? I can't find the answer in the article or the Github.


I'd suggest that is because there are enough low hanging fruits (single factor password based sites) left to attack.

Phone 2FA is, to me, a bad idea as SMS was never designed as a secure transmission and there's a number of known unfixable weaknesses as a result

1) many OS's are allowing SMS to be viewed on the user's computer. so a standard malware attack can get both the password and access to SMS

2) Web sites exist to provide access to a users SMS messages for a number of providers. So an attacker who compromises the PC gets access to SMS messages as well.

Whilst app based 2FA (e.g. google authenticator) isn't perfect, it's better than this, and should be what companies are aiming at in 2016...


Moreover, did you ever try to port Authenticator data from one device to another? There are rumors it's possible. I work in the industry since forever, if anybody can be called qualified for such simple task, it's me. I gave up, too much trouble. Imagining that a regular person would even think about getting into these woods is laughable.

Sure Google allows you to port authenticator data with an easy 5-step process. Almost nobody else does even this.

Without portability, it means losing access to your Facebook, Instagram and Pokemon Go when you change your device? People would revolt if you do that.

So what's the alternative? We either use SMS, or we use email (which will have like order of magnitude higher failure rate with no added security) or we don't use 2FA at all. Or we think really hard and invent better 2FA than SMS that works on every mobile device and is simple for the user. Then we can deprecate SMS.


I always refuse to use the "scan QR code" thing, and everybody I've tried that with (at least Google, Amazon, Github, Dropbox, Linode) give you a TFA secret to type in as an alternative - I then store these in 1Password and can back that up and use them to key Google Authenticator on additional devices. (I've never tried to extract or backup.reuse secrets from Authenticator.)


In 1Password premium, you can put the secrets directly as TOTP in a login item (on your phone) by scanning a qr or entering the secret. Then 1Password will generate the OTP for you. It then also works nicely in the desktop browser.


This only works for services using TOTP mode; HOTP prevents replay/cloning attacks.


The HOTP counter is something you can increment yourself if needed when storing it somewhere?

Proper implementations of TOTP do not just rely on expiring the codes. From chapter 5.2 of RFC 6238: "Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP."


Yep, right at the top of page 7 of the RFC: https://tools.ietf.org/html/rfc6238

If it accepted the same token more than once, it couldn't possibly be called a "one-time password".


While it makes it a bit insecure (as I know they must store the data), using Authy as an alternative TOTP client makes for easy syncing.


Thank you, I will try Authy, maybe this will make sync problem better (I now have about 10 2FA accounts there and if one of my devices dies and has to be replaced it'd be so annoying).


That's why I use Authy, because I'm scared the data will be nontransfereable.


And you can be sure Authy is secure because it uses SMS to confirm the identity of the user before the client can download the passphrase protected database!

Oh wait, what was this article talking about again?

That said, Authy is pretty convenient for most users as far as backups are concerned, and I'd imagine its at least as secure as storing the database in iCloud/Google Drive. They at least do ensure two factors (albeit a soon-to-be deprecated SMS factor) to get the raw data.


I store mine on a YubiKey. I only need any NFC capable Android device and the app that Yubi provides and I'm all good.


Titanium backup works fine if you have root.


Right, except that means rooting every one of your devices, which is a) annoyingly time-consuming and b) not available for many less-popular devices since nobody cares and c) way beyond the skills of the average user.


Do you go through more than one phone per year?

For my phone, at least, I can get a program that does all the rooting for me with a click.


> They should be calling for secure, validated SMS.

Does such a think really exist?

More to the point wouldn't adding an (optional) standard push notification API to TOTP clients be a better solution. You login, your phone pops up a notification, you hit accept on the notification, done. Way less annoying than even SMS.


The Microsoft Account app does this when an MS app sends an additional challenge. I'm not entirely sure how secure it is but it sure beats looking at a code on GA or Authy.


2fa via the Google app (not authenticator) does something like this. Login on computer, prompt appears on phone, tap yes to log in.


More to the point wouldn't adding an (optional) standard push notification API to TOTP clients be a better solution. You login, your phone pops up a notification, you hit accept on the notification, done. Way less annoying than even SMS.

How would that work when you're trying to login on your desk/laptop?


Surely "Open the BankCo app on your phone and enter the code" is just as simple.

For banks, for example, I already have a banking app on my phone (which was originally authenticated via, ahem, SMS), so they could very easily put the OTP generator there.


That's not going to happen, internationally.

Secure to-device messaging over IP would work. Perhaps if you narrowed it to authentication the telco providers wouldn't see it as a threat to the very, very profitable SMS feature.


As someone who travels SMS sucks for authentication. Maybe most people don't travel but I suspect once they do and wind up unable to access their accounts would not be too happy


I used to travel a lot, but even my cheap prepaid (German) SIM card had reception in most of Asia, and I haven't had any trouble with SMS 2FA. In the worst case, I've had to swap my SIM cards for a minute to receive the token.

It was a bit of a hassle, but not enough to be a showstopper.

I wonder how this is implemented - when Apple sends me an SMS 2FA code, do they pay extra because I'm abroad?


No, you pay extra https://www.att.com/shop/wireless/international/roaming.html

That's mainly a texting fee since that only gets you unlimited SMS, not data or voice. If you don't get the Passport plan in advance, sent texts go from free to 50 cents each.

When I travel Europe, when I'm in the country that issued the SIM in my phone, sending texts are maybe 3 cents, if I leave that country they're maybe 9 cents. Receive was always free.


How about PKI secure data networks like... idk, the Internet?! Google and Apple already provide these mechanisms. Couple it with Authy's REST API and you're 1) secure and 2) in business.


One of the biggest weaknesses of SMS 2FA that I didn't see the article cover is when an attacker can socially engineer their way into your account with your cell service provider.

I'm thinking of a high-profile example when an attacker tried to take over h3h3's YouTube account by requesting his SIM card from T-mobile by pretending to be a T-mobile employee: https://youtu.be/caVEiitI2vg


The other day I forgot my Github password. When I went to go through the password reset process, it must have triggered the 2FA because it asked for my code. I use Google Authenticator, but I had switched to a new phone since the last time I used GA with Github, and never scanned the code on the new phone.

So now I'm at an impasse. How do I get the code? Well, Github has a backup -- it will SMS the code to your phone! When it said this I just kind of chuckled to myself as I also had seen the h3h3 video. Sure enough, it texted me the GA code and I got back in control of my account.

Github actually provides a list of emergency codes that you can print out and use as a last resort. I had printed these before and actually had them available, but forgot about that process.

Github is trying so hard to have your account secure, but yet the SIM card cloning threat is still there.


Hint: don't just scan the QR codes on one device, switch to the "type in the TFA secret" mode, and store that in your password safe (this makes it easier to add the key to all your devices too - I have thew Google Auth app in two phones and an iPad. I'd advise against doing that without at least considering something better than a 4 digit pin unlock for your devices).


Hint: don't just scan the QR codes on one device, switch to the "type in the TFA secret" mode, and store that in your password safe

I just don't use an authenticator app at all. Some password managers (e.g. 1Password) have support for storing TOTP. So, as long as I can access my 1Password vault (use a strong password!), I can access my TOTP codes.

Besides that, I prefer U2F, which is supported by GitHub.


> switch to the "type in the TFA secret" mode, and store that in your password safe

Oh that's a great idea! Never thought of that, thanks for sharing.


I had the new phone Google Authenticator lost data problem too. I use Authy now. It is attached to your email and phone number so you can login when you get a new phone


There was an update to the GA app a year or two back that screwed up the saved data and lost a lot of people access to their stuff... Google's answer was "Sorry, our bad. We'll have a new version of the app out that doesn't do this in a few weeks or whenever we get around to it, but all your lost stuff is gone. Soz..."

Protip: Don't allow your TFA app/hardware to be a single point of failure. Don't upgrade your reserve TFA device/apps until you're 100% sure the upgrade on your primary TFA device/app has worked smoothly.


I don't understand the downvotes.

Anyway, I have one time codes for all accounts I use 2FA with. Google generates these one time codes as TOTP substitutes, LastPass generates them as a one time master password that's TOTP exempt. Amazon you have to send an email and they'll call to verify and then unset 2FA on the account.


Criticise the mighty Google, and you'll be forced to pay dearly with meaningless internet points ;-)

(It's a little telling that none of the downvoters attempted to refute any of the facts…)


Authy stores your TOTP accounts, so you can sync up using a new device.


I suppose if you're a high profile target it's safer to not use 2FA and rotate your password on a frequent basis.


No, it is not safer to not use 2FA. That SMS is easy to hijack does not mean that password+SMS 2FA is weaker than just a password.

It's important to separate out two separate things that we've seen happening - and the media has done a bad job distinguishing these two things - 2FA and account recovery.

If you use SMS 2FA, then to gain access to your account someone needs your password and to hijack your phone number. That's harder than just having your password, but perhaps not much harder if you are a prominent target. The advice I would give to popular youtubers and streamers would be to have very strong passwords using a password manager, and use a TOTP app for 2FA.

What most of the news stories have been about, however, is not 2FA but account recovery. If an attacker can gain access to your account using _only_ your SMS number then you do not have 2FA: It's 1 factor authentication! A lot of websites do a bad job of explaining why they are asking for your phone number - there are competing aims here, to both add security but also ensure you can still gain access to your account - but if you are a high profile target you should take care of the latter (access) yourself, and _not_ enable a backup phone number for account recovery purposes.


Using a burner phone number might also help, to port it to another provider they would have to discover your fake registration details. Though I wouldn't say that number would be impossible to extract from tech support ("Which number did I register with? Was it 2302 2489? No? Dang, it must have been a work cell phone, can you give it a call? No answer?", et cetera).


The problem with 2FA apps is that they don't also serve as an instant notification you when someone is trying to log in as you. 2FA SMS does. This needs to be addressed somehow before we declare the former superior.


Instead of SMS, wouldn't email notifications suffice? Apple (iCloud), Gmail and Salesforce does this when there's a new login on a new device.

Furthermore, I'm not too in favour of using SMS... I have two numbers and when I don't have both phones with me, it's a huge hassle. I end up setting up my phones to auto forward such smses.

I use 1Password OTP support and love how it works seamlessly across my phones.

(Edited for clarity)


When my Origin account was hacked, I found out that hackers used a very basic vulnerability in Gmail - they've logged into my Origin account, changed the language to Russian, and then changed the password - I received the "your password has been changed" email, but because it was in russian, gmail automatically put it in Spam folder and I never saw it(when I eventually found it the message shown by gmail was "this email is in a different language than used normally for this email address so we've automatically marked it as spam".). Obviously by the time I realized, the "I didn't do this!" link in the email has expired and I had to call EA to recover my account(surprisingly, I did!).

So yeah, now I have 2FA enabled on my origin account, but I still wish I received a text message telling me my password was changed.


> Instead of SMS, wouldn't email notifications suffice?

Maybe? Email requires a data connection but SMS can reach more places on more phones in worse conditions. I mean sure if you have a terrible or no internet connection then you won't be able to address it anyway but SMS at least in my anecdotal experience has given me much better notifications than email (occasionally I've had issues even with my Nexus 6P where I have to manually refresh my email).


This is what Twitter has been doing for me. For whatever reason, I get logged out when I restart my browser and they send me an email each time letting me know I logged in.


Microsoft Authenticator had this facility, the last time I used it. Instead of using 2FA; it popped up a notification on my phone, which I could then approve or decline. But you can have your mail configured to send email whenever there is a login attempt.


I use Duo Mobile for some accounts; it supports push. Definitely nicer than rushing to type a number in before the timer expires :)


There's a few minutes' slack so you shouldn't need to rush.


That is up to the website implementing the 2FA check. We only have tens of seconds slack.


definitely recommend duo push. you get the notifications, the multi-device support, and it's really easy to integrate into lots of things.

big fan


Several mobile 2FA apps come with the platform's native cloud messaging support for push notifications; is that not sufficient?


I would love just a push notification I can open and get the 2FA code instead of unlocking my phone, finding authenticator etc.


2fa via the Google app (not authenticator) does exactly this. Your phone pops up a notification when someone tries to log in.


There is more than 1 way to do 2FA apps. I'm a big fan of push-based authorization like Duo Security does it.


The O365/Azure app does this, but using it doesn't meet other NIST requirements.


When I think of NIST, the first thing I think of is the old National Bureau of Standards (now NIST) WWV Time and Frequency broadcast on 2.5, 5, 10, 15, 20, and sometimes 25 MHz. (You old-timers can probably hear the radio voice already!)

This came to mind because I just read a great PDF with a detailed history and technical description of WWV and its sister stations WWVH and WWVB:

http://tf.nist.gov/general/pdf/1969.pdf

Not directly related to 2FA, of course, but that PDF is recommended reading. These people were hardcore hackers before any of us were born!


The suffix of my amateur radio callsign is WWV. A few decades ago, when I actually talked on the radio, there would always be somebody who would ask me what the time was.

Ironically/coincidentally, nowadays I run several stratum 1 and stratum 2 time servers.


At the tone...


> 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

Is that possible to do this reliably in any country right now? I know you can easily migrate numbers and the oldschool block assignments don't mean anything in a few countries.


I moved out of the country and depended on my number being on Google voice to use existing services. I'm also curious how to check if a US number is associated with a VoIP services.

I worked for an international Telecom whose SMS gateway would just broadcast messages to the two other national providers if the number wasn't there's (the other providers would drop messages that didn't belong to them). That was one of my first assignments; writing a task that would check the ported number database and only send the SMS to the correctly ported provider.


I really think this is a terrible guideline. While I understand their concerns, there are plenty of people for which a VoIP number is their only number. Kinda just leaves them out in the cold there.


You can do a fair job with this through number portability lookups; there's a per lookup fee though (although, if you're going to send an SMS, you're paying per message anyway).


Github repo for the working documents: https://github.com/usnistgov/800-63-3

Issue tracker (discussion/request for comments): https://github.com/usnistgov/800-63-3/issues


> "...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."

Now this bothers me. I deliberately use a service (RingTo, discontinued for new users) to park a handful of numbers and be able to exchange SMS and MMS with them. One of the things I do not do is give out my actual mobile number to every random web service that wants it for "2FA," primarily because that now opens me up to even more phone spam. With RingTo, I just set that number to always go to voicemail but am still able to use SMS through their app.

It is arbitrary to say "one number type is acceptable for SMS verification but another is not." I'm actually more concerned that my mobile carrier will cough up my account to an arbitrary attacker than I am about some out-of-the-way number parking service that I log into using credentials that are not able to be easily discovered (an alternate e-mail address and such). My mobile carrier is a much larger target and has scores of fallible humans working for it just waiting to be socially engineered.


I agree. Namecheap currently only supports SMS 2FA. I'm abroad with a local sim in my phone so I registered my Google Voice # with them. It would really suck if I had to carry my USA sim at all times and swap it anytime I wanted to login to those accounts.

Ideally they'd support the standards so I could just use one of the many standard OTP apps


Same problem. Don't know why namecheap doesn't support 2FA app like FreeOTP. Would make it so much simpler and more secure at least.


They've been promising to implement a better 2FA option for ages. I just got tired of waiting and moved to another registrar.

It's a shame because in general, I've never had any problems with Namecheap.


It's about time. Phone numbers change too much to be used as part of a reliable 2FA. You go on a business trip or a vacation, you of course get a pre-paid SIM card with a local number in your country of destination. It's simple and straightforward, most airports are lined if kiosks of vendors. But then you can't access any of your services. You can't do your work. 2FA should be based around something that isn't tied your location and doesn't change so regularly.


For international travellers, I imagine its a problem. Within a country - it is less a problem. In india at least, we have number portability between providers, so there is little reason to change your number.


Good riddance. I live in a basement. I can't tell you how many times I've been scrambling to log into a service that only allows SMS-based 2FA, requiring that I then run upstairs or outside, waiting for my phone's signal to get strong enough that it will receive the SMS, then dash back down before the code expires.


I'm curious, do people still consider it "two factor authentication" when you have a mobile device generating (or receiving via SMS) one-time codes and that same mobile device syncing passwords?

For example, if your web browser or password manager is syncing your passwords to your mobile phone, and that's the same phone the SMS codes or TOTP app runs on, is this completely circumventing the whole concept of "two factors"?

Asking for a friend, because I'm sure no HN readers would be dumb enough to do this...

(also, The Register covered this same story yesterday, here's my dupe submission: https://news.ycombinator.com/item?id=12157529)


See wikipedia:

> Multi-factor authentication (MFA) is a method of computer access control in which a user is only granted access after successfully presenting several separate pieces of evidence to an authentication mechanism - typically at least two of the following categories: knowledge (something they know); possession (something they have), and inherence (something they are).

So as long as your phone is sufficiently password-protected, that is is still 2fa.


So a laptop or phone with a fingerprint reader and TOTP app would qualify as well I suppose. I think many people assume that two separate devices are necessary for proper security, and I wonder if this is true?


Yes, it would qualify. While having additional devices does increase security (harder to break into both the laptop and a phone, or laptop and smartcard/yubikey/RSA SecurID token) its not entirely necessary.

Many physical security systems utilize multiple factors of authentication for access that are tied into a single reader. They often have a badge reader (something you have) and a fingerprint/eye scanner (something you are) or a PIN pad/digital combo dial (something you know) all built into the same device stuck on the wall. Sometimes they'll use separate systems for this, but the combo units are very common.


Another thing to remember is that you're still preventing someone from just storing your entire auth request and replaying it later. The one-time password changes every time, so although they might get a password in transit they won't be able to generate future one-time passwords. They would still have to have that thing you own (the OTP secret) and the thing you know (the password).


I love Google Auth, and SMS really does have security problems, but you need a 2FA method for dumb phones, don't you? Are there Java apps for it?


Or a hardware token. It doesn't have to be a software token running on your existing phone.

That being said, several companies [1][2][3] have in fact made software authenticators that run on J2ME.

[1] https://guide.duo.com/j2me

[2] http://www.aradiom.com/SolidPass/2fa-OTP-security-token.htm

[3] http://www.eset.com/us/products/secure-authentication/


> Or a hardware token

The trouble is with the user (the user is always the problem). What happens if they lose their hardware token? You must have a way to recover that is not exploitable by bad guys but usable by the good people just trying to get back into their account.

SMS fills this pretty well despite its security flaws. I'm not convinced hardware fixes this, at least not in any current form I've seen.


My bank gives out hardware tokens. It's super easy to use, and I trust it way more than using SMS, even though they tried to push me over to using SMS (probably cost cutting move on their part). When it gets lost, they can replace it.


That sounds like a pretty miserable user experience though. People are forgetful and lose things. Doing something online for the ease of it only to have to wait for something physical seems like a big step backwards as far as UX is concerned.

Until you make good security dead simple it'll never be used by the majority.


I agree. I have an old 'dumb phone' and I appreciate that I can use 2FA without a fancy Android app.


I never investigated any of them but there are J2ME implementations of TOTP.


> J2ME

Now that's a name I've not heard in a long time.


Yes, and also for PalmOS, webOS, Maemo, Openmoko and more.


One possible impetus is the rise in SMS phishing like this: https://twitter.com/maccaw/status/739232334541524992

How do you verify that the SMS is really from your service?


> How do you verify that the SMS is really from your service?

The way the phone system works I don't think there is an actual way. It's inherently insecure from multiple angles. Unless there is a way to verify it, reliably, that I don't know about but I tried looking into this before and found essentially nothing useful.


The problem with 2FA is that quite often it will turn into (a weaker) 1FA when users gets a possibility to restore their primary password by the SMS.


Wouldn't PUSH notifications over the Google and Cloud networks resolve this? I know Google Prompt and Authy do this already because of SMS. Authy posted this a couple weeks ago: https://www.authy.com/blog/security-of-sms-for-2fa-what-are-...


Interestingly, when you sync a new device with Authy, one of the options to verify is SMS.


IIRC, Authy uses this SMS challenge to authenticate users to allow you to download the database of secrets. This db is encrypted by a passphrase which never leaves the device. So, Authy is using SMS as one part of a multi-auth system to get to the final unencrypted data.

That said, anyone with a SIM card able to get messages for your phone number can download the encrypted database and attempt offline passphrase recovery. It might take a while to brute force, they seem to use a lot of hashing rounds as it takes a couple of seconds to verify the passphrase on a 2014 Moto X.


It's annoying in a lot of services I can't use my google voice number to authenticate.


Reading through the draft, the level-2 authentication and upwards (AAL-2 https://pages.nist.gov/800-63-3/sp800-63b.html#sec4 ) spec is encouraging. NIST is encouraging eliminating the password and fully embracing cryptographic authentication (like SSH public-private keys).


The biggest threat that other people have mentioned is using social engineering to get a new SIM card that works with your telephone number. I have a google alert for "sim swap fraud". It's oddly under-reported in the US, but quite common everywhere else. How bad is this?? Well, what if at attacker obtained more information about you (ie security questions possibly obtained from a keylogger), then was able to get your phone number, then contacted your bank or other investment broker and drained your accounts? Yes it happens- all the time. It's about time that NIST declares this form of 2FA insufficient. Hopefully the rest of the world will take notice, soon.

I prefer OTP... hopefully there aren't any other RSA-type hacks in the future.


What's wrong with SMS to virtual number? I mean how it's less secure than regular number?


Coinbase, too hasn't gotten the memo yet.

https://community.coinbase.com/t/can-i-use-google-authentica...


In South Africa, this scenario is becoming a big problem: A victim's cell phone, in their possession, is triggered to go into no-signal state which is sometimes not noticed for hours. During this time, criminals are somehow able to capture communication that would have originally gone to the cell phone. Communication like 2FA passwords. This is then used to transfer money out of the victims bank account. How can 2FA over sms be considered safe if this is possible?


It's fine that there are flaws with using SMS, but the alternatives -- proprietary apps, proprietary dongles -- aren't any better. They also just create more parties you have to trust.

And if it comes down to using public/private keys, there's no reason an open source SMS app couldn't authenticate encrypted text messages or something.

If SMS in the clear is bad (and it probably is), then whatever is okay needs to be broadly accessible, open, and usable.


«It's fine that there are flaws with using SMS, but the alternatives -- proprietary apps, proprietary dongles -- aren't any better. They also just create more parties you have to trust.»

TOTP and HOTP are both open OATH moderated standards. You can use any app or dongle of your choice with any provider that follows the standards. This is a way better alternative than SMS.


Here's a story about a friend whose phone number was hacked in a banking Trojan attack: http://williamedwardscoder.tumblr.com/post/24949768311/i-kno...

In this case it was a land line, but it's still a relevant empirical data point for those weighing options.


The list of drafts and request for comments on a range of topics can be found here: http://csrc.nist.gov/publications/PubsDrafts.html

Other than the SMS-based 2FA work, see: - Identity and Access Management for Smart Home Devices - Multifactor Authentication for e-Commerce: Online Authentication for the Retail Sector


So what exactly is the alternative? I should carry around a physical security token with me for every single account I ever made?


Get U2F FIDO USB key (https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3...) [standard, works with Chrome & Firefox for Google, GitHub and more] and/or install Google Authenticator on your smartphone [works with anything supporting TOTP].


Any 2-factor auth is better than none.


I'm somewhat surprised NIST is using github (a private company) rather than self-hosting.


Does anyone have any experience of using hardware tokens (like the sealed key-fobs) running TOTP?

For some services, I would much rather have a key-ring-ful of these devices rather than an app on my phone which I also use for reading websites.


I use a mix of

- Google two-factor

- Service-specific two-factor (e.g., Steam authenticator, which provides other features beyond TOTP)

- Non time-based authenticators; Yubikeys are great, and appear to be made of some indestructible material that survives multiple trips through the wash.


Eventually the government will issue identity cards with certificated key pairs.


My bank uses SMS based 2FA. I'll send them this link and reiterate they should support U2F, or at least TOTP supported by Google Authenticator.

If SMS is problematic for 2FA, why isn't it problematic for account recovery?


I never used SMS 2fa because I don't want my phone number out there.


And still in "secure" messengers like Telegram SMS is primary authentication method, not even secondary for 2-factor. Despite documented cases of account hijacks this way.


"For now, services can continue with SMS as long as it isn’t via a service that virtualizes phone numbers"

How much of an affect will this have on companies providing such a service.


I failed to find in the article the reason why it's frowned upon, are there reasons published in the guide?


The headline seems a bit click-baity. It seems to merely add some suggested guidelines to how this is done.


If SMS is out, any form of verification or identity tied to phone numbers should be too.


> To avoid red tape, the Institute is trying out a new method for reviewing and commenting on the guidelines that isn’t quite so official: GitHub.

Ironically, GitHub uses SMS-based 2-factor authentication...


Or alternatively authenticator based 2FA, which is their suggested way.


Or alternatively U2F, which uses a dongle and is phishing-proof.


It uses both SMS and software tokens.


I will never ever use 2FA if it's not via SMS. I just don't care enough to be bothered.


You've never had anybody try to seriously take over the email account you manage domains names with, have you?

(Try owning a domain name with the word "anonymous" in it, and watch the skript-kiddies descend en-mass...)


Well, I didn't (I'm not the OP). I host my own e-mail myself.


I've been forwards and backwards on that one myself many times...

Do you seriously think you're more capable of securing your mail server than Google/Microsoft/Apple?

Is the time/effort you'll spend maintaining it worth the privacy tradeoffs?

How are you dealing with outbound mail? Where are you hosting your email that isn't already on half the spam blacklists already?

(That last one was the killer for me last time I ran a mail server of my own, neither my home ip address, nor any of the Digital Ocean/Hertzner/Linode/AWS vpses I could easily use/afford to make outbound mail connections with were ever trusted by the big email providers. A self hosted mail service that couldn't reliably get mail into the inboxes of 80+% of the people I correspond with didn't end up being of much use... I've ended up back with Gmail and hating myself for it.)


> Do you seriously think you're more capable of securing your mail server than Google/Microsoft/Apple?

I don't know about Apple, I stay away from them.

I also stay away from Microsoft, but I had to go through some of their products in my time, so there's good chance that I'm more capable.

And Google? Extrapolating how they interact[1] with the rest of the world, it's not improbable, too.

[1] Did you know, they were a source for backscatter for several years?

> Is the time/effort you'll spend maintaining it worth the privacy tradeoffs?

Wrong question. The correct one would be: why would I give up access to server logs (yes, I use them sometimes) just to give up my privacy on top of that?

> Where are you hosting your email that isn't already on half the spam blacklists already?

In a place that is not a known spam source? (Yes, this excludes AWS and Digital Ocean.)


>In a place that is not a known spam source?

Examples? Shall we take turns guessing the names of these elusive spam-free providers? Your non-answer reads to me as, "Just don't use any providers that you can actually afford, and you'll be fine!"

(Sorry if this comes across as grouchy--I can't sleep, and I have to get up early tomorrow.)


Well, there are smaller companies with own server rooms that offer VPS-es.

I use one in my country (Poland), and I use it since a little longer than Amazon entered our market. I don't think such a regional provider would be of much use to you, unless it operates in your region, of course.

What my comment boils down to is to avoid big hosting places.


Using proper DKIM/SPF goes a long way in getting your emails accepted by the big providers these days. That + TLS and you're probably going to make it through even from a DO VPS. From what its worth, it seems to me like a lot of the email servers that don't pay attention to DKIM/SPF are also the ones that don't bother worrying about IP blacklists, so even if they don't bother checking you've got a decent chance of making it through, but YMMV.


Not the previous poster, but I run my own server too. I don't think I can secure it better, but I don't think I have to; it's secure enough against automated scanners, and I'm not worth the effort of a manual attack by someone who knows what they're doing.

As for the time, after setting it up and later configuring DMARC, I don't ever touch it. And despite not having almost any volume, I've never had problems getting received by Gmail (though, to be fair, most of my outgoing email are replies, which might help).


The double-speak and quack-speak is getting a little thick for me lately.

Government bodies frown heavily on end-to-end encryption, but also frown heavily on authentication methods that are less secure.

Why, whichever directive shall I adhere to? The more secure behavior or the less secure behavior?

Maybe I should just do whatever benefits everyone else but me.


I don't think it's fair to group all government bodies as one entity. The FBI may frown heavily on end-to-end encryption because they want to be have access to everyone's messages, but that doesn't mean that NIST isn't still trying to make everything as secure as possible.


Police and security services are just one part of government. In the US, we're in an "encrypt all of the things" phase in most places regulated by the Feds. NIST stuff is pretty good, and is the basis for most of the mainstream security standards.

The government plays a weird dual role. NIST gives good advice, but you need to understand what you're doing. Part of that is data classification and risk assessment, which is always art and science.

When they get real explicit about guidance, that means the thing is broken.


Remember this is the same NIST that backdoored the EC coefficients [ http://safecurves.cr.yp.to/rigid.html ]. And before that devised the "explanation" of how WTC7 collapsed. [ http://www1.ae911truth.org/en/news-section/41-articles/927-n... ].

NIST is a political organisation more than a scientific one.

Here come the down votes.


No.

NIST is legally required to collaborate with NSA on crypto. It was widely reported that NIST people fumed about NSA undermining heir standard and they removed the offending crypto from the stNdard quickly.


> Here come the down votes.

Nobody is impressed by your edgy downvote invitation.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: