You don’t need SMS-2FA
blog.cmpxchg8b.com
blog.cmpxchg8b.com
That argument is just nonsensical. If you're a provider, the user being compromised on some other service doesn't really matter (and there's nothing you can do to prevent it anyway). While preventing the compromise protects the platform from abuse, saves on customer support on having to help the hijacked user recover, etc. While if you're a user, obviously it's better to be hijacked on as few (and as unimportant) services as possible.
> Instead, why not simply randomly generate a good password for them, and instruct them to write it down or save it in their web browser?
The users don't know how to save a password in the web browser. They'll lose the piece of paper. They'll be unable to log in, and effectively end up in an eternal loop of recovering their account (with SMS!) every time they log in, and getting a new password they can't remember. If you end up sending the user an SMS anyway on every log in, might as well use the version where you get to use knowledge of the password as a gating factor.
> If we spend all that good will on irritating attackers, then by the time we’re ready to actually implement a solution, developers are not going to be interested.
I'm really not sure what this is referring to. Other than this comment, I thought Tavis was railing against forcing users to do SMS 2FA. But then it turned out that the resource he is concerned about is developer goodwill, which doesn't really make sense.
There are a few classes of developers.
1. Huge companies with security teams that are willing to entirely implement their own authentication systems. Their goodwill is not going to be exhausted, since they're implementing what those teams think is the best for their platform's security.
2. Companies with potentially sensitive data who outsource some or all of the authentication to some kind of identity provider or identity platform. Their goodwill won't be exhausted: they'll just expect the provider to implement whatever the best practice is at any time.
3. Companies that don't care, and just roll their own username + password auth. They aren't going to implement SMS 2FA any more than they would implement U2F.
Yeah I really don't understand their argument here, to the point that I feel like I must be missing something.
Furthermore, the suggested alternatives of U2F, WebAuthn, and FIDO would behave exactly the same! (Excluding perhaps passwordless authentication utilized by the hacked website.)
So this (quite deliberately) renders it immune to credential stuffing.
If your system stores both WebAuthn credentials and a password (e.g. to enable cheap FIDO dongles as a second factor to the password) then the passwords could be used in a credential stuffing attack against other sites. But if you don't store passwords and use WebAuthn to handle both factors (e.g. Touch ID plus physical possession of the iPhone = two factors) then you don't have any credentials that can be used by an attacker, none at all.
The article suggests that if a service provider unrelated to your service uses usernames & passwords, and is hacked, SMS 2FA protecting accounts on the service provider YOU run still does not prevent credential stuffing. The argument that follows this statement is nonsensical: "Well sure, they can't login to YOUR service, but they can login to other ones."
Seemingly this argument advocates the opposite of the suggestion - if you use usernames and passwords for authentication, add SMS 2FA to prevent other hacked websites from leaving your users vulnerable. (Would WebAuthn be even better than SMS 2FA? Yes!)
If I'm not the "hacked" service provider, adding WebAuthn to my service has no additional benefit when a DIFFERENT service provider is hacked (well, aside from removing SIM swap attacks from the equation.)
WebAuthn only changes the situation if you are _the site that was hacked_. But aside from this point, the article seems to discuss the case where a separate service was hacked and passwords were leaked.
I think he's concerned about user goodwill (to comply with "annoying" security stuff).
1. You have a unique, long password with Foo.
2. Oh no! They store your password in plaintext, and their security is terrible, so your username and password are part of a giant data breach from Foo.
3. Before you know about it and can change your password, someone that is not you, who does not have access to your phone, tries to log into the account.
4. While out living your life (or in, these days), you receive an SMS from Foo, and then ignore it.
5. There is no step 5, as no one else is getting in.
6. Okay, fine, you caught on, and now you log in and change your password with Foo, or maybe just drop the account, because really.
It seems to me that SMS-2FA helps in this scenario. Am I missing something obvious?
I don’t fully buy the argument, but he didn’t just ignore this.
More valuable, I think, is the claim that we only get so much bandwidth to educate users and that spending time educating people on unique passwords is more effective than working on sms 2fa.
This is from infosec/opsec awareness training experience I get paid to provide. Not all users are lazy, mind you, but enough to be emotionally depleting. Incentives matter.
There's a suggestion here in the article: don't let users pick their passwords. Just generate one for them and say "use your browser's password manager or write it down".
A sticky note password attached to the screen creates another password sharing problem.
The last company I trust with my secret password is my browser. One hack away from exposing everything. That's like bring all of your important documentation with you wherever you go. If you are robbed it is better you don't have your bank code attached to the card.
Using cheap FIDO USB dongles is "I forgot it was there" easy, you have to tap the button or touch the metal contact surface or whatever on your dongle when you sign in, it becomes a reflex, you stop thinking about it yet now you're authenticated and bad guys aren't.
The touch ID style behaviour in a newer Pixel or iPhone likewise, that's probably already how you unlock your phone without really thinking about it, and now it can unlock a web site.
Even the OpenSSH FIDO integration feels lazier, yet more secure than having to use a local password for your keys. Some non-trivial number of people have no password or set it to something easy because it was annoying, the resulting risk (malware exfiltrates their unsecured private key) vanishes instantly if you give them all FIDO dongles and require that login method.
If you create the password for the user they can't reuse it and thus no credential stuffing problems.
You are. Tavis discusses this clearly and offers two suggestions for making this more common (educating people about password managers or having services generate all passwords for their users rather than letting users pick them).
If you believe that "everybody uses unique passwords" is achievable then Tavis is 100% correct and SMS-2FA achieves nothing.
To be clear, I'm not talking about credential stuffing. I'm talking about my credentials from Foo being used with Foo.
I personally don't feel like I have enough information to decide whether this is a reasonable threat model or not.
Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated.
One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere.
I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.
The stronger or less guessable a password is, the more likely it is to be written down or recorded somewhere where it could be compromised.
This doesn't seem to follow. As the previous poster called out, if I have unique passwords, SMS-2FA makes me safer than not having it. If someone (let's say Bank of America) has their password database leaked, then an attacked can immediately log in to my account with a unique password.
If I have a unique password + SMS 2FA, the attacker has to compromise SMS to log into my account - a slower process that gives me more time to be informed of the leak and change my password.
Correct. It's possible the entire system is compromised. It's also possible the entire system is not compromised, and the data breach happened without the target institution losing control of their systems.
> since they clearly have breached the system already.
No, not necessarily. Someone could, say, export the contents of a database and put it somewhere public. A data breach is not necessarily the result of hackers getting total control of the target.
No one cares about it, most are people who will never be reading hackernews, who barely know how their computer works, and write down one password on a stickies A taped to their monitor and reuse it everywhere because they are in a hurry to do their actual job.
"If they don't practice good security, why should we?"
The other points would have been stronger if he'd just admit that there is this small advantage to sms2fa. As is, he's making a ridiculous argument in an attempt to make the issue wholly black and white.
It's not necessarily scalable, but sim-swapping[0] is still an unfortunately serious issue. Phone numbers are not proof of identity
If you can make opportunistic attacks fail and require targeted attacks, you still have a big advantage.
Hacker has access to Foo that's how they got your creds. If they want more access they will use the admin account to gather all info Foo knows.
Hacker picks a global service. Paypal, gmail, appleid, godaddy and tries all usernames/passwords.
When they hit 2fa they attempt a code. 99% of times it fails. You get a warning/change the password and get scared.
User receives an email saying that you have beenhacked. They have proof you did something illegal or something illegal has been planted. Send bitcoin here or this video will be sent to all of your friends/work/family.
----
2fa usually locks you when you need it the most (no battery/texts not going through/paid bill latertexting is turned off can cause this)
It should never be the only factor required to reset a password. It should always be an option to disable. (Smaller financial institutions seem particularly to fall into this one, "its for your security.") It should be granular enough to give the customer control of what it can and cannot be used for.
The big thing being missed here is that all organizations should be expected to block any leaked password in the wild from being used. Banlists are rarely used by any entity except the largest. SMS-2FA is a step in continuous improvement, not a destination. It is also being used to either check compliance boxes or as a part of security theater. The hoopla, range, and witch hunt energy should be repurposed to get everybody using password banlists.
The author completely misses the point about the value of 2FA itself. I agree SMS-2FA is not good, but that doesn't mean 2FA is worthless.
If you are happy to use this only as a second factor, the USB key can handle any number of sites without constraint. If you want "resident credentials" where the USB key can sign you in spontaneously (no need to even enter a username or email address) the key needs storage for each such credential, those on the market today hold only a relatively small number, fine for your bank but not for say Hacker News and other forum sites you might join dozens of.
For other application software it's trickier but possible, you can see that OpenSSH did this for example.
(If the service supports U2F)
"Are you trying to log in from Ukraine? If yes, the code is 123456."
"Bank tranfer of 10000 EUR to account XYZ: verification code 987654"
TOTP obviously can't do this.
A main goal of security engineering is to increase the difficulty level for attackers. SMS authentication has demonstrated its ability to do this in a highly accessible, albeit imperfect, manner. I feel that the author severely underestimates the practical difficulties of widely deploying "Unique Passwords and U2F".
I strongly disagree with the conclusion that "SMS-2FA is not only worthless, but harmful" and highly recommend consulting a security professional before entertaining any of the arguments or following any of the suggestions in this article. I don't like leaving negative comments, but this is at best borderline misinformation that has the potential to create severe consequences.
Some more context, if you want to consider a more balanced perspective: https://doublepulsar.com/infosecs-fantastic-fear-of-everythi...
[1] The common HN objection which you alluded to is "but it's so hard!" It's really not. Passwords are hard! If only I could have back all the hours I've spent trying to help my grandparents remember their passwords. I have a U2F token plugged into the side of laptop and nothing could be easier than tapping it to get in. Implementation might be hard, but come on, that's our job.
2-factor as an idea is great, and this author seems very confused.
It’s a one time thing at account creation and should be immediately deleted afterwards.
Real 2FA should be set up afterwards to actually protect the account. A yubikey or even a simple TOTP app is a lot of protection against account takeover. The only big weakness left at that point is the help desk.
This is only very marginally more effective than SMS. Phishing is way more common and can be automated much more easily than SIM-swapping. With TOTP you close a small window but leave the big door open.
Yubikeys prevent phishing, which is enormously valuable.
Google does this well. Yubico Security Key + they seem to monitor my logins / rate limits etc.
I deal as do many folks with relatively to extremely sensitive info (yes, also have stuff on auto-delete).
Complex passwords require a password manager - if those get updated and rooted then my yubico seems to save me again.
In fact, with yubico I have a few passwords I memorized that aren't TOO crazy long - with a 2FA hardware key you may be able to SIMPLIFY passwords and still have good security.
And the yubico is EASY! Clip it to your keychain and go.
It’s an unusual way of thinking about it and I think the weakest part of his argument but it is interesting.
But it is of course question if you are worth their time.
It also is totally unrelated to credential stuffing.
We are not looking for a panacea there. If you're that gullible and your forum account is pwned, no security measures will prevent you from giving up bank details.
For example: "Please go to x url and enter your password" -> user enters pw -> show new form with 2fa code input (and in the background, try logging into their account with the pw supplied) -> user gets another text from the same number, enters in your site -> profit???
Security is only as strong as the weakest link. If you have a "forgot password" that emails you a login or a "lost/changed phone" that removes the sms, don't bother even having the password or sms.
Falling back to email means you've just pushed your auth behind the email's auth. Just use it directly by using oauth with google, o365, facebook or whatever makes sense for your target audience and be done with it. If you are b2b, use saml.
However the section for "If you’re a security conscious vendor..." doesn't make sense. Credential stuffing is so common, and sms/totp is a great tool against it. You could prevent users from setting their own passwords, but that seems a little "too different" from existing sites that it could harm usability.