101–110 of 121 posts
Just tried this on iOS 16.1 and when I go to sign in with the passkey it loads a pop up menu with a QR code that I need to scan - but it's on my phone so what am I supposed to scan it with?
I don't think I understand passkeys. The best I could make out is that it uses an asymmetric key pair for authentication. How is this different from self-signed TLS client certificates (like the ones used in Gemini protocol) or CertFP used in IRCv3?
Earlier quoted context omitted.
The difference is that: 1) this is accessible and usable by anyone running a modern operating system+browser. mTLS client certs need to be provisioned which is one of the major reasons why it is only used in enterprise settings. And 2) passkeys and WebAuthn are privacy preserving features. You can't track users across different websites with FIDO2 devices (mTLS does not preserve your privacy at all). This was one of…
Client certs as implemented on Gemini and IRC are self-signed. They are enrolled on the service after they're created. They don't need enterprise level capabilities. In fact, even the creation of these certificates are automated on many clients (eg: Lagrange Gemini browser, soju IRC bouncer). You don't even think of them as certificates. They're considered as identities. And regarding the privacy. You can deploy as m…
I'm a bit confused with WebAuthn/Passkeys/Fido If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot? Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key acro…
It works like this (WebAuthn non-resident keys):
1. YubiKey contains symmetric key.
2. When you register to WebAuthn service it generates random private key/public key, encrypts the private key with symmetric key, and sends this as token to server. Along with your username and newly generated public key.
3. When you login to WebAuthn service and type your username you get back the token. YubiKey then decrypts the token to get the private key, and answers to the challenge server gives in public key.
In other words, you don't need to store the public/private keys at all, all you need on the client side (YubiKey) the symmetric key. The private keys are stored on server you login.
For WebAuthn resident keys it needs to store info, more here:
https://developers.yubico.com/U2F/Protocol_details/Key_gener...
Just tried this on iOS 16.1 and when I go to sign in with the passkey it loads a pop up menu with a QR code that I need to scan - but it's on my phone so what am I supposed to scan it with?
Read the “learn more” to learn more. (I had the same question.) First create an account and then setup the passkey.
Earlier quoted context omitted.
I second this. I would love to see a raw demo that doesn't hide the internals.
webauthn.io has recently been revamped to support more of the 'passkeys' behavior, such as conditional UI (the password manager/form-fill-like behavior added in certain browsers). webauthn.me has a developer tab that lets you really get your hands dirty.
I'm a bit confused with WebAuthn/Passkeys/Fido If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot? Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key acro…
For the first part yes, you can re-register the key multiple times for multiple accounts on the same site, and generally speaking these are not very correlatable on the basis of the token itself, as long as you have gotten a non-dodgy token (ie, one with a unique attestation cert). There may be other ways to strongly correlate the users however, and then the token may give the final (hard) proof the site was looking for. As a trivial example, linked in does a simple correlation on src IP. If you create 2 fake LI accounts and visit from the same IP, after a ramp up time LI will ask each of them if you want to connect to the other. But in this case, LI already had the info necessary to associate the 2 accounts. The token itself isn't the tip of the spear here, that makes this possible.
Cross-site collusion is prevented by restrictions on the RP ID. So as long as the browser is functioning correctly sites cannot collude to use the token as a supercookie.
> Unless I'm missing something
Well the thing you're missing is that you're simply supposing these things. But these things are prevented by, and intentional in the design of U2F/WebAuthn.
And if you don't trust the browser, or want to protect against sophisticated correlation attacks, "just" use a different token when you want to go dark. I'm not sure why you have this underlying assumption that a person can only possess one token.
One caveat: I've no idea what you're referring to with "GA".
I'm a bit confused with WebAuthn/Passkeys/Fido If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot? Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key acro…
What you're asking is if the token can act as a so-called supercookie. For the first part yes, you can re-register the key multiple times for multiple accounts on the same site, and generally speaking these are not very correlatable on the basis of the token itself, as long as you have gotten a non-dodgy token (ie, one with a unique attestation cert). There may be other ways to strongly correlate the users however, a…
Probably means google analytics.
Earlier quoted context omitted.
> I'm aware about this requirement, and it makes sense. See, pins for yubikeys don't make much sense to me. If you have to enter a PIN and press the button on a token, that doesn't seem very different to entering a password and pressing the button a token which U2F has offered for years.
There are yubikeys with biometric readers. The reason they are referred to as PINs rather than passwords is that they are locally set and entered, without being shared with external network systems. Since they are being used to augment the physical security properties of the hardware device, the PIN can also be far simpler than a typical password - someone has to steal your hardware before they can contemplate forcin…
This part of the overall design seems problematic to me. These “resident” keys are described as “passwordless”, but they’re really username-less. And an attacker who gets the security token can not only log in but they can also enumerate all credentials. Ouch!
ISTM a much better design would have been to put the credential list on the browser side. If I log into a website that I’ve used before from the same browser, the browser’s credential manager can remember my username (and optionally key handle) and the external token can do a normal authentication. No website state is stored on the token, and the experience is almost as good — the user only ever needs to enter their username once per browser.