
You don’t need SMS-2FA - beefhash
http://blog.cmpxchg8b.com/2020/07/you-dont-need-sms-2fa.html
======
jsnell
> Unfortunately, it doesn’t work like that. When a service enables SMS-2FA, an
> attacker can simply move to a different service.

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.

~~~
johnmaguire2013
> > Unfortunately, it doesn’t work like that. When a service enables SMS-2FA,
> an attacker can simply move to a different service.

Furthermore, the suggested alternatives of U2F, WebAuthn, and FIDO would
behave exactly the same! (Excluding perhaps passwordless authentication
utilized by the hacked website.)

~~~
tialaramex
The stored credentials for WebAuthn aren't useful for impersonation. They
consist of an opaque identifier useless except for triggering the verification
on that particular site, and a public key which is... public.

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.

~~~
johnmaguire2013
Maybe I'm missing something, but I think we're in agreement.

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.

------
scott_s
I believe the arguments that SMS-2FA is not effective against phishing. (Or,
at the least, I can't provide a compelling counter-argument.) But I had always
thought of SMS-2FA against a more banal problem:

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?

~~~
UncleMeat
Tavis discusses this explicitly in the article. His claim is that there will
be some other service that doesn’t do this so the user is still vulnerable to
credential stuffing - just not on your service.

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.

~~~
toomuchtodo
Users are lazy. You can educate all you want, they will still use the same
passwords everywhere, or weak passwords. You have to bake the security into
your workflows, processes, and code if you want it to matter.

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.

~~~
UncleMeat
> You have to bake the security into your workflows, processes, and code if
> you want it to 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".

~~~
wolco
All that does is increase the locked account support tickets and drive people
away.

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.

~~~
UncleMeat
You are typing your password into your browser. You must trust them with your
password.

~~~
wolco
I don't trust them to store and safe guard the password.

~~~
FabHK
So you're not using a password manager either?

------
jasonpeacock
He's arguing not just against SMS-2FA, but against 2FA itself, and his simple
solution is to "just use a strong password".

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.

~~~
pkulak
I guess he was trying to specify 2FA that's NOT u2f, or other very strong
options. But yeah, in principal, he's really talking about SMS, TOTP, et all.
Bit of a shame, because TOTP itself is far better than SMS. It's all a sliding
scale of security vs convenience.

~~~
packet_nerd
Except it's not really a sliding scale with SMS being "easy" and U2F being
"hard". U2F is SO much more convenient than either TOTP or SMS. SMS might be a
little easier than TOTP, but with either one you still have to (1) find the
phone, (2) unlock it, (3) hunt around for and open the app, (4) manually type
the code in, often looking back and forth between the phone and webpage 2 or
more times before you get it. Compare to just taping the U2F key with the side
of your finger (assuming it's already plugged in, which is what I do). There's
just no comparison in terms of UX between U2F and anything else I've ever
seen.

~~~
pkulak
Can you use the same USB key for every application you need to authenticate
to?

~~~
tialaramex
Web sites can all just do WebAuthn. The browser will securely manage the
relationship between each site and the USB key ensuring that sites can't lie
to the key about who they are (which would enable phishing).

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.

------
wyc
Yes, it's true that SMS-based authentication has its flaws, but it's far from
useless/harmful in many contexts. The same strawman arguments used here would
also find TOTP "wholly ineffective" which is an absurd conclusion.

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...](https://doublepulsar.com/infosecs-fantastic-fear-of-everything-
why-the-reddit-incident-shouldn-t-cause-infosec-to-throw-4bb3b7ea634f)

~~~
packet_nerd
Regarding the "SMS-2FA is not only worthless, but harmful" claim, it's true,
but only in the sense that widespread "lazy" SMS 2FA deployments stifle U2F,
which, I believe, should just be the standard across the board[1]. Of course
SMS does help, just not as much or in as many attack scenarios (and is more of
a UX pain too).

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

------
hprotagonist
SMS 2-factor is wrong and bad and NIST has been yelling about this since 2016
or before. Simjacking is real and fairly commonly used in targeted attacks.

2-factor as an idea is great, and this author seems very confused.

~~~
jandrese
SMS should only ever be used as a proof of investment. IE making sure a bit
setting up hundreds of thousands of accounts (because they broke your CAPCHA)
needs to buy tens of thousands of real phone numbers with service.

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.

~~~
frei
All the arguments in the post against SMS 2FA are also arguments against TOTP

~~~
jandrese
There is no help desk that can give away your TOTP secret. That’s the big
weakness with SMS, someone buys a phone and asks the clerk to give them your
phone number.

~~~
UncleMeat
It is a publicized weakness. In practice, phishing is scalable and social
engineering isn’t. And humans are shit at detecting phishing attacks.

------
7786655
After multiple experiences where I couldn't log into an account due to not
having a phone signal, I refuse to use SMS-2FA on any service. Given that I
already use strong passwords, the marginal security advantages are far
outweighed by the potential lack of availability.

------
exabrial
SMS 2FA exposes a person's cell phone account to attack, and the carriers
aren't hardened to handle it. Jack Dorsey getting hacked proves how stupid
using SMS for anything. Please, implementing this. Use FIDO U2F or TOTP. It's
not that hard, my 70 year old mother has it enabled and has no issues with it.

------
thoraway1010
I've got the dual yubico key thing going. It seems to work fine. I don't need
to pick overly complex passwords if I don't want to.

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.

------
lostmsu
I did not get the explanation for why SMS 2FA does not work against credential
stuffing. It clearly does.

~~~
UncleMeat
He is thinking of it from the user’s perspective rather than the service. If I
reuse my passwords I still get owned even if some of my services use 2fa,
because others won’t.

It’s an unusual way of thinking about it and I think the weakest part of his
argument but it is interesting.

~~~
lostmsu
Yeah, that basically destroys his argument. If I use the same password for a
random internet forum with no 2FA and my bank account with SMS 2FA, then a
person, who breaks into the forum DB still can not access my money.

~~~
ozim
Problem is that attackers can take advantage of that random internet forum to
take over your bank account. Plant something that you would click because it
is on your account and it downloads some malware. Could come up with more
scenarios probably like they could target someone else from your account and
use trust you have on that forum.

But it is of course question if you are worth their time.

~~~
lostmsu
What you said has nothing to do with SMS 2FA, and has everything to do with
user/their friends' gullibility, which still must be pretty high to click
something on the forum and then also launch it.

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.

------
zachrip
The thing I find odd about sms 2fa is I sometimes get multiple services
texting me through the same short code. Isn't that a security hole in itself?
If a user recognizes a number as the "security number that texts me sometimes"
and I as an attacker know this, couldn't I somehow abuse this?

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???

------
tbp105
I think this misses the point... do you need your own auth at all?

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.

------
frei
The prescriptions in "If you’re a security conscious user..." make sense to
me. If you use a unique password, sms/totp adds very little benefit.

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.

------
freeone3000
Okay, the argument about credential stuffing is fairly weak. 2FA on a given
service makes it an ineffective attack against that service. If you have 2FA
on _all_ of your services, credential stuffing won't work on any of them, so
you're then immume. Moreover, not all services are identical - Email merits
two distinct hardware keys, my Steam account warrants an emailed password, my
BeerAdvocate account... probably doesn't need anything.

------
haecceity
It could be used to deter users from making multiple accounts. It won't stop
determined spammers though.

