gre345t34

To be fair, the webauthn spec expressly forbids facilitating the extraction of credentials from the authenticator (though arguably even syncing between devices violates the spec).

Ideally you should not be able to determine whether a username is valid without authenticating.

If you got tricked into logging into goggle.com or something the FIDO2 auth would fail because a) the URL would not match the credential metadata and b) the resulting assertion, a signature over data which includes the URL, would not be valid (google.com would not accept it).

A FIDO2 credential can be used for passwordless authentication, so long as the authenticator performs user verification (e.g. requires a PIN). This counts as 2FA because it's something you have (the authenticator) plus something you know/are (PIN/biometric).

It can also be used as an second factor for traditional username/password auth (with or without user verification).

Losing a passkey is no different to losing any other credential: you need another method to authenticate or recover your account.

The article assumes quite a bit of knowledge of FIDO2 and your confusion is understandable.

> How/why? What's the connection to passkeys or HSMs?

Passkeys are implemented on top of FIDO2 and specifically utilise the "resident key" functionality of the FIDO2 spec (according to the article; I don't personally understand passkeys). FIDO2 hardware authenticators are not HSMs exactly, though they are similar and some devices (like Yubikeys) are both HSMs and FIDO2 authenticators.

> Yeah okay... does this imply that all resident keys are discoverable keys? Or that all discoverable keys are resident keys? Or both?

In FIDO2 "resident key" and "discoverable key" are synonymous. "Resident key" is the term used in the spec, however "discoverable key" is commonly used. One of many such cases of FIDO creating confusing terminology.

> No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or both? Or something else entirely?

Neither, it refers to FIDO2 hardware authenticators (e.g. Yubikeys) which are commonly referred to as "security keys".

> Okay so an HSM can apply to an unlimited number of accounts because it can store... some kind of key wrapped in another key (of the same type? different type?)

A FIDO2 hardware authenticator (which is not a HSM per se) can be registered with unlimited accounts because it is effectively stateless; it doesn't store anything (assuming that you are NOT using resident keys, which must be stored).

When the authenticator is registered with an account, it generates a key pair on the device (e.g. an EdDSA key pair). Instead of storing the key pair, it encrypts the private key with the onboard master key (e.g. an AES256 key). It then sends the plain text public key and the encrypted private key to the "relaying party" (e.g. google.com) who stores it. When authentication is attempted, the encrypted private key (i.e. the "wrapped" key) is sent to the authenticator where is decrypted onboard and then used to produce a digital signature.

Note: The FIDO2 does not actually specify how to implement non-resident keys - wrapped keys are just one way of doing it. FIDO2 only requires that the private key must be securely derivable from the credential ID (where the credential ID is actually arbitrary data which may or may not be a wrapped key).

Tell me about it. All of the terminology around FIDO is super confusing, and FIDO themselves make no effort to clarify or acknowledge the confusion.

Everyone (including Yubico) uses the terminology incorrectly in a way that makes it super hard to get to the bottom things.

CTAP1 is only used for talking to old U2F keys.

Additionally, U2F/CTAP1 does not support resident keys anyway (IIRC).

Primary issue with FIDO is not the specs themselves but the extremely confusing nomenclature that FIDO put zero effort into clarifying.

It's like murder but scaled up.

There's a certain amount of cosmic irony involved whenever someone calls LLMs 'stochastic parrots' or whatever.

The context is that US is developing high altitude balloons for detecting hyper-sonic weapons. Developing a technology and actively using in another country's airspace are quite different things, so it's not really that surprising that articles don't find it important to include.

Yeah, kinda of disappointing for the author to disavow his own cautionary tale about AI, because obviously only meat can be conscious I guess.

Can you tell us how to determine which tasks require "understanding" and which don't, so that we may make accurate predictions about what tasks LLM's will be capable of in the future?

As far as I can tell, it's a library that implements CTAP2 (which it erroneously refers to as webauthn).

Why should hackers be prosecuted for using systems as they're programmed?

Because there are lenses in the headset that focus the two images at a set focal distant (between a couple of meters and infinity focus, depending on the headset).

You need glasses for the same reason one would need glasses to see a flat image several meters aways, or to see the stars as the case may be.

You are confusing optical focus (like a camera lens or the lens in your eye) with stereopsis - the mechanism by which your brain detects depth information through parallax.

The VR headset shows each eye a slightly different image. Objects appear in slightly different locations in each image. When you look at these virtual objects, the relative angle between your eyes changes which creates the illusion of depth. (This is my layman understanding. I am open to correction).

The optical focal distance remains constant, however.

This is inaccurate. Unlike IRL in which objects can appear at varying focal distances, requiring the eye muscles to constantly adjust the focal distance of the eye, the two images in a VR headset (one for each eye) remain at a constant focal distance as determined by the lenses.

The 3D illusion in VR comes from stereoscopy. The objects that appear in VR are actually all at the same focal distance.