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.

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

They do. At least Apple implements WebAuthn for Touch ID and Face ID on both its mobile and laptop platforms, using Safari.

Windows also has this; they call it "Windows Hello".

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

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

> 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?

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.

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

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.

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.

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.

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.

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 :/

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.

Another idea would be to use https://redbean.dev/ . For mobile it'd not work, though.

Very cool!

My own in-browser encryption project/POC: https://mprimi.github.io/portable-secret/

Discussed here: https://news.ycombinator.com/item?id=34083366