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