Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

2FA absolutely will protect you from a phishing site using the password it stole.

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.



Not all 2nd Factor solutions allow stealing the 2nd factor.

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


> Not all 2nd Factor solutions allow stealing the 2nd factor.

The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)


The article's first and most prominent criticism is that it costs at least $30-$60, which might be a barrier to mass adoption but for most HN readers is not a serious reason not to use it.


I own two (one as a backup in my safe in case I lose this one. They all have the same TOTP stuff and setup in every service side by side where possible), to agree with you. Though it’ll be lovely when your iPhone can be a U2F key through their hardware security chips and some OS support, if I’m dreaming out loud.


Have I got good news for you: https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-... - ICYMI WebAuthn is the successor to U2F.


I do like phones are building in these keys, it makes them way more accessible to the general population, and generally not a pain to use. And then those of us with physical keys get better support too :)


And the third is that they leave their keys in their coat. When I’m at home, I leave my keys (and therefore my yubikey which is on my key ring) on my desk and when I’m out, I always keep them on my person and never unattended.

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.


U2F is so infrequently used on public sites compared to SMS and TOTP. Of the things I use regularly, that arn't for work, that have a 2FA option - I think two (Google, and my password manager) supports U2F.

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.


Yeah, I really wish more things worked with U2F. I especially hate when I enable U2F on a site it works on (Twitter) and then every time I log in it does an sms code anyway, even though I have U2F enabled and would much prefer to use it, but like having my phone number as a recovery backup.


> Not if it also steals the 2nd factor.

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.


> persistent access

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?


> The solution is to go only to the right site.

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.


Well, name one error that persists despite not making the error, and you can definitely say I'm wrong. But that wasn't the point. The solution is to go to the right site. You were supposed to use your imagination to come up with ways that might be caused to happen. The article and commenters here suggested password managers that discriminate between the right site and the wrong site, that's an example. "OH SURE BLAME THE VICTIM FOR NOT INSTALLING A PASSWORD MANAGER!" If you're looking for a solution that doesn't whatsoever require the participation of the user, you may meet with some degree of disappointment.

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.


Actually better education and training is often the only real solution. It isn't "victim blaming" if the situation is at least theoretically within the victim's control. If some random "plumber" that I didn't call for shows up at my house, asking to be let in to replace some of my pipes, and I say "okay", then he robs me, is it victim blaming to say perhaps I should have been more suspicious of strange plumbers randomly showing up at my house to do work?


> education and training is often the only real 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.


If the easy part is the implementation and the hard part is convincing people of its value then I can say one or more of the following are true:

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


The problem is that the people who need to be convinced are not the people who are being harmed by phishing. The people who are being harmed by phishing (non-technically-savvy end-users) are powerless. The people who need to be convinced of the merits of the solution are browser vendors and web site operators. Both groups would need to work together to solve the problem. Getting that to happen is the hard part. It's a very real problem, but it's a political problem, not a technical one.


Explain how any solution prevents the user from opting out of yubikey and typing self-XSS into Dev console to get owned.

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.


> Not if it also steals the 2nd factor.

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.


As phishing usually includes impersonating a website and making the victim believe they are giving their credentials to the original service, I think it is implied that most victims would willfully provide their second factor, when asked for it.

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.


I bought my whole family Yubikeys last Christmas for exactly this reason ... you can't trick someone into a hardware token authentication. Now I tell people to use something with U2F. I find myself using software U2F and include the secret key in my password manager so that I don't need a hardware key from my laptops.


How many websites allow U2F as the only 2FA? Every website I tied it wanted a backup authentication app added.


Normally you can create backup hardware recovery keys (or alternate fallback 2F). (EDIT: Keys as in e.g. alphanumeric on time use tokens lie "23430240392")

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.


I have 4 keys which are stored safely. I do not want a fallback mechanism because that reduces the security of my account. The downside is I have to manage my keys on each site separately. It is a shame that the original OpenID never stuck around as I could have just had one secure account, without having to be part of the current ID provider cabal.


Or perhaps worse, they want SMS OTP to be added as a backup. Even with tons of messages telling people not to share OTPs, it still happens through social engineering.


> you can't trick someone into a hardware token authentication.

Since when?


Well once the authentication token expires, they would need to phish you again to get another 2FA token, so there is that. But that is probably plenty of time to do some harm, and depending on the service, possibly even disable 2fa (although a good site will require another 2fa authentication in order to do so).




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: