emlun

Someone made a bookmarklet to disable it: https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet

Google did suddenly start supporting U2F in Firefox a few months ago!

Unlimited! Except for passwordless credentials, which do consume storage space aboard the device. But second factor (U2F style) credentials are stored encrypted on the server, so there's unlimited "space" for them.

If the server allows it, sure.

That won't work for U2F or FIDO2, unfortunately, since the master key is not configurable. You need to enroll both keys with each new service, sadly.

For U2F you're right that it becomes single factor if you use the device as the only factor. With FIDO2 (which is what makes passwordless available), however, the device supports a local PIN as the "something you know" factor - and it's also a better kind of knowledge factor than a traditional password since it's never sent over the network.

It's a hardware token that supports a local PIN as a second factor.

My friend lost his YubiKey and found it embedded in his gravel driveway six months later. Still worked like nothing had happened.

And even then, the token would lock itself down after too many incorrect PIN attemtpts.

NEO also does OpenPGP over NFC on Android. iOS only recently started opening up NFC to non-Apple developers.

Yubico currently sells one at $20. https://www.yubico.com/product/security-key-by-yubico/#secur...

There are competing U2F keys, but I don't know of any competitors that support FIDO2 yet.

>where somebody else owns your identity, not you

Care to elaborate on how you mean WebAuthn prescribes that? The GUN explainer videos also seem to assume there's a server involved, so I don't understand what you mean is bad about that.

No, you were right at the beginning. There is no "root" or "real" pubkey. A separate keypair is generated each site, so that - like you said - identities are unlinkable. This is also a crucial part of what makes these credentials immune to phishing.

Yeah, and a separate keypair is generated for each site.

Web Authentication is part of FIDO2, which is what Microsoft is pushing. Whether you use it for passwordless login or second factor depends on what the server wants and what authenticator hardware the user has.

I'm sorry, I don't understand at all what you mean by that.

No - that process _remains_ a pathway for exploits against the particular website being targeted. The process does not open new pathways for transferring exploits from one site to another - on the contrary, such exploits are made more difficult by the separation of credentials.

To be more precise, the PIN is the key that unlocks the keyring (the hardware token) that contains the keys (asymmetic keypairs) to the various kingdoms (websites). WebAuthn is not a single sign-on framework, and there's no "root credential" that's used everywhere.

Oh, maybe I didn't get the entire question. There's no global identity or "root credential" used for all websites. A separate keypair is created for each website, and a keypair for site A is not usable on site B even if site B somehow has the public key.

I think you misunderstand how WebAuthn works - there's no "root credential". See my other reply https://news.ycombinator.com/item?id=17032637

No third party issues tokens in WebAuthn either - you have your one or a couple of authenticators you use everywhere, and those authenticators create their credential keypairs locally on the device (and a separate keypair is created for each site - they're not shared between sites).

I think you misunderstand how WebAuthn works - see my other reply to your previous message.

Wait a second. Web Authentication is not an SSO framework - there's no "root credential". Each server you use the token on gets its own keypair which is used for only that site.

It seems like the scenario you're describing in further replies is this: 1) Alice has an account at service A and an account at service B, and authenticates to both with the same FIDO2 token. 2) Eve calls service A and convinces them she's Alice and needs a new token. 3) Service A sends Eve a new token registered to Alice's account. 4) Eve uses the new token to log in as Alice at service B.

The above attack is not possible, since the keypair for service A is not usable at service B. This separation of credentials for separate services is a fundamental FIDO/WebAuthn design feature for damage control and user privacy. Eve can use the new token to log in to service A, yes, but only to service A.

Even if service A and service B were to try to cooperate out-of-band to support each other's credentials, the browser would not let them unless they're on the same domain.

It's mostly for host-authenticator communications, yes, but it it includes a couple of helpers for verifying signatures. But you're right it's not a full-featured server library at this point.

From what I understand, Firefox doesn't implement the whole U2F spec, and Google and Facebook use some of the features (appID facets) FF left out. However, Firefox, Chrome and Edge all plan to implement the whole Web Authentication API.

The PIN is not stored on the key, it's used to unlock the key. Your analysis is correct, but your premise is false.

This.

Though I'd like to add that FIDO2 does support fingerprints and other biometrics as an additional authentication factor - it all goes under the same abstract "user verification" umbrella as PIN does. The important distinction is that the PIN or fingerprint is never shared with the server - it's only used to unlock the private key - so it's much more difficult to steal.

Maybe I misspoke - by "optional" I meant "optionally required". The server can require the use of a PIN - and although the PIN verification is done client-side, the authenticator (YubiKey) sets a bit in the signed response to indicate whether PIN was used. The server can then verify the authenticity of the bit if it trusts the authenticator's attestation certificate.

It's also allowed for authenticators to always require PIN even if the server doesn't, but the current YubiKey obeys the server's preference.

But yes, there will of course be bugs. But that is also true for password logins, so I don't see it as a particularly convincing argument.

What Freak_NL said. No, there is no globally correlatable identity, and it won't be possible to either create or authenticate credentials silently. Browsers will show confirmation popups and YubiKeys will start blinking to prompt for touch confirmation.

In a sense, yes, but the keyword is "on-device". It's not shared with the server, so it can't be remotely intercepted - but it _can_ be changed in a single place (the YubiKey) should it ever be compromised.

They will not support FIDO2, but they do support U2F which is compatible with a subset of the FIDO2 features. Specifically, they don't support PIN or username-less login, but they CAN be used as 2nd factors (emphasis on the 2) in addition to conventional username+password login.