5 ms·
My main beef with Passkeys is that there is no hardware attestation. With Yubikeys, the relying party has a cryptographic way to ensure that the key is generat
by traceroute66 3y ago
My main beef with Passkeys is that there is no hardware attestation.
With Yubikeys, the relying party has a cryptographic way to ensure that the key is generated on a Yubikey, and can even validate the specific Yubikey hardware version.
AFAIK, with Passkeys you can't do that. You have to trust that it was generated and stored securely and not just some software emulation.
The Passkey manufacturers argue this is because Passkeys are intended to be transferable between devices. But I can't believe there is no form of attestation possible just because you are transferring the keys around, afterall it should be possible to attest that "these bytes were signed by a key in a $this_device secure enclave and the key was securely imported to the device secure enclave via $manufacturer Passkey process" or something along those lines, no ?
- voxic11 3y agoIt's funny because in the last post on this topic everyone was complaining that the problem with passkeys is that they can't be transferred between devices like passwords can.
- lxgr 3y agoSometimes different people have different objections to a single thing. There isn’t one generic “anti-Passkey” archetype.
- stavros 3y agoWebAuthn supports attestation, so passkeys must too. Usually I hear the opposite argument, that people don't want to use WebAuthn/passkeys because of attestation.
- lxgr 3y ago> WebAuthn supports attestation, so passkeys must too. They can (it's optional, i.e. not a specification-"must"), but so far they don't. Apple explicitly unshipped attestation when they introduced keychain-synced Passkeys; I think Google also had attestation for a while on Android and did the same. Requiring attestation was actually a way to opt out of passkey synchronization on iOS for that very reason, but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation. > Usually I hear the opposite argument Different people have different needs and priorities. Authentication is a large surface with multiple actors and sometimes conflicting goals.
- danShumway 3y agoThis might be being reconsidered; I don't have the full details but I've seen some talk about attestation being expanded to handle roaming keys as well. I think that's a mistake -- I think there are a lot of security and UX considerations around roaming keys that make attestation not suitable: For example, what happens when a user moves between ecosystems and finds out after the fact that their new ecosystem isn't supported? Also does attestation for an ecosystem and not just for a device actually offer any strong security or phishing guarantees? Apple supports sharing passkeys with contacts, so what phishing protection are you actually getting here? I'm a little bit skeptical of attestation in general, but there are scenarios where some regulatory bodies might really want it, and many of these specific concerns don't exist for device-bound keys, and you do actually get some strong security guarantees from them, so attestation at least makes a bit more sense there. I look at a company asking for attestation for device-bound keys and think, "yeah, that makes sense, you want a strong security boundary around the key." But my point isn't to argue one way or another, just to point out that, yes, keychain-synced passkeys on devices like iOS don't support attestation right now. But I don't know if that's going to be the case in the future or how that will change when certification starts ramping up. > but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation. I'm too far out from the tech to speak confidently about it and I'm sure there are considerations I'm not aware of, but it really seems to me from the outside that a key being synced or device-bound should have been an attribute of the passkey and not like an entirely separate system. I know there are considerations with hardware tokens and resident key limits, but I also suspect part of this is that roaming keys were a later addition, my understanding is that they were relatively controversial when first proposed and so maybe that led to them kind of evolving separately? I'm just guessing though. It is very weird that iOS requires passkeys to be roaming keys.
- overstay8930 3y agoIf you rely on Attestation, all you have to do is use Private Access Tokens: https://developer.apple.com/news/?id=huqjyh7k https://developer.apple.com/news/?id=huqjyh7k
- deleted 3y ago[deleted]
- josephcsible 3y agoUnless you're trying to use them to enforce hardware DRM for you, why do you care that the user can't back them up? Lack of attestation is a good thing.
- traceroute66 3y ago> Unless you're trying to use them to enforce hardware DRM for you Oh FFS ! Not everything has to bubble down to the same old FLOSS claptrap you know ! > Lack of attestation is a good thing. Had you read a few of the comments before posting, you would have learnt that regulated environments and sensitive use cases are two of many concepts that you would do well to think about before jumping on your "stick it to the man, no DRM !" bandwagon. The Financial Sector is a low-hanging fruit example. If I'm trusting you to put on million-dollar trades, then I damn well want to know its you at the computer and not some Russian hacker who has has inevitably exfiltrated your credentials which were stored in software with Passkeys. If I give you a Yubikey: - I can force you to enter a password to "arm" it for use every time, no caching - I can force you to physically touch it to execute the transaction - Through hardware attestation I can know it is your Yubikey that I gave you - I can force it to lock the key if the wrong password is entered too many times - If you loose your Yubikey, I can kill access - Many other things... Time and time again software has shown us that you cannot trust it with secrets. That's why HSMs exist, that's why Yubikeys exist. The modern world is a scary place in terms of security, hardware attestation is a CRITICAL part of the security onion.
- josephcsible 3y ago> I'm trusting you to put on million-dollar trades, then I damn well want to know its you at the computer and not some Russian hacker who has has inevitably exfiltrated your credentials which were stored in software with Passkeys. In such a high-value environment, you could buy the YubiKey, provision an account for me registered to it, then give it to me. That would give you the assurance you want without needing remote attestation. Also, if Russian hackers had enough access to my computer to steal my software passkeys, couldn't they just wait for me to start a valid session with my YubiKey and then use that session to do whatever they wanted? > - I can force you to enter a password to "arm" it for use every time, no caching > - I can force you to physically touch it to execute the transaction > - Through hardware attestation I can know it is your Yubikey that I gave you > - I can force it to lock the key if the wrong password is entered too many times > - If you loose your Yubikey, I can kill access > - Many other things... Those are downsides, not upsides, because of the mixing of "I" and "you". I should be able to decide my own risk tolerance levels for access to my own accounts. You shouldn't get to decide them for me. > Time and time again software has shown us that you cannot trust it with secrets. That's why HSMs exist, that's why Yubikeys exist. Sure, that's a good argument for hardware secret storage. But not for attestation. It's a good thing that I have the ability to use HSMs and YubiKeys for access to my accounts, but if I don't want to, other people shouldn't be able to force me to.