Ask HN: Why does YubiCo need my private key?
Hi HN,
I've been reading up on YubiKeys, which seem to be well-regarded on HN. When doing my own research, I discovered that the default authentication method requires a copy of the private key to be stored on a validation server[1] (YubiCloud, by default). This can be changed to a private validation server, however that would also need to have a copy of the private key in order to work.
My question is: why is this necessary at all? Surely the same functionality could be achieved with public-key cryptography rather than requiring the private key to be uploaded[2] to a validator.
[1] https://docs.yubico.com/yesdk/users-manual/application-otp/yubico-otp.html [2] https://upload.yubico.com/
27 comments
[ 1.7 ms ] story [ 297 ms ] threadStop shipping your org chart like it's a flatpack box of IKEA parts for your customers to put together.
The OTP key is separate from other keys that enable WebAuthn.
Also, please don't use Yubikey OTPs. While they can't be brute forced like TOTPs, they can be phished. There are better technologies to implement.
Just use FIDO2. I have no idea why OP is trying to use the YubiKey OTP protocol, which is legacy.
Now that FIDO2 has been mentioned as something that solves this issue, it turns out there's another tool called the "YubiKey Manager", which allows you to configure/toggle various "applications" on a key, including Yubico OTP and FIDO2.
Hetzner Cloud and Bitwarden use Yubico OTP.
[1]: https://github.com/drduh/YubiKey-Guide
> Transferring keys to YubiKey using keytocard is a destructive, one-way operation only. Make sure you've made a backup before proceeding: keytocard converts the local, on-disk key into a stub, which means the on-disk copy is no longer usable to transfer to subsequent security key devices or mint additional keys.
The order of backup, transfer matters. I did a similar setup years ago before that guide existed (or before I knew about it) and ended up with a backup of nothing. Lol. Thankfully I didn’t used the key to sign anything too important and I learned the value of testing your restore procedure for everything before relying on anything.
Backup key should have separate private key and all websites should allow adding multiple keys.
The DrDuh guide suggests generating the key offline (e.g. a live iso), and having a backup of that private key material somewhere. In DrDuh's guide, the 'master' private key is never accessible on an online machine, only the private subkeys.
An advantage with YubiKeys is that the private key material can't be re-accessed, so putting the 3 private subkeys on the YubiKey is even nicer.
I'd found it hard to visualise, so came up with these diagrams: https://rgoulter.com/blog/posts/programming/2022-06-10-a-vis...
Yeah tell that to Paypal and a ton of other sites :(
Better that then wait until it was too late.
https://www.passwordstore.org/
1. The Yubikey specific OTP was turned on by default on both of my keys. The particular default is a Yubikey protocol. An alternative OTP is the Challenge-Response HMAC [0] implementation which I use with Keepass.
2. The OTP is not necessary, and most websites use FIDO2/WebAuthn anyways. It would only be "necessary" if the service used that particular Yubikey OTP protocol instead of FIDO. I use the FIDO2 functionality as my preferred 2FA, falling back on the Yubikey app for TOTP keys.
[0]: https://docs.yubico.com/yesdk/users-manual/application-otp/c...
Factory resetting the key will not reset the Yubi-OTP private key (which is burnt into its memory and never leave the device), but it will however invalidate any FIDO2 credentials (either resident and non-resident) from the key.
The Yubi-OTP private key is also one way of certifying that the Yubikey is genuine.