Happy to discuss a few points you've brought up.

it’s that none of them are consumer advocacy groups.

I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is "notable" -- great, noted. I hope that doesn't mean they were using it as an argument for "Do not use [passkeys]" (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don't know what a consumer advocacy group would suggest differently here -- DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.

The GraphenOS example is a good one.

I went and looked for what you were referring to and didn't find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn't seem related but maybe I am missing something.

I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:

1. People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That's a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn't happen.

2. Email is the most important mechanism of communication for people's security. Bank and financial accounts, paid services, government notices... they are almost all through email. The idea that they will vendor-lock email to specific hardware... it's not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. "Requiring" an attested phone would kill a massive use case.

3. People already feel locked to their email provider -- it's extremely difficult to change all contacts you have to a new email address. Passkeys don't change that. Phone hardware doesn't change that. So I'd say it's just a continued problem, and not a reason to not use passkeys.

4. The FIDO Alliance had like three phone manufacturers out of 250 members.

Overall, I don't see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there's no reason it would be "requires my X branded phone". These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?

passkeys are giving away too much control to the second party.

There are already dozens of hardware and software passkey vendors. It's honestly amazing how little lock-in there is. There's a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What "control" are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.

Cheers

Thanks.

There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.

Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.

Widevine DRM, Google Play Protect, etc…

I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem

I can only speak for myself, but I hold all of those values you claim. I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it's a baseless claim that passkeys lock people out of their own control/infrastructure. I think people conflate non-transferable, TPM passkeys with passkeys. Just don't use that if you don't want to.

FWIW, passwords were never "yours", they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it's not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format -- if they are the type that can be exported.

I can only continue repeating that the passkey spec is public and transparent. If the service is not supporting passkeys in a way that you want to use them, then complain to that service. I don't decide that service X doesn't support transferable passkeys, but they should.

DRM and other gate keeping efforts, IMO, are tangential to passkey support. Passkeys are fine, vendor-locking and walled gardens are not.

I haven't found this to be the case in practice (IE passkeys are plenty portable). I've successfully used passkeys on multiple browsers, OS's, and apps, all stored using a FOSS password manager (keepass). Any FOSS password manager that is either self-hosted, or syncs, should work just as well with passkeys as it does for regular passwords or TOTP.

I think there's somewhat of a conflation of concerns. It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager. I just want it to be simple to migrate my massive number of passwords, right? I need to bulk export + bulk import. EASY. But... what if your first password manager has a bug in the seed generator? Oops, you have to rotate 500 passwords now... there is no easy, off the shelf solution for that. It's basically the same for hardware-bound passkeys. If you generate hardware-bound passkeys, you're not going to simply replicate them to another hardware-bound passkey. The whole purpose of that type of credential, is to make it hardware-bound. There are a lot of meaningful reasons to do that from a security POV.

Now, I think what probably needs to be made clearer, is that if you do want that kind of credential, you shouldn't be using TPM-backed passkeys. You should be purchasing independent hardware (FIDO2 hardware keys) or only make software+transferable passkeys. Personally, I have several hardware keys and I register them with one being a backup. If the vendor posts a vulnerability notice that there's some big gap in their hardware, I will have to go and rotate every passkey. I know that is what I am signing up for, but maybe not a lot of people do.

FWIW, the article may be a bit outdated. I'm not a FIDO expert by any means, but there have been improvements in the spec to help define how to transfer passkeys (CXF and CXP). The situation should be better than 2024, but if you're using TPM-locked passkeys, you're just in that locked box already.

Yeah good question, and more people should give consideration to account recovery. Are you referring to recovery PINs? There's really a couple aspects to the design:

1. They are single use -- this is really just to make sure users aren't coming to rely on these PINs. It's also a simple fact that passwords that are typed are more likely to be leaked than passwords that are never typed. Single-use do a great job taking advantage of that.

2. They lock after very few attempts and generally have more aggressive anti-hammering/brute force/backoff protection than password/TOTP attempts.

3. They help get new devices registered without already having a passkey.

Securing/backing them up has the same challenges as TOTP secrets management. Storing them in a password manager is what I generally do, but there are a few that warrant keeping offline completely and storing it in a fire-resistant/water-proof enclosure.

The other reliable recovery is just registering several passkeys and keeping one as the recovery credential. I always issue two hardware keys per employee, and we have a pretty lax policy if more are needed or replaced. We also don't allow employees to recover their own accounts. If we're at that situation, we need to know in order to help. And FWIW, I don't use biometrics.

the vast majority of mine are +50 characters - you are just wrong. the services which strictly limit the length are rare and their security is suspect since they should be hashing your input anyway

I default to using 128 characters because that's the max for the password generator I use. A surprising amount of accounts are OK with that, like more often than not. I have pared accounts down massively since using a password manager though, and use privacy respecting services when possible, so I may be self selecting here.

Most do. Source: I usually use passwords that long.

Maybe 1 in 10 don't, and I find that annoying since 32 characters containing only lowercase real words and spaces has several times as much entropy as 8 characters of random mixed case letters, numbers, and symbols.

I've experimented with this and haven't had a problem. However, I was using the open source fork Vaultwarden and only the browser extension(s).

Haven't had that issue using Vaultwarden backend and bitwarden android, Firefox and Chrome extensions.

Hmm I haven't had that issue, I have a lot of passkeys saved and they sync fine and are usable in Firefox on my laptop as well as with apps on my pixel 5 running lineage. I have noticed that occasionally an app will refuse to give me the option to create a passkey in bitwarden, but I just skip those and I haven't noticed that issue in a while.

Have you checked whether the site entry shows the passkey on both devices? On mine it'll say "passkey created ..." on both devices in the vault.

Oh that's good to know, I didn't realise TOTP was vulnerable on the server side. I'm still going to steer clear of passkeys for now though.

Thank you so much for clearly and concisely explaining how TOTPs are kept in sync between server and user. I KNEW the answer couldn't be "magic".

No problem until they make every other method more and more difficult. Which is already happening.

I only use passkeys when the alternative is an onerous song and dance.

Really there is no way big tech can force me to use their app? Ok so you know how the open standard for TOTP is a six digit code computed from the time and shared secret? Well every student at the university of California and every employee at many companies across the US has to use an Authenticator app called duo which uses a 3 digit code generated by the app at the moment you attempt to log in. How does it do that? No idea it’s closed source. Is it even a formula like the TOTP open standard? Probably not I’d guess duos servers just send a code to both sides when you attempt a login. And would you look at that suddenly we have TOTP that I can’t write myself and I’m forced to use some shitty app.

Now I do recognize the point you’re making but I want to emphasize it’s not about attestation being in the metadata or not. It’s about open standard compliance. As the open standard is written even if you have to have hardware attestation you can build the passkeys yourself (because this is functionality all password managers are quickly starting to have) and frankly having each passkey being device locked is good security practice to protect you from credential stealers and related malware. You’d still be in control and you could still sign in to as many devices as you want. You’d just need to make a new passkey for each one if you don’t wanna sign in the old fashioned way with a password and dual factor and such.

The abuse scenario you describe would require a departure from the open standard. Is this possible? Of course. As I said some companies already do this with TOTP. But I don’t see that as a structural fault of passkeys that TOTP somehow doesn’t have like the article tries to imply. Both only work well for the consumer if the open standard is adhered to.

See I bought a couple of yubikeys, but have zero passkeys becuase I've yet to encounter any service that lets me choose to store their passkey on said yubikeys. How do you do it?

Seems to me that if I could tie them to yubikeys (ideally on two keys), remote attestation wouldn't risk me allowing any third party to assert influence or control over my choices of technology - is that right?

Amazon is probably the most visible example of trying to create passkeys all the damn time, but it never offers any user choice about where this passkey would be (my best guess is that its on the computer and tied somehow to my login). I'd happily use passkeys with yubikey, but I'm not willing to set up a different passkey on each computing device I use. Thatś a housekeeping/maintenance headache I dont want or need and it would be made all but impossible if I give up visibility and control over what devices are 'authorised' and how.
I hate to think how many people have inadvertently set up passkeys on devices that they rarely use.

Problem is passkey generation, expiration logic, etc., is often not well protected, so if a hacker is able to get it, they may not be able to target a specific account, but they can target random accounts with semi-bruteforce since there's no username to limit tries against or lock the account if there's too many tries. Just use a botnet and start throwing probable keys at it and you're likely to get a few.

Also, with a password repository, I protect that as exceptionally as I can, but I can always change my passwords and would do so of that was compromised. But I'm not talking about the passkeys of an individual being stolen, I'm talking about a compromised site having very little way of determining of a hacker has gotten enough information to narrow brute forcing down to a relatively manageable level with a botnet and using that to access random accounts for personal information scraping. And the user may have no idea it's happened to them since the bad tries never were associated with any login.

Sounds like a turbo encabulator.

Also, that website is full of sand traps. Every time I accidentally mouse over something, a huge menu covers up the definition.