Hacker News new | past | comments | ask | show | jobs | submit login

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.

Applications are open for YC Winter 2020

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