[lvh]

> U2F can only be used as a second factor.

I mean, certificationally, sure. But what prevents a website from trusting you to input your identifier (user name or e-mail address) and then accepting a U2F signed blob as your only credential?

[StavrosK]

The fact that if someone steaks the key they can impersonate you anywhere. U2F doesn't support pin authentication, as far as I know.

[lvh]

It's not built into the protocol, sure, but the device can do whatever it wants before it decides to sign something. You need to unlock my phone and SEP before Krypton signs anything, for example. But you still raise a good point: I suppose it's a good thing that we can do that with cheaper devices and safe, browser-provided UX for PIN entry.

(I would suggest that a single physical device that takes a PIN before it does some signing is still 2FA even if there is only one _communicated_ credential, but I appreciate we need better terminology for this. Other versions of this to consider: if you username + password + Duo into your SSO portal and then sign into a service with SAML, is that not 2FA? If it isn't, does using a session cookie prevent something from being 2FA? For the latter, I'd say obviously not :-) I think the "who can impersonate you" is a good line in the sand, since in the former the SSO system holds full authority in most cases.)

[StavrosK]

I completely agree with everything you said, but a U2F token that takes a PIN would be hard in the sense that it would be hard to make it cross-platform (unless the PIN pad were on the actual device or something).