Why do security keys store secrets unencrypted or poorly encrypted? | Hacker News Reader

Why do security keys store secrets unencrypted or poorly encrypted?

14 pointsfilipzyzniewski9 comments

I have started designing infrastructure for my projects and I think having a proof of identity is a good starting point.

I have looked at devices like https://www.yubico.com/products/yubikey-5-overview/, https://onlykey.io/, https://shop.trezor.io/product/trezor-model-t and https://asicvault.io/ and got surprised by the general approach to keeping secrets secret.

Why do these devices focus (to a varying degree) on physically protecting secret data from retrieval from permanent storage rather than having the user enter a strong passphrase and store the secret data encrypted with a key encrypted with this passphrase?

The device could be equipped with power capacitors and could run a RAM wiping procedure on each disconnect from the host device (also after a configurable time [e.g. from 0 to x hours] after last use). Would this not make reliance on strong physical protections less necessary?

The passphrase should of course be supplied without involvement from the host via either a builtin keyboard or (less secure) by the device acting as an USB host for a normal consumer keyboard (so the device would have two USB ports - one implementing a USB device and another a USB host).

Sure, it's less convenient than just tapping a Yubikey, but OTOH public key authentication could be used instead of 2FA (the user would type in the passphrase on their security key rather than in a service's login UI) for web services.

I think you have the wrong perception on how YubiKeys add to your security.

2fa means you use different proves. A password is proof that you know a secret. A YubiKeys outputs proof that you are in possession of this device. The tapping is there to avoid rootkit based exploits (e.g. streaming the data to another device on demand).

Adding a password to you YubiKeys does not add anything to this. It does not strengthen this.

to clarify: the biggest concern for these devices is that the prove of ownership is leaking. And an easy way would be to copy the device.

Anything that copies the identity (private key) to a physical key is broken because the identity could be copied before it is on the key.

That's why you create a cryptographic keypair on the device, and the device does not offer to extract the private key.

It must be impossible to clone the key. When you read articles that claim 100% phishing failure due to these YubiKeys then that's because phishing is copying secrets. And you simply can't for the key. You have to physically steal this device.

And then there is also a human aspect. If you have something that is convenient and 100% successful then don't make it less convenient. You risk that people try to circumvent it.

I like to think of passwords as proof that you’ve exposed your secret.

I tried to do a startup based on an idea like this, but it’s difficult because you essentially have to have keyboard input into the device, which means you now have to trust the keyboard. And once you have a passphrase it is confusing as to whether you should make a 2FA device or a password manager. But it is possible, on a technical level, because embedded devices now have enough RAM to run “effective” versions of argon2 or scrypt or whatever may be preferable at this time.

> Sure, it's less convenient than just tapping a Yubikey

A keyboard on a tiny Yubikey? Are you joking?

The whole point is to have something that is easily usable, without evoking the horrible "IT security came up with another way to make our lives worse" emotion.

Also, the Yubikey is the "have" part in the multi-factor equation. It's no big win to have it do more. You can always prompt for a password in your application, in addition to the touching of the key.

And that's how most everyone does it, anyway.

Yes. It’s poor practice. The FIPS 140 standard has been chip and pin for 30 years now. Maybe ‘somebody’ doesn’t want this to be in common use. It’s absolutely standard in any serious security environment, fully compatible with active directory, enables unhackable web logins via SSL in Apache, and the device costs less than $5. Its atrocious that web sites still use logins that any insider can steal, or any outsider can spoof. U2f is better but not good.

As said elsewhere, for U2F/Webauthn, the biggest threat is creating a duplicate of the key rather than third parties using the physical key. The idea is that physical security plus needing to know the account password should be sufficient security for that use case. Yubikeys in smartcard or FIDO2 mode do use PINs or passwords to protect the private key, since in that case the private key+PIN are the two factors.

FIDO2 supports "PINs" (can be a passphrase) but it's opt-in because you have to distribute devices to users - if you put a default PIN, it's like having no PIN.

So it seems to me that what you're asking is there already. Just maybe not advertised as it should. Am I missing something?

You've forgotten the most common hardware security module, of which there are billions: the SIM. Good luck putting a keyboard on that.

Reply on news.ycombinator.com