[al_borland]

>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced.

This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you.

I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done.

A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.

While I don't like passwords and understand their very real security limitations. I'm also not a fan of my phone becoming my identity.

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

[hoorible]

Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.

[varenc]

You can use SMS as a backup 2FA to login to your online Apple ID account, but that's not enough to access the iCloud keychain.

The decryption keys for that data are only stored on your iDevices. It's E2EE after all. So while you can access your Apple account via the SMS 2FA backup, you won't be able access your actual iCloud Keychain data/passkeys without some sort of access to your iDevices. (it might be sufficient if they're online somewhere and you have their login credentials?)

A bit confusing, but if it really is E2EE, then you can see why SMS alone wouldn't be enough to recover your Passkeys.

[FateOfNations]

There is a procedure for recovering access to the E2EE data in the event that you no longer have access to any of your Apple devices.

https://support.apple.com/guide/security/secure-icloud-keych...

[chrishas35]

> Apple’s implementation uses SMS as a backup.

I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.

[daveoc64]

I don't think they can get rid of it, as not everyone using Apple's services has a supported Apple device.

They don't offer a standard like TOTP, so SMS is the only option.

[r00fus]

Is it possible to disable SMS at the carrier level?

[bloppe]

2FA is as strong as the strongest link, not the weakest. You need both factors, not either factor.

In this case, it's just that one of the factors has a weak backup option.

[avh02]

Until the "try another way" option is a weaker form of 2fa, like sms.

[al_borland]

So if I have a single device, a phone, and it gets stolen... what is the path to get my data back? And in the interum, if the theif swaps my SIM into another phone they now have my 2FA via SMS?

This all seems very messy when bad things happen.

[MBCook]

They solved this with a feature called “Recovery Contacts” in iOS 15(?). You can set them up and they’re people who cannot access your account but can help you regain access if necessary (such as your one device case).

I think you still need to know your password, but that’s pretty reasonable.

They also added a similar feature to allow you to get into a loved one’s account/phone after their death if they set it up.

[fauigerzigerk]

>They solved this with a feature called “Recovery Contacts” in iOS 15(?).

That doesn't solve it for me. None of my trusted contacts has an up-to-date Apple device.

[r00fus]

I think the answer to the "stolen SIM" from Apple may just be "use e-SIM".

I agree the inability to remove SIM as backup 2FA method is troubling. I would sign in blood any liabilities to be able to remove SIM as a backup auth.

[avh02]

Sim cards can have pin codes

[Spiritus]

Get an e-sim

[raxxorraxor]

A password can very well be as secure as the ownership of a device. Compared to most 2FA schemes I love them because they are simple. I think if people are trained adequately it isn't an insurmountable barrier. But the industry never did develop good practices and bad ones are still around.

I don't like to have my key chain in the cloud at all. Loss or lack of access is far more likely this way. I already hate that services profile my device or location.

[madeofpalk]

> I think if people are trained adequately

When will this happen? How will it happen?

Websites/services just make this way too difficult. Banks will host official services (that require login) on domains like www2.citionline.com with no way to know whether it's legit or not.

Apple has a marketing site at offers.appletvapp.apple which leads to prompts to sign up - how is any normal person supposed to understand this is legit? That domain is virtually indistinguishable from some phishing site at apple-iphone-offers.online

[nicoburns]

Password managers like Bitwarden can do TOTP with syncing. Doesn’t help with Apple though which uses non-standard 2FA. I actually have some accounts using SMS still, because I can fairly easily get a replacement sim if the device is lost.

[spacedcowboy]

You don’t need to have your second device to get past 2FA in a disaster scenario. You can phone up Apple Support and as long as you know the code you use to unlock your old phone (which is a reasonable ask), you can regain access to your iCloud account, and hence to your iCloud Keychain/devices.

Apple don’t know your unlock passcode, so they can’t do it for you, but this is designed to cover the “my house burnt down with all my devices inside” type of scenario, or your own “I no longer have access to a device”.

[traceroute66]

> When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done.

As per the Apple FAQ[1]:

"you can get a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign-in screen and choose to send a code to your trusted phone number. "

[1] https://support.apple.com/en-gb/HT204915

[solarkraft]

Oh wow. I thought those keys were the foundation for real end-to-end encryption, i.e. Apple doesn't have access to them. Does this mean their "E2EE" is basically fake?

[traceroute66]

> Oh wow. I thought those keys were the foundation for real end-to-end encryption, i.e. Apple doesn't have access to them. Does this mean their "E2EE" is basically fake?

I'm afraid I don't follow.

I don't know what you're talking about, but I thought I was talking about an the manner in which Apple provides an alternative to Apple hardware 2FA.

i.e. "normally / if available", Apple will do 2FA on your account by virtue of you being already logged in on another device. HOWEVER if that device does not exist (or you only own one Apple device), then as per my FAQ link, Apple DO provide an alternative mechanism that DOES NOT rely on the existence of a secondary Apple device.

This methodology is no different to any other 2FA alternative mechanism (e.g. "backup keys" or other websites/services that also use phone/SMS as backup, e.g. Microsoft Authenticator).

Thus I believe I was correctly answering the OP's question AND I don't see any problem with the way Apple does it because in practical terms its no different to anyone else in terms of "backup" for 2FA.

Thus I've no idea what you're claiming to be "fake", and I'm not sure if I want to be drawn into that discussion because it sure sounds like Apple bashing that is not factually supported.

[tedmiston]

> A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.

I've heard this approach of cloud-based second-factor auth keys called "1.5FA". It's probably enough for most people, most of the time.

That said, in the case of a broken phone and away from your computer, you'd still need either a second device that's already logged into your vault or a backup recovery code. That's a good thing for all of us to keep in mind the next time we're traveling.

[FpUser]

>"I'm also not a fan of my phone becoming my identity."

I see that many people are slowly moving this direction and just can't fathom why do they fall for this corporate trap.

[mobiuscog]

Convenience. It's the reason for most mass-market uptake.

[userbinator]

They don't know any better.

[lathiat]

Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days: https://support.apple.com/en-us/HT204915

[Thorrez]

>You're forced to have 2 devices

Do you consider a U2F key a device?

And it's not exactly 2. It's n+1, where n is the number of 2FA physical factors you expect to lose/break. If you expect to lose/break 0, then you need 1. If you expect to lose/break 5, then you need 6.