3 ms·

Encrypting Data in the Browser Using WebAuthn

62 points by IAmKale 4y ago

justsomeadvice0 4y ago
That is really cool, thanks for a detailed writeup. I try to pay attention to the WebAuthn spec and did not realize this was possible. I suspect that for most people, WebAuthn (esp with synced passkeys) is going to actually make the CI part of CIA possible for end user content on the internet. In practice it solves the UX around key management and device syncing issues - it passes the "your grandmother can use it" test IMO. The web3 concept was caught up in cryptocurrencies and constraints around distributed systems; but extending asymmetric cryptography to end users is what should be worked on, as it allows improving most systems without financial or performance overhead. mTLS certs approached the issue but the UX never got there, and cannot be used outside of site authentication.
- AlbertVAustin 4y ago
  > it passes the "your grandmother can use it" test IMO. Indeed, but note that having the token is still rare. It'd be good if browsers exposed TPMs via WebAuth since they're more common on consumer-grade hardware. And also the "minor" thing that having only one strong authenticator makes it super-easy to lose own data just in case the authenticator breaks etc.
  - cormacrelf 4y ago
    They do. At least Apple implements WebAuthn for Touch ID and Face ID on both its mobile and laptop platforms, using Safari.
    - jrockway 4y ago
      Windows also has this; they call it "Windows Hello".
  - deleted 4y ago
    [deleted]
  - justsomeadvice0 4y ago
    > And also the "minor" thing that having only one strong authenticator makes it super-easy to lose own data just in case the authenticator breaks etc. This is why I mentioned "esp with synced passkeys". WebAuthn can use - but does not necessarily require - hardware-backed keys. iCloud passkeys are an example of an implementation of "soft" keys that are both transparently backed up and synced across the user's devices. Their interfaces are designed to make them difficult to leak (I'd imagine you'd need root+SIP turned off, or a really good OS bug), but are to my knowledge resident in device memory. This is tradeoff for usability. Grandma is never going to be able to use yubikeys to log into things, let alone set one up.
TacticalCoder 4y ago
Am I misunderstanding TFA or is the encryption done with the encryption key in the clear inside the browser? I just set up my servers' SSH to use U2F keys for authentication and the secret never leaves the security key, protected behind the security key's HSM. That's kinda the point of these security keys: computers aren't devices to be trusted. If they were, we wouldn't need physical security keys with the secrets hidden behind a HSM. From TFA: > Local threats like JavaScript injection attacks could exfiltrate the value of inputKeyMaterial from Step 2.1 and store it away for later use. I really enjoyed TFA but... These kind of "local threats" are precisely what these U2F security keys are all about: you can use them on a totally compromised computer and yet the attacker cannot extract the secret from the security key. I've seen people use security keys with GPG and I'm nearly sure the private part of the key is never leaving the security key. I may be wrong though...
- d1sxeyes 4y ago
  > Am I misunderstanding TFA or is the encryption done with the encryption key in the clear inside the browser? I'm struggling with a similar problem, and don't see a more user-friendly way to do it. So far my flow is as follows: 1. User logs in and is prompted to create an encryption key using a password that they won't forget 2. Encryption key is created and wrapped using the password as part of the key material for the wrapping key 3. Wrapped encryption key is sent off to the DBMS. 4. Wrapped encryption key is fetched from DBMS and user is prompted for password to unwrap 5. Unwrapped encryption key is stored locally in order to encrypt and decrypt messages. I don't see any way to do it differently without either a) storing the unwrapping key password (in which case, why not store the key itself?), or b) asking for the unwrapping key password every time the key is used (which is super annoying). Assuming that I can't ask users to do any kind of key management themselves, is there a better option?
- rektide 4y ago
  Authentication & data-encrulyption have different needs. That it took so so many years for WebAuthn to recognize the need to do more than authenticate, to add "pr", is because it was non obvious what we would do, because so many security folk never want to let the keys out. In a fantasy world, security keys might be high speed decrypting devices, that we could pass data into & quickly get data out of. They, alas, are not so high-featured at present. And, this would come with a host of assumptions. If I want to use group cryptography so a set group of people/keys can decode the data, will the hardware implement that? What do you suggest then? I understand the concern. Do you propose we not allow encrypting data? Do you have some other idea for what we might do today? I hope we can both recognize a tension between hardened security & soft software. Possibility is scary. But imo the progressive approach here, embracing the good, is the only way we get nice things. For folks like offline webapps to be able to use keys to protect themselves & their data is a huge huge win.
dariosalvi78 4y ago
this is excellent news. Combined with passphrases, it makes encrypted web apps possible without the need to remember a password, which is the main risk in applications where the data is encrypted. Last time I checked PRF was in the source code of Chrome, but not available in the official release, but seems like it's going to come. I hope Safari will follow soon.
bawolff 4y ago
This is cool, but the elephant in the room for all these cryptography in the local browser is still there. Namely, you have to trust the server not to send you malicious html and if you already trust the server you might as well do things server side. As the saying goes, security is always about the weakest link.
- snowstormsun 4y ago
  You could create a local HTML file without a server for it.
  - kevincox 4y ago
    Edit: This was a misreading, see child comments. You can't actually do this because file:// URLs are not considered a secure context and the Web Crypto API is only available in secure contexts: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... You would need to run a local webserver and access it over `localhost`.
    - snowstormsun 4y ago
      Yeah, also thought so, but here it says "and file:// URLs are also considered to have been delivered securely." (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...). Am I missing something?
      - kevincox 4y ago
        Hmm, I must have misread that paragraph based on my expectation.
        snowstormsun 4y ago
        But you're right. Just tried it and it told me: "Uncaught (in promise) DOMException: Public-key credentials are only available to HTTPS origin or HTTP origins that fall under 'localhost'. See https://crbug.com/824383 https://crbug.com/824383" Unfortunate :/
snowstormsun 4y ago
Very cool!
mprime1 4y ago
My own in-browser encryption project/POC: https://mprimi.github.io/portable-secret/ https://mprimi.github.io/portable-secret/ Discussed here: https://news.ycombinator.com/item?id=34083366 https://news.ycombinator.com/item?id=34083366

62 points by IAmKale 4y ago

That is really cool, thanks for a detailed writeup. I try to pay attention to the WebAuthn spec and did not realize this was possible. I suspect that for most people, WebAuthn (esp with synced passkeys) is going to actually make the CI part of CIA possible for end user content on the internet. In practice it solves the UX around key management and device syncing issues - it passes the "your grandmother can use it" test IMO. The web3 concept was caught up in cryptocurrencies and constraints around distributed systems; but extending asymmetric cryptography to end users is what should be worked on, as it allows improving most systems without financial or performance overhead. mTLS certs approached the issue but the UX never got there, and cannot be used outside of site authentication.

AlbertVAustin 4y ago
> it passes the "your grandmother can use it" test IMO. Indeed, but note that having the token is still rare. It'd be good if browsers exposed TPMs via WebAuth since they're more common on consumer-grade hardware. And also the "minor" thing that having only one strong authenticator makes it super-easy to lose own data just in case the authenticator breaks etc.
- cormacrelf 4y ago
  They do. At least Apple implements WebAuthn for Touch ID and Face ID on both its mobile and laptop platforms, using Safari.
  - jrockway 4y ago
    Windows also has this; they call it "Windows Hello".
- deleted 4y ago
  [deleted]
- justsomeadvice0 4y ago
  > And also the "minor" thing that having only one strong authenticator makes it super-easy to lose own data just in case the authenticator breaks etc. This is why I mentioned "esp with synced passkeys". WebAuthn can use - but does not necessarily require - hardware-backed keys. iCloud passkeys are an example of an implementation of "soft" keys that are both transparently backed up and synced across the user's devices. Their interfaces are designed to make them difficult to leak (I'd imagine you'd need root+SIP turned off, or a really good OS bug), but are to my knowledge resident in device memory. This is tradeoff for usability. Grandma is never going to be able to use yubikeys to log into things, let alone set one up.

TacticalCoder 4y ago

Am I misunderstanding TFA or is the encryption done with the encryption key in the clear inside the browser? I just set up my servers' SSH to use U2F keys for authentication and the secret never leaves the security key, protected behind the security key's HSM. That's kinda the point of these security keys: computers aren't devices to be trusted. If they were, we wouldn't need physical security keys with the secrets hidden behind a HSM. From TFA: > Local threats like JavaScript injection attacks could exfiltrate the value of inputKeyMaterial from Step 2.1 and store it away for later use. I really enjoyed TFA but... These kind of "local threats" are precisely what these U2F security keys are all about: you can use them on a totally compromised computer and yet the attacker cannot extract the secret from the security key. I've seen people use security keys with GPG and I'm nearly sure the private part of the key is never leaving the security key. I may be wrong though...

d1sxeyes 4y ago
> Am I misunderstanding TFA or is the encryption done with the encryption key in the clear inside the browser? I'm struggling with a similar problem, and don't see a more user-friendly way to do it. So far my flow is as follows: 1. User logs in and is prompted to create an encryption key using a password that they won't forget 2. Encryption key is created and wrapped using the password as part of the key material for the wrapping key 3. Wrapped encryption key is sent off to the DBMS. 4. Wrapped encryption key is fetched from DBMS and user is prompted for password to unwrap 5. Unwrapped encryption key is stored locally in order to encrypt and decrypt messages. I don't see any way to do it differently without either a) storing the unwrapping key password (in which case, why not store the key itself?), or b) asking for the unwrapping key password every time the key is used (which is super annoying). Assuming that I can't ask users to do any kind of key management themselves, is there a better option?
rektide 4y ago
Authentication & data-encrulyption have different needs. That it took so so many years for WebAuthn to recognize the need to do more than authenticate, to add "pr", is because it was non obvious what we would do, because so many security folk never want to let the keys out. In a fantasy world, security keys might be high speed decrypting devices, that we could pass data into & quickly get data out of. They, alas, are not so high-featured at present. And, this would come with a host of assumptions. If I want to use group cryptography so a set group of people/keys can decode the data, will the hardware implement that? What do you suggest then? I understand the concern. Do you propose we not allow encrypting data? Do you have some other idea for what we might do today? I hope we can both recognize a tension between hardened security & soft software. Possibility is scary. But imo the progressive approach here, embracing the good, is the only way we get nice things. For folks like offline webapps to be able to use keys to protect themselves & their data is a huge huge win.

dariosalvi78 4y ago

this is excellent news. Combined with passphrases, it makes encrypted web apps possible without the need to remember a password, which is the main risk in applications where the data is encrypted. Last time I checked PRF was in the source code of Chrome, but not available in the official release, but seems like it's going to come. I hope Safari will follow soon.

bawolff 4y ago

This is cool, but the elephant in the room for all these cryptography in the local browser is still there. Namely, you have to trust the server not to send you malicious html and if you already trust the server you might as well do things server side. As the saying goes, security is always about the weakest link.

snowstormsun 4y ago
You could create a local HTML file without a server for it.
- kevincox 4y ago
  Edit: This was a misreading, see child comments. You can't actually do this because file:// URLs are not considered a secure context and the Web Crypto API is only available in secure contexts: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... You would need to run a local webserver and access it over `localhost`.
  - snowstormsun 4y ago
    Yeah, also thought so, but here it says "and file:// URLs are also considered to have been delivered securely." (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...). Am I missing something?
    - kevincox 4y ago
      Hmm, I must have misread that paragraph based on my expectation.
      - snowstormsun 4y ago
        But you're right. Just tried it and it told me: "Uncaught (in promise) DOMException: Public-key credentials are only available to HTTPS origin or HTTP origins that fall under 'localhost'. See https://crbug.com/824383 https://crbug.com/824383" Unfortunate :/

snowstormsun 4y ago

Very cool!

mprime1 4y ago

My own in-browser encryption project/POC: https://mprimi.github.io/portable-secret/ https://mprimi.github.io/portable-secret/ Discussed here: https://news.ycombinator.com/item?id=34083366 https://news.ycombinator.com/item?id=34083366