3 ms·

This enables a few cool use cases, like uploading sensitive, client-side encrypted documents, and storing them on behalf of the user—without even being able to

by 9dev 1y ago

This enables a few cool use cases, like uploading sensitive, client-side encrypted documents, and storing them on behalf of the user—without even being able to peek inside—all with the convenience of passkeys!

megous 1y ago
Nothing that the user can trust, though. Only way to upload sensitive data is to encrypt it yourself, while handling all the secret key material yourself, and then upload the result. You can't trust the website, when it has access to the secret key, regardless of whether it was derived from FIDO2 HMAC or whatever.
- 9dev 1y ago
  Huh? But that’s the entire point. The website only knows your public key. The encryption happens locally, within the secure code of the authenticator, far away from the website.
  - skybrian 1y ago
    The decrypted data is stored in a JavaScript variable. The JavaScript is under full control of the website owner. Adding telemetry to a website is pretty easy. It would simplify website operations and eliminate some kinds of security bugs, though.
    - 9dev 1y ago
      Well, okay, sure. But everything that is exfiltrated happens in plain sight, since all crypto operations are performed client-side. This offers way better guarantees than plaintext or SSE for many use cases IMHO.
  - megous 1y ago
    No it does not. Website knows the secret key, it just is not supposed to store it (user has to trust that the website stores just salt and not the derived secret key): https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#sctn-hmac-secret-extension https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...
- lxgr 1y ago
  Trust isn't absolute. Deploying a malicious version of a given webapp is still harder (and much more visible) than just silently dumping a backend database, so I'd trust an implementation that client-side encrypts my data using PRF and passkeys significantly more than one just uploading everything in plaintext.
skybrian 1y ago
This could simplify things a bit for website owners since they don’t need to protect a database where they store encryption keys. Bugs or supply-chain attacks on client-side software are still a vulnerability, though. For the customer, they are unlikely to be able to audit the client-side software and any updates to it, so it still requires trust. The software could still have a lot of telemetry baked in. Maybe someday there will be something like certificate transparency for software?
- SchemaLoad 1y ago
  Sometimes the company cares more about not having access than the end user does. If you physically don't have the decryption keys, you can't get hacked and have user data leaked. You can also respond to government data requests with "Sorry we don't have access to that"
  - 9dev 1y ago
    This. If you store a lot of sensitive documents, you also paint a target on your back. If you don’t even have the decryption keys, this angle becomes irrelevant.

by 9dev 1y ago

megous 1y ago

Nothing that the user can trust, though. Only way to upload sensitive data is to encrypt it yourself, while handling all the secret key material yourself, and then upload the result. You can't trust the website, when it has access to the secret key, regardless of whether it was derived from FIDO2 HMAC or whatever.

9dev 1y ago
Huh? But that’s the entire point. The website only knows your public key. The encryption happens locally, within the secure code of the authenticator, far away from the website.
- skybrian 1y ago
  The decrypted data is stored in a JavaScript variable. The JavaScript is under full control of the website owner. Adding telemetry to a website is pretty easy. It would simplify website operations and eliminate some kinds of security bugs, though.
  - 9dev 1y ago
    Well, okay, sure. But everything that is exfiltrated happens in plain sight, since all crypto operations are performed client-side. This offers way better guarantees than plaintext or SSE for many use cases IMHO.
- megous 1y ago
  No it does not. Website knows the secret key, it just is not supposed to store it (user has to trust that the website stores just salt and not the derived secret key): https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#sctn-hmac-secret-extension https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...
lxgr 1y ago
Trust isn't absolute. Deploying a malicious version of a given webapp is still harder (and much more visible) than just silently dumping a backend database, so I'd trust an implementation that client-side encrypts my data using PRF and passkeys significantly more than one just uploading everything in plaintext.

skybrian 1y ago

This could simplify things a bit for website owners since they don’t need to protect a database where they store encryption keys. Bugs or supply-chain attacks on client-side software are still a vulnerability, though. For the customer, they are unlikely to be able to audit the client-side software and any updates to it, so it still requires trust. The software could still have a lot of telemetry baked in. Maybe someday there will be something like certificate transparency for software?

SchemaLoad 1y ago
Sometimes the company cares more about not having access than the end user does. If you physically don't have the decryption keys, you can't get hacked and have user data leaked. You can also respond to government data requests with "Sorry we don't have access to that"
- 9dev 1y ago
  This. If you store a lot of sensitive documents, you also paint a target on your back. If you don’t even have the decryption keys, this angle becomes irrelevant.