Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypting Data in the Browser Using WebAuthn

blog.millerti.me

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Encrypting Data in the Browser Using WebAuthn

#11

Post by rektide »

TacticalCoder wrote: post #4

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 h…

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.

Re: Encrypting Data in the Browser Using WebAuthn

#13

Post by snowstormsun »

bawolff wrote: post #10

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.

You could create a local HTML file without a server for it.

Re: Encrypting Data in the Browser Using WebAuthn

#14

Post by fragmede »

rektide wrote: post #11
TacticalCoder wrote: post #4

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 h…

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…

That's not that bad of an idea, given USB 3 data rates, and asic speeds! Kickstarter?

Re: Encrypting Data in the Browser Using WebAuthn

#15

Post by kevincox »

snowstormsun wrote: post #13
bawolff wrote: post #10

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.

You could create a local HTML file without a server for it.

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_...

You would need to run a local webserver and access it over `localhost`.

Re: Encrypting Data in the Browser Using WebAuthn

#16

Post by snowstormsun »

kevincox wrote: post #15
snowstormsun wrote: post #13

Earlier quoted context omitted.

You could create a local HTML file without a server for it.

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_... You would need to run a local webserver and access it over `localhost`.

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...). Am I missing something?

Re: Encrypting Data in the Browser Using WebAuthn

#17

Post by kevincox »

snowstormsun wrote: post #16
kevincox wrote: post #15

Earlier quoted context omitted.

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_... You would need to run a local webserver and access it over `localhost`.

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... ). Am I missing something?

Hmm, I must have misread that paragraph based on my expectation.

Re: Encrypting Data in the Browser Using WebAuthn

#18

Post by snowstormsun »

kevincox wrote: post #17
snowstormsun wrote: post #16

Earlier quoted context omitted.

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... ). Am I missing something?

Hmm, I must have misread that paragraph based on my expectation.

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"

Unfortunate :/

Re: Encrypting Data in the Browser Using WebAuthn

#19

Post by cendyne »

TacticalCoder wrote: post #4

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 h…

For those wondering: the local threat here is a malicious extension can modify the function of navigator.credentials.

While not malicious, this has been shown to be possible by 1Password. See https://www.future.1password.com/passkeys/ and I have confirmed it is possible to modify this function.

JavaScript can be monkey patched, in some ways this is great for polyfills. For other cases this can be a threat.

If browsers had an explicit mechanism to register extension provided Authenticators and locked down a way to modify the original navigator credentials interface, then we may be able to protect the "first" bytes that come back from the authenticator to the application.

Re: Encrypting Data in the Browser Using WebAuthn

#20

Post by nibdo »

kevincox wrote: post #15
snowstormsun wrote: post #13

Earlier quoted context omitted.

You could create a local HTML file without a server for it.

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_... You would need to run a local webserver and access it over `localhost`.

Some dirty solution can be spinning up home server just to download web app to your device and let service workers cache everything relevant. And then turn off server to prevent any updates to app.

This is of course not very user friendly, but might have some use, if you can't or don't want to have running server 24/7 at your home or secure location.

But I don't know, if any browser will let offline apps live for indefinite time.

I was even playing with code signing web apps with help of service workers, which was not bullet proof, but better than nothing. Ultimately it failed on the fact, that you could not prevent/cache/block update of actual service worker file.

Another dirty workaround could be using dynamic one time address for serving service worker only on first attempt and then browser would get 404 on attempts to update service worker. Again, not very useful as you are at mercy that browser won't just purge such "broken" worker.

Post reply on HN