Klox

No, I’m just a professional software engineer that has been in security and privacy for the last ~9 years (unrelated to passkeys). But I am also head of security for my company and rolled out updated hardware keys in the last year, so am somewhat more familiar with the topic as of recent.

I also generally enjoy discussing privacy topics. Even more so when I feel the community’s understanding is off /shrug. Was chilling on my phone while the kids were crashed this afternoon.

Apologies if I miss-stated your point and conflated service’s other arbitrary decisions with what you’re suggesting may happen with passkeys.

Maybe I have one follow-up question, there are a number of websites that just don’t use passwords at all. It’s always one-time codes sent to emails. Where does this fall on your freedom spectrum?

Do you have similar arguments about HTTP 3? QUIC? Web RTC? There’s so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn’t really mean much. Particularly when it’s actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.

Cheers

IMO you’re reading way too much into the value proposition of passwords. Services can “deny service” for arbitrary reasons already with zero consequences, but your idea is that they will ban based on… passkeys? You’ve got people banned from youtube for arbitrary comments. You’ve got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.

You seem to think that’s tangential, but I reject that. It’s kinda the whole point.

I didn’t say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.

Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we’re even getting an open standard authentication, the exact opposite of “walled garden”.

Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret.

The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.

I think we’ve probably hashed out enough of the sides of the argument. Good luck to you.

This is the equivalent of Sony arguing that you never owned any games

It’s far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this “debate” is shaping up closer to LED vs incandescent bulbs.

It’s easy to say passwords are sufficient when you’re one person practicing good op-sec. It’s not when you’re supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were “sufficient”, but the world you and I live in is more complicated. Certain passkeys are transferable, so you’re not even losing out on that capability. Curmudgeon arguments aren’t convincing. Passkeys aren’t “giving power away”. Using passkeys doesn’t mean your giving up freedom. Passkeys have no bearing on the “economic system” and inflation. As far as the IT ecosystem is concerned, we’ve never lived in a more open and capable time. There are so many alternatives to every service (that isn’t tightly coupled to copyright). Of course companies are trying to offer unique products people can’t get anywhere else. None of this has to do with passkeys.

I’ve personally refused to use Apple for decades because of their walled-garden, and it sounds like I’ll continue to follow that principle, heh. But that also has nothing to do with Passkeys, and everything to do with whatever Apple is doing. So I guess, you got me there, Apple sucks.

I will say, I am able to deploy FIDO2 for SSO on Apple devices just fine with both Microsoft Intune and Jamf. But that’s not really Apple’s Passkey vault.

Cheers

Literally just name a service that forces this. If it’s all of them, it should be pretty easy.

I replied to someone else asking the same thing, but we can avoid this infinite-universe syndrome. Which service is forcing a specific passkey provider, and doesn’t offer alternatives? I just need an example to understand because I don’t know of any and I have been using passkeys for awhile, so I’d appreciate being informed.

Which credential manager, and which service is not working with it? Just looking for an example to understand what you’re struggling with. I feel like I don’t have these problems heh.

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.

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.

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.

If my passkeys are spread across dozens of vendors

You’re picking what vendor you want, not picking unique vendors for every unique passkey.

Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?

It depends. It sounds like you just don’t like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can’t do much of that. Maybe your major complaint is that some major OS’s default to hardware-bound passkeys?

My reference to “vendor” meant to include self-hosted/FOSS solutions.

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.

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

This is some weird doom and gloom take on a real improvement in public security that we don’t see very often. Of course there are a lot of stake holders. Of course every protocol is complicated. I run security for a company, and my auth systems mandate attested (i.e., company-provided) hardware keys. You’re not using a passkey on my systems that I’m not providing you. Pretty simple concept, yes?

Do you have any examples of any public service requiring attested keys? No, because it really doesn’t make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

I agree it would be helpful to make the feature set clearer to the end user, but the UX are still a mess across OS and websites. IMO that’s not a reason to not use them.

Passkeys are much more phishing resistant. They apply unqiue-credential best practices. I’ve been managing unique passwords for decades, and passkeys are a great improvement. Very few companies are going to completely remove other forms of auth, and so suggesting passkeys are ruining people’s ability to share passwords is really premature. And even so, companies have been pursuing other strategies for identifying shared accounts much more effectively than shared credentials. Thinking that’s a reason to not use passkeys just tells me you aren’t valuing how passkeys elevate public opsec.

Passkeys are projected to overcome TOTP market share next year. That is honestly amazing. I like the writeup on the features, but this nefarious, conspiratorial narrative doesn’t fit what’s actually happening.

What really boggles the mind is, he isn’t even savvy. He’s literally an idiot. I can only imagine the damage if he was a competent fascist, but maybe that’s what it took to find his people, idk. I just hope his stupidity helps in his undoing. We have a lot to rebuild and time is wasting.