Hacker News Reader

Comment by cmdli | Hacker News Reader

Just because this is a common misunderstanding of passkeys, I'm going to state it again here: passkeys don't have to be locked to a hardware chip inside your device in order to work. It is entirely possible to have use passkeys only in software (shameless plug to the passkey manager I'm building, https://bulwark.id), and that is most likely the way that most people will interact with them.

I think it's unfortunate that Apple and Google are the ones who are most visible in the passkey space because it gives people the idea that passkeys are a locked-down authentication mechanism when they aren't.

View on HN

>that is most likely the way that most people will interact with them

i admire your confidence in your product, but i'm pretty sure the way most users will interact with passkeys is the first-party workflow that their devices promote, and not third-party tools.

Just lite the most common password manager is the one built into chrome and ios, right?

Last time I looked into your implementation, it looks very neat, but I would like to store each passkey to a file and encrypt with GPG. I use https://www.passwordstore.org/ like mechanism to store all my passwords.

This is something that would be very nice to support, and saving to just a local file and allowing users to use their own storage mechanisms is definitely an intended use case. Right now it stores the entire vault encrypted on disk, but I would like to be able to store passkeys in a standard format (ideally supported by multiple managers) and then allow users to do whatever they want with them.

Where did you get the idea that Apple and Google's implementations are hardware-bound?

Generally, the idea is that the private keys are stored on a TPM chip so they cannot be exported for security reasons, similar to a YubiKey or a crypto wallet. I know Apple and Google are looking into trying to allow users to somehow export these keys elsewhere, but I'm uncertain how easy that will be or what tradeoffs there will be. I'm skeptical that Apple and Google will try to make it too easy since they benefit from user lock-in, but I would be happy to be proven wrong.

> I'm skeptical that Apple and Google will try to make it too easy since they benefit from user lock-in, but I would be happy to be proven wrong.

https://hachyderm.io/@rmondello/110329118270492669

Apple's existing password manager (which is what surfaces passkey management) lets you export and import the database as a CSV file, same as Google and many others. I suspect the biggest missing piece is an agreement on an interoperable format - likely one that would also be interoperable for password and TOTP exchange as well.

As far as I can tell both Google and Apple have a mechanism to export the key so you can replicate the same key to another device. I run into this same situation with "HSM clusters" sold in enterprises where I don't really understand how people can claim with a straight face that you can't export the key to another device when they just explained to me that they export the key to another device.

That is not Apple’s stated design at all. If you read Apple’s passkeys security document, it claims that the private keys are synchronized with iCloud and are recoverable following the loss of all devices. Non-exportable passkeys using the TPM is an HN myth.

Per this: https://www.slashid.dev/blog/passkeys-deepdive/

The private key is both kept in your phone’s Secure Enclave and stored in iCloud, so strictly speaking the implementation isn’t hardware-bound in that case.

But I think the intended point is something more practical: can you, as a user, export the passkey to be shared on your non-Apple laptop, phone, etc? And maybe I’m mistaken, but I’ve been under the impression that you cannot.

Hi,

I'm the author of the blogpost. You are spot on, Passkeys are exportable so the private key ends up both on iCloud and the Enclave/authenticator.

My understanding is that there's chatter about cross-vendor synchronization of passkeys but nothing concrete yet.

Meanwhile Apple allows people to share Passkeys via AirDrop (Settings > Passwords - select the passkey you want and click the "Share" icon to send it over Airdrop) so it should be possible with some effort to obtain the private key with something like this: https://github.com/seemoo-lab/opendrop. Haven't done extensive testing yet though, so I can't confirm.

Would love to hear if anybody knows more about how the sharing via AirDrop is implemented/protected.

Given it sync from iCloud, you probably could export with enough prying at the MacOS Keychain app, but exporting them out is not a supported use case yet.

I'm pretty sure my 2017 Macbook Pro (Intel, no Touch Bar) doesn't have a Secure Enclave chip, yet it supports Passkeys.

Hi,

I'm the author of the SlashID blogpost. You are right, the WebAuthn standard doesn't provide any guarantees on the authenticator storage security hence passkeys (and WebAuthn creds) can be stored in anything that speaks CTAP2.

We wrote a follow-up blogpost talking about the threat model in which we touch on the above: https://www.slashid.dev/blog/passkeys-security-implementatio...

If macOS can download it from iCloud, with enough reverse engineering you should be able to use the same APIs.

Unless iCloud only lets you download it in a form only the secure enclave can decrypt.

How are you doing the Linux integration?

Maybe nit-picky.. but why does the Linux download assume a Debian-based distribution?

Fortunately, any non-Debian Linux uses will know enough to be to do something with the .deb.

Reply on news.ycombinator.com