[jjav]

> as a means to avoid locking 2FA to hardware

Tying 2FA to hardware is for most of the common use cases a bad idea. Instead always use TOTP and keep the seed in a secure storage with multiple backups.

If on top of that you like to keep it on your phone to generate the code that way, fine. But at that point you can destroy the phone and it doesn't matter, you'll still have access.

> While I don't like passwords and understand their very real security limitations.

When used correctly, password are a fairly great solution with fewer limitations than competing solutions. By properly I mean generate yourself 128 bits from /dev/random, never reuse and store securely.

[bigiain]

> Tying 2FA to hardware is for most of the common use cases a bad idea.

For me, I don't consider that to be true.

I have a Yubikey on my keyring, and a backup Yubikey in my safe.

Losing my keys is an extremely rare thing (I've never actually lost my keys, closest I've come in the last 30 years is temporarily misplacing them or locking them inside).

I'm happy enough to deal with losing my digital access (via 2FA) tea[orarily under the same sort of circumstances where I've lost my keys. I might need to call a locksmith to get inside my house/car if I've locked them inside, or possibly to get me inside so I can replace the locks (and get my backup Yubikey out of the safe).

When I travel for work, I at least try to make sure I can get into critical systems using TOTP (on my phone and backed up with cloud accessible seeds), to protect against losing th4e Yubikey while abroad. I don't usually bother doing too much of that when I'm on vacation travelling.

[makeitdouble]

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

[highwaylights]

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.

[smaudet]

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

[bb88]

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.

[philsnow]

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.

[est31]

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.

[highwaylights]

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?

[mrsteveman1]

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

[jhugo]

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.

[jwr]

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

[mwwaters]

Any OTP can be phished. There is no automatic authentication that the OTP is being given to the correct party.

A public/private key alone would have a similar issue, but the browser for FIDO keys gives the domain it's actually talking to. The domain is authenticated with TLS or the browser on an uncompromised machine won't send that domain over. The device only signs the challenge with the private key generated for that specific domain.

[oceanplexian]

While you're technically correct any authentication system worth it's salt would ideally see the same user trying to authenticate from two different locations, and prompt the second user for another factor of authentication (Email, etc.) And since TOTP expires it's not like they could sit on the token and use it later.

[mwwaters]

The OTP is already a second form of authentication. An email link would be a third form. I never saw that when I used Authenticator.

Anyway, the user would likely still click the link in the email since they are trying to log in.

[anony999]

TOTP is prone to phishing. Not to mention that you still need a password so it's both insecure and hard to use. You could ague that "When used correctly, password are a fairly great solution " but as passwords are flawed they are exploited and even the "experts" happen to fall victims to "improper" use of passwords.

[jupp0r]

Only if by "never reuse" you mean "never ever log in after the initial login". The problem that WebAuthn/FIDO solves is that even if you read my encrypted communication, you won't be able to use it to gain access to my identity.

[raxxorraxor]

A software implementation of WebAuthn requires a TPM module and to be honest I think privacy and user identification are more of a security problem on the web than being phished for passwords. The problem I see with Fido2 is that they consider a far too narrow corridor of threats.

Sure, for devices that need to authenticate themselves it is a decent or maybe the best solution. For me as a user? I am not convinced. It cannot compete with passwords.

[jjav]

If you've managed to insert your malicious code in a place where you can bypass TLS, secrecy of the password isn't my main concern anymore, as all is lost. It's not a threat model I worry about in most circumstances (sure there's always exceptions).

[clysm]

> always use TOTP

TOTP can be phished or man-in-the-middle'd and isn't as secure.

[41b696ef1113]

Fair, but I am a nobody that is unlikely to be specifically targeted. I am willing to swing the balance towards convenience/backup safety vs utmost security.

[drivebycomment]

A common misconception. After credential stuffing (which 2nf factor protects you from), your biggest threat (for people with 2nd factor) is phishing and keystoke logger, which does not require any targeted attack.

OTP is way less convenient than fido keys, so it's both convenience and security. The only downside is the cost, and the effort required for registering multiple keys which is easily compensated for by the ease of use during authentication than OTP.

[dividedbyzero]

But then I'm not aware of a FIDO key that works with random apps on an iPhone. That's where I, personally, have by far the most logins and spend money. Pretty much all of them support some sort of authenticator app nowadays though.