This is definitely true of TOTP but U2F was designed to prevent phishing attacks by incorporating the hostname in the protocol[1], which means the attacker needs to successfully compromise SSL as well.
However I wouldn't want my second-factor to be attached to my browser. Seems way too volatile for me. Personally I'd rather keep TOTP and be vulnerable to time-of-use phishing.
Maybe if the browser had an OS API that a YubiKey could query...
Just to extend on what jon-wood said, that's definitely the other way around: U2F is an open standard and the intelligence lives on the USB/NFC device. Any browser which implements that standard[1] can login and, especially nice for security, the browser never gets access to the keys or, with devices like the YubiKeys which require you to touch a button for each request, even the ability to authenticate without user approval.
1. Currently Chrome has this, Firefox is close (50.1 shipped it but it only works in the e10s mode), and there are extensions for Safari and older versions of Firefox.
It's actually the other way round, the YubiKey (or other U2F token) has an API the browser queries, generally triggering the token requesting some sort of physical interaction.
I know how it is now, but that's not what I'm talking about. Currently the URL is not included in the hash, that's my point. It could be by having those two talk to each other. Who's the server and who's the client is beside my point.
I mentioned a hash. The secret is hashed together with the time. _That_ hash.
> The crypto keys used for U2F are indeed domain-specific, if that's what you're trying to ask.
I know the secret is domain-specific. What I was describing is taking the secret, and the time AND THE DOMAIN and use them to produce the hash. This would break MITM. One of the comments above me mentioned this and I run with it. But you're talking to me like you didn't read anything above....
Yes, but as per the standard TOTP codes are valid for a window of 1 minute.
TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).
Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?
If the codes are time-based (TOTP), they are typically generated with a rolling window of 30 seconds (as you saw in Google Authenticator). The 30s rolling window is the recommended (and widely implemented) default value from the TOTP RFC [0].
It is common but not universal for sites to accept, at a given time, 1) the current U2F token, 2) the U2F token from the previous window, 3) the U2F token for the next window. This is done as a partial mitigation for potential clock skew issues on the client that's generating the TOTP codes (e.g. your phone). In practice this means every code is valid for 1m30s, although sites may customize this (with or without changing the window size, which is typically not done because that parameter must be consistent system-wide).
> If I wait till the last few seconds before using the code, does that make me any safer?
Maybe, but this is not practicable security advice. The latency of a MITM attack on a 2-factor TOTP login depends on the attack infrastructure and design, but can easily be made to be on the order of tens or hundreds or milliseconds. Reducing the window seems like it might help your security, but it can never be perfect and there is a direct tradeoff with usability because users need time to look up the codes on one device and enter them on another.
Folks often say "enable 2FA" in response to news of new and sophisticated phishing attack campaigns, but it's critical to note that most commonly deployed 2FA (TOTP, HOTP, SMS) is trivially phish-able. 2FA is not an automatic defense against phishing, although some newer designs achieve this and were created specifically with this goal in mind: U2F is a good example.
The RFC recommends a time step of 30 seconds + permitting at most one previous time step for handling out of sync clocks and slow/late entry:
The validation system should compare OTPs not only with the receiving timestamp but also the past timestamps that are within the transmission delay. A larger acceptable delay window would expose a larger window for attacks. We RECOMMEND that at most one time step is allowed as the network delay.
[...]
We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability.
Since the client's clock could be in the behind or ahead of the server's clock, I have to correct myself and the window would be 90 seconds.
One could be a bit strict and e.g. the previous time step only until 1/2-way the current time step, which would bring the window make to 60 seconds.
At any rate, all these timeframes are far to large to avoid real-time phishing attacks.
In some cases the server is configured to accept multiple codes (prev, current, next) to handle timesync issues between server and client (where the app is running).
No. How long does it take from you entering the code to the code reaching Google? A few tens of miliseconds? With a phisher in the middle it's a couple extra miliseconds.
1. https://security.stackexchange.com/questions/71316/how-secur...