Comment by TacticalCoder | Hacker News Reader

Comment by TacticalCoder | Hacker News Reader

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.

Reply on news.ycombinator.com