Please, please, please stop using #passkeys to encrypt user data.

[timcappalli@infosec.exchange]

Please, please, please stop using #passkeys to encrypt user data. Please

https://blog.timcappalli.me/p/passkeys-prf-warning/

[jasonkarns@indieweb.social]

@timcappalli I think it’s even worse than this! Your do a great job explaining why it’s problematic for users who -don’t- know what’s happening (and also the increased risk of loss for everyone)

But there are second order affects on -security-. A user who -knows- their passkey is encrypting their data must now keep that key much longer than they would otherwise need to. Auth keys should be safe for frequent rotation and replacement, which means keeping their scope tight.

[stf@chaos.social]

@timcappalli isn't that what age is also pushing?

[glyph@mastodon.social]

@timcappalli haha oops https://github.com/glyph/tokenring

(I don't think this *quite* qualifies for what you're talking about, as anything speaking ctap2 directly is not quite in the same category as doing PRF in the browser)

[timcappalli@infosec.exchange]

@stf age?

[stf@chaos.social]

@timcappalli https://words.filippo.io/passkey-encryption/

[timcappalli@infosec.exchange]

@stf oh, that. yes.

[i@toot.pouyan.net]

@timcappalli@infosec.exchange To add to the arguments: it also defeats the whole idea of having hardware security keys. If the secret is stolen or exposed somehow, decryption does not require access to the hardware token anymore.

[i@toot.pouyan.net]

@stf@chaos.social I just recalled that confer (LLM by moxie and co) is also using passkeys for encryption:

https://confer.to/blog/2025/12/passkey-encryption/

@timcappalli@infosec.exchange

[cthos@mastodon.cthos.dev]

@glyph you’re also setting the explicit expectation that the hardware token is required for access. Which is not the same as “whoops we added another confusing thing to your passkey”