Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors.
So no, that is not the solution.
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.
- Your solution is not sufficiently great as to be self-evidently great.
- People (i.e. the victim) must be faulted (i.e. blamed) for their inability to be convinced of its inherent majesty.
- Given convincing's similarity and overlap both with educating and with training, you are having a failure of imagination. (Source: Your comment.)
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
Since when?