Maybe I'm getting tinfoil-y here, but I think the horribleness is the point: consider how eager Apple in particular is to get people fully enmeshed in their services ecosystem. You're a lot less likely to try to roll your own backup, or otherwise exit the walled garden, if doing so means your entire auth story is irredeemably fucked.

The thing that strikes me about this whole story is that during a lot of the initial discussions of passkeys, a common point brought up on the anti-lockin side was the ability to use non-phone providers like yubikeys. If the actual implementations make this less viable, as discussed in the article, then that shifts power towards lock-in.

Not tin foil — Apples privacy pushes (in some markets) are based on driving up lock in and benefiting their ads and apps. Any consumer benefit is a second order impact.

Tin foil — third parties can be passkey providers: https://blog.1password.com/apple-passkey-api-wwdc/

I'm pretty nervous about Passkeys for exactly these reasons, and I'm still not at the point where I feel comfortable advocating for them, but I'm forced to admit that if anything, Apple has (so far) arguably done the best job of any of the major tech companies at discouraging vendor lock-in with Passkeys.

Blocking attestation requirements, opening up 3rd-party providers earlier, and (I'm not sure if it's released yet) committing to search. I even saw recently that they're releasing Chrome/Edge extensions for Windows to sync keys.

Do I trust it? Ehhh... I still can't generate passkeys on Linux as far as I know, so I'm definitely not going to be using them any time soon no matter what. There are still articles like this pointing out abusable features that I'm not sure should even exist in the first place. And it's honestly just going to be a while for me to get over the weird amount of advocacy that so drastically misunderstands what portability even is in the first place (no, 1Password does not make passkeys portable, standardized export/import formats as a requirement for certification make passkeys portable).

But I think the signs are that Apple is caring a lot more about avoiding vendor lock-in than Google/Microsoft are right now, which is a very weird thing for me to say.

That's indeed scary. Losing your 2nd factor shouldn't block you from accessing your accounts indefinitely. There should at least be one recovery path outside 2FA be it "printed recovery keys", "email recovery", "support channels", or even (despite being fully insecure) SMS maybe with a grace period (like 48 hours). Backing up your 2FA secrets isn't user-friendly at all, and it's even harder after you've started using it.

Yes, those recovery paths are also susceptible to phishing, scam attacks, and they should be designed with that in mind like, for instance, with ID verification, notifications from multiple channels, process delays.

Everyone should go over their Authenticator app and check their recovery options with every account they have there to make sure they don't fall into this trap.

> Losing your 2nd factor shouldn't block you from accessing your accounts indefinitely.

You’re absolutely right and also you don’t have to worry. Everyone who operate auth of any sort will be forced on day one to have reasonable recovery. Nobody is gonna lock customers out because you lost their super-secret private key.

In practice, it goes back to email recovery for 98% of services. This will remain true with passkeys. Just like people forget passwords today, they’ll lose their passkeys tomorrow.

An average user can keep perhaps 5 decent-entropy passwords in their brain, at most. Thus, they can be useful for master passwords and your bank account. Other than that, it’s an elaborate dance of reusing existing passwords, using low entropy ones for low-value services, and for some of us, systematic usage of pw managers. But it’s still a dance, extra steps. And the UX is fragmented at best.

Passkeys has a chance to greatly improve both security and UX of happy-path auth. That’s not bad at all.

Personally, I’m more worried about spec bloat. It looks like tons of knobs and flags already, imagine where we are in 5 years.

I’m also a little worried about public computers, shared devices, borrowing etc. Not everyone has a personal $1000 phone. This whole “my own device” assumption is a first world bias, and the experts should know better.

>I’m also a little worried about public computers, shared devices, borrowing etc. Not everyone has a personal $1000 phone. This whole “my own device” assumption is a first world bias, and the experts should know better.

Exactly. That's why I'm in favour of SMS based auth for really important services like banking and government services. Your phone got broken/lost? Most providers offer replacement sims immediately or in 24h at worst around here. Your phone is broken, but you have an old 20 year old flip phone? Pop your card in there (with a plastic frame) and you can still authenticate (another reason against non physical sim cards).

I saw mentions that SMS is insecure, but I never heard about a credible remote attack that didn't include provider cooperation or taking over your phone. (someone driving to your house and setting up a fake cell tower in your yard doesn't count for most people). Yes, the user experience is annoying to say the least. Consider the current system we have in Poland for government services (taxes, health care, driving agency, benefits). Most people use their bank as the auth provider a typical session would look like this: - go to a gov website, click login, be present with various login options that include personal certs etc, choose your bank from the list - login to your bank's system the normal way (with physical 2fa if you have it, printed keys, or SMS). - then the bank asks you "do you want to provide auth request that contains these personal detail to _gov_agency_A, if yes tick these 4 boxes that absolve us from anything you do down the line - then they send you another SMS to confirm finally authenticating you to the site - you can browse the site etc, but let's say you want to send in a document that requires signing, you fill that document online and they ask you "select your signing provider" (despite already being logged in - you select your bank, you go through two rounds of SMS again to sign the doc - phew... Done

It's rather elaborate and hinges on SMS being secure. Most older people get lost at around "tick these 4 boxes" part, so most likely the whole process is being done for them by a local gov/library/internet cafe employee or a relative.

Is it secure? It's pretty annoying to use, but personally I consider the security adequate. I

SMS is monumentally insecure and any suggestion to use it as an auth factor (much less a recovery mechanism) is wildly irresponsible. Not only is SIM swapping as easy as convincing the teenager at your local phone store that you lost your phone and want to pay his commission when buying a new one, but the SMS protocol itself is unencrypted and you can MITM, or just straight up spoof it with a few grand worth of equipment (see "stingrays" for the professional version of this). This _abolutely_ happens all the time in the EU too.

> I saw mentions that SMS is insecure, but I never heard about a credible remote attack that didn't include provider cooperation or taking over your phone.

Technically correct, but how likely those attacks are seems to depend on the country. While I'm not aware of this being an issue in any EU country, sim swapping is a common thereat at least in the USA. Yes, American providers really need to improve the security of their procedures, but this means that in the current situation the security of any authentication flow based on SMS heavily depends on which country the user is located.

> In practice, it goes back to email recovery for 98% of services. This will remain true with passkeys.

My understanding is that passkeys are really intended for the non-technically-skilled users.

So then, how will passkeys succeed with that audience? A high percentage of them already routinely use password recovery mechanisms rather than keeping track of their passwords. That's an established habit. If they can keep doing that, then why wouldn't they?

Yeah. They’d only switch if it’s discoverable and easy, (perhaps their browser + the website presents the option).

Also, the “forget password” flow itself has opportunities for happy-path improvements that are much more simple than passkeys. I have thought for a long time we should embrace that and lean into it, perhaps change it to a better “magic link” type of flow.

> Nobody is gonna lock customers out because you lost their super-secret private key.

https://www.nytimes.com/2022/08/21/technology/google-surveil...

To be fair I said “customers”.

I pay google. Do you think I'd have a different experience?

You aren't the customer... even if you're paying.

This is definitely good advice.

My point here is to note that "phones" are not a good 2nd factor, unfortunately, because they're not that durable and are kind of targets of theft. So moving to solely rely on phone sounds like a bad idea.

In my case, this was not the end of the world since I use a Yubikey for Google rather than TOTP, so at least my core email services (which represent a huge identity provider) were fine.

(This is also the reason why I could afford to wait to get parts and fix the phone rather than get into some panic mode of having all my digital accounts in a state where I might get locked out at any point.)

Yes, I even use multiple FIDO2 keys for both convenience (some stay plugged in to my machines) and as backups. I find Passkeys convenient too, but the author's points need to be addressed, I agree.

Using "something you have" as an extension to "something you know" is essentially the point of all of 2FA. That's why backup 2FA methods are essential; if it's not extremely hard to get access to your account(s) after you lose all of your second factors, 2FA is pointless and you could've just sticked to just using passwords.

That said, passkeys aren't necessarily second factors; they can be a relatively secure first factor as well, basically acting like long, randomly generated passwords that are impossible to be reversed or to be used in credential stuffing attacks.

See, this where the metaphor breaks down. At no point was the phone "lost". The 2fa tokens are perfectly safe yet there's no way to get to them... even though you still "have" the things, you can't prove you have it.

Which is why having 2FA _solely_ on a phone (like OP implies) is a bad idea. It's a fragile device that can easily render you unable to prove yoh still have it.

If I break my house key I can know exactly where the broken parts are but I still can't unlock my front door. "Broken" and "lost" are the same things here.

Of course you shouldn't rely solely on your phone, that's what the recovery keys any decent website makes you save or print out are for, or the other alternative 2FA options.

> If I break my house key I can know exactly where the broken parts are but I still can't unlock my front door.

This actually isn't true (it's exactly why digital 2FA is different!) If you break a physical key (already much less likely) you can still read the bitting (~ password) off of it. Bring the broken pieces to a competent locksmith and they can originate a new key for you. 2FA doesn't let you do this (intentionally, it's not a bad thing but it does mean recovery is harder).

> recovery keys any decent website makes you save or print out are for

Right, and almost all of the services that I still have on TOTP 2FA are not decently implemented... and do not have the concept of recovery keys (they are actually a somewhat recent inclusion in the setup process)! Sites that are modern enough to have made recovery codes usually also support HW tokens which I would've used instead.

> KeePass, which apparently supports them, who knew...

Bitwarden, too. I no longer have to worry about not having my phone on me, or even having to take it out of my pocket.

>I no longer have to worry about not having my phone on me, or even having to take it out of my pocket.

I mean, I appreciate the convenience but can't help feel like this is cheating...

The whole point of 2fa was to verify you had the 2fa device and this basically defeats that.

"Cheating" is an odd way to put it.

Everyone has their own security risk profile. If someone decides that effective 2FA isn't worth it considering their own profile, that's legitimate. It's not "cheating", it's finding ways to work with the system you have in the way that you deem best for you.

In that case, why bother with 2FA though...?

I use some services that support 2FA that I don't have 2FA enabled on because I don't care if those accounts get hacked/leaked...

Some services require 2FA/MFA whether you personally want it or not.

A 2fa device, perhaps? Access to Bitwarden requires 2fa, and confers on the device I logged into the ability to 2fa for other purposes. I don't leave Bitwarden unlocked for more than a few seconds, so the two factors are "having a device on which I've logged into Bitwarden already" and either "being able to satisfy a biometric sensor" or "knowing my passphrase".

I do also have the ability to bootstrap Bitwarden access on a new device without an existing device -- the two factors then being "knowing my passphrase" and "having my security key".

Yes, KeePass (and KeepassX and KeePassXC) support generating 2FA codes, but it is generally not a good idea to store those alongside your passwords, as if you do those aren't a 2nd factor anymore. You can mitigate the issue by having an encrypted db only for 2FA codes, but I would still advise having those in a completely separate app anyway.

Yep. That's exactly what I did.

Imported the 2FA seeds into a special new db that's in then put in cold storage (unlike the regular db that gets synced around).