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.
> 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.)
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.
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.
Comments
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.
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.
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.
Furthermore, the suggested alternatives of U2F, WebAuthn, and FIDO would behave exactly the same! (Excluding perhaps passwordless authentication utilized by the hacked website.)
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.
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.
This article goes more in depth and answers the questions you bring up https://passwordbits.com/dont-need-sms-2fa/
Yeah I really don't understand their argument here, to the point that I feel like I must be missing something.
I think he's concerned about user goodwill (to comply with "annoying" security stuff).