You can already use the same process on your GMail if you have a compatible U2F key.

Of course, more sensitive stuff (access to production, access to pay stubs, access to $cloud_erp) requires re-entering password plus the security key.

Sometimes 'replacing passwords' is used to mean 'replacing the traditional username and password login' as well.

This is a common misconception. The threat model of 2FA is not "I lost my device, and it is now in the hands of someone who knows the password".

The threat model of 2FA is one of:

1) "An attacker has gained remote access to my computer, but not physical access"

2) "I have been targeted by a sophisticated phishing attack, and I trust the machine that I am currently using"

TOTP (and even SMS) protects against (1) in most cases, though U2F is still preferable. U2F is the only method that protects against (2).

A bit of clarification: U2F protects against phishing attacks by automatically detecting the domain mismatch when a link from a phishing email sends you to g00gle.com rather than google.com, which is something that a human might overlook while they're typing in both their password and the second factor they've been sent via SMS. However, if someone were to use a password manager and exclusively rely on autocomplete to fill in their passwords, then that would also alert them to the fact that something was fishy when their browser/password manager refuses to autocomplete their Google password on g00gle.com. So this isn't exactly the only method that protects against the second scenario above... though I will concede that using a password manager in this way sort would sort of change 2FA from "something you know and something you have" to "these two somethings you have" (your PC with your saved passwords and your USB authenticator), which is something that might be worth considering.

Regardless, these physical authenticators are a huge step up from SMS and I'm very happy that an open standard for them is being popularized and implemented in both sites and browsers.

Lots of websites do weird modal overlays, domain changes and redirects, redesigns, or other tricks that break password autocompletion. I've never seen a secure password manager that's robust enough against all of these that it would eliminate the human factors causing the phishing opportunity here.

Apparently Google hasn't either, because that was their motivation behind developing these schemes.

Would you be able to elaborate on this? I'm not understanding the difference between TOTP and the physical key from the article for this scenario.

With U2F, there is communication between the browser and the device, requesting authentication for a specific origin hostname -- that can't (shouldn't) be fooled by a phish hosted at Google.com-super-secure-phishing.net

https://www.youtube.com/watch?v=Z20XNp-luNA

You say that, but the overwhelming body of evidence from real-life phishing attacks and red-team exercises demonstrates that even very technologically-literate engineers will not consistently notice.

Any "type in a code" or "approve this login (yes/no)?" authentication factor is technically vulnerable. All the phishing site needs to do is proxy the authentication to the actual site in real time.

These guys put together a great overview of the approach: https://www.wandera.com/bypassing-2fa/

I always thought the 2FA threat model was "Someone acquired my password" or else "someone has access to my email account and may try to do password resets by email."

> Google has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical Security Keys in place of passwords and one-time codes, the company told KrebsOnSecurity.

A more in-depth quote is later in the article: "Once a device is enrolled for a specific Web site that supports Security Keys, the user no longer needs to enter their password at that site (unless they try to access the same account from a different device, in which case it will ask the user to insert their key)."

The parenthetical seems to imply that they're doing initial auth (and thus cookie generation) with password + U2F, and then re-validating U2F for specific actions / periodically without re-prompting for the password, similarly to how GitHub prompts for "sudo mode" when you do specific account actions.

They support x509 certs, which use PINs. Whether it needs the PIN once-per-session, once-per-15seconds, or once-per-use is configurable. The number of failures before it locks is also configurable. More details can be found here: https://developers.yubico.com/PIV/Introduction/

They also support TOTP/HOTP, where the computer asks the device for a code based on a secret key that the device knows. This can require a touch of the button.

EDIT: TOTP/HOTP modes do support a password, as cimnine pointed out. I'd forgotten about that setting.

Yubico OTP is similar to TOTP/HOTP, and is the mode where the yubikey emits a gibberish string when pressed. The string gets validated by the server against Yubico's servers. This does not require a PIN.

The U2F mode does challenge/response via integration with Chrome and other apps. The app provides info to the USB device about the site that's requesting auth, then you press the device and it sends a token back. This is critical to the phishing protection: barring any vulns in the local app (which have happened before), you can't create a phishing site that will ask my Yubikey for a challenge that you can then replay against the real site. This mode requires physical touch but no PIN.

Thanks!

The PIN is used to configure the YubiKey itself.

The key (sic) thing about U2F isn't that it is new and special (it isn't -- it's plain old 2FA as used for more than a decade) but rather that it is practical to deploy for smaller organizations. You don't need to buy large quantities of keys. You don't need a special server. You don't need staff with special skills to deploy it. It works with "cloud" providers like Google and Facebook, out the box (same key as you use for your internal services).

However the U2F and Fido spec requires a Cryptographic assertion (with all that replay attack mitigation stuff like Nonces) that makes it so that an attacker can reuse a Token touch. I'd probably encourage a glance over this https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fid...

Sadly the Wikipedia article doesn't have a good layman's explanation yet, but I'm sure it'll will soon.

Yes at a high level, its still 2FA but like most options in any factor of Auth. It can be improved upon. (For a simple case, take Fingerprint readers and look at the advances of liveliness checks and how many unique points it requires.)

Any other 2FA method can.

Short version: the keys are matched directly from the device to the site making it virtually impossible to phish unless you control the site itself.