Hacker News Reader

> I'm happy enough to deal with losing my digital access (via 2FA) temporarily under the same sort of circumstances where I've lost my keys.

To me the critical difference would be that my house keys are single purpose and only serve at a single location. I lost/broke keys a few times in my life, and the only issue was to wait outside the house for a few hours.

I didn't need to authorize 3d secure transactions when paying for the hotel or a taxi, didn't need to authorize accessing my Gitlab account at work, nor validate that I'm really me in the flurry of 2FA services. Nowadays phones and computers are more akin to wallets, and I'm actually more in trouble when losing access to my phone than when losing my wallet.

Absolutely this. I can lose my wallet - I know how much that's realistically going to cost me and I'm protected against fraud and theft regardless, save for the headache of making a few phone calls.

The world really hasn't appropriately quantified our reliance on little black fondleslabs.

To echo the sibling commenter, perhaps this rule applies:

When dealing with hardware, hardware access tokens should be required. When dealing with software, software access tokens should be required.

That way, you never have hardware compromised by remote tokens, and you never lose access to your software because you lost some hardware.

E.g., hardware tokens to login to a laptop, but only a software token (password) to get on a flight.

Of course there are a lot of use-cases inbetween with varying needs (escrow boxes with digital locks, intelligence services who need to verify the identity of their agents when entering/exiting premises), but I posit those come with requirements outside of the "ordinary".

You should have a third in a safety deposit box at a bank or other offsite location.

The issue is if you have a fire and both your keys are melted, you're f'ed.

But the entire issue is that needing to enroll all your keys every time you gain access to a new service is directly at odds with keeping one copy/key in a second, safe location.

If there were one more layer of abstraction where all N of my keys prove that I'm "me" (or proves that I'm some entity) and the "me"-ness is the principal that gains access, that would be nice, but that's directly at odds with not wanting to rely on some third party identity/authentication provider.

Authentication is hard.

That's an issue of the implementation, not of the concept of hardware 2fA. With SSH keys, you don't need them around to enroll them, as they use public key cryptography. I can point someone else to github.com/est31.keys and they can give me ssh access. The actual ssh keys can reside on hardware.

For some reason, this use case was not considered for Webauthn.

Question for you about this as I've often considered it.

What is the life of a yubikey? Do they degrade over time horizons?

The reason I ask is that if you have a backup that you never hope to use it's likely to be accessed only very rarely - which makes me kind of wonder what if your primary yubikey fails in 15 years due to natural wear/tear/degradation due to the passage of time and your backup has succumbed to the same problem due to being just as old?

It's solid state electronics, if not subject to any external factor (which should not be common to both) it will just keep working on any timescale that matters here.

I've carried one in my pocket for ~10 years without a problem, now I want to replace it because it's too old to support ed25519. That's likely a fraction of its useful hardware life.

> What is the life of a yubikey? Do they degrade over time horizons?

Not that I could see over about 4 years. I've been using one YubiKey (USB-A) for over four years now and a second one (USB-C) for over two. Each has been carried with my keys for at least two years.

But the right approach anyway is to use this excellent tutorial: https://github.com/drduh/YubiKey-Guide and generate your keys yourself, storing a backup in a secure location. This is what I do — so even if my keys get completely destroyed, it will be possible to recreate them from backup.

> What is the life of a yubikey? Do they degrade over time horizons?

I don't think it's an issue in practice, certainly not for someone using them as they were intended, even heavily, but in theory a JavaCard implementation (like most of the smart card ecosystem, Yubikeys are still JC devices as far as I know) could "wear out" from use because of the way they work internally[1].

I've never personally seen that happen, and all of my Yubikeys still work, even the ones I bought over 10 years ago which were used far more heavily (20-30 ssh/gpg/piv operations per hour, every day, for years) than most people would use a FIDO key.

I've only managed to break other manufacturers smart cards by severely misusing them (as a USB-connected Linux HWRNG, I doubt the RNG command was designed to be called every few seconds for years).

[1] The JavaCard standard requires certain (all? I can't remember, it's been a while) objects in applet code to be written to persistent storage (meaning flash/eeprom), which has endurance limits. In practice they're not expected to be treated as permanent storage devices, if a card fails it's supposed to be replaced with another, revoke the old key pairs, register the new ones, etc.