These articles never seem to mention the issues with passkeys asthey relate to Apple and other companies like them being in control of you account accessibility. What happens if you're device is list or stolen? What happens if that company decides you can no longer access your account with them?
I'll be using keepassxc and passwords until I'm forced to use passkeys and then I'll use passkeys in keepassxc. No way am I tying my accounts to one of more devices controlled by multinational advertising companies.
Gotta love how they are pushing full steam ahead for the technology and leaving export a to-be-solved problem. Oh, except the cloud vendors have full rights to backup our keys.
I keep hoping for a few senators and or EU officials to have their accounts locked and deleted so they'll pass some laws that make it harder.
Many modern countries have laws that landlords can't just kick you out of their apartment on a whim. Phone companies, Electric Power companies, natural gas companies can't cancel your account on a whim.
Companies that control so much of your life Apple, Google, or that have digital assets that you licensed (Steam, Sony, Amazon, Nintendo) need to not be able to cancel you so easily.
> I keep hoping for a few senators and or EU officials to have their accounts locked and deleted so they'll pass some laws that make it harder.
When that happens you just ring your C-suite golf buddy from the offending company and have it fixed within the hour, right? Why would anyone have any issues? /s
This is exactly why I'm not using passkeys. I even trust Apple's statements that they can't view the key material, however, if Apple ever decides my account is no longer in good standing, I still want to access all my other accounts and as it stands now, you'd lose access to everything.
That helps a little, but it's still a big problem. In particular, consider the situation in which Apple deems you persona non grata, and then your iDevice starts getting old and unreliable. As soon as it dies, you'll be locked out of everything forever since you can't move your passkeys to a new device without Apple's blessing.
Summary: It's a password manager on your phone. You sign into your password manager with something easy like biometrics or a PIN. Then all the 'real' passwords for sites are autogenerated and those are what's sent to sites when you log in.
It's actually neater than that. It's a cryptographic public/private key that is generated uniquely per service. It removes any risk of a login credential being leaked from the sites, as they just have a public key, which is entirely useless to actually auth with.
Passkeys are a nice solution, and it's entirely possible to adopt them without locking yourself into Apple or Google's walled garden. That seems to require you to forgo using your Apple/Google devices as passkeys themselves, unless you use an unrelated app as your passkey manager.
It's interesting seeing how they're being used for lock-in, though. As mentioned in this thread, attestation in the standard will be abused towards that end.
I’ve found that most (not all, but overwhelmingly) sites allow you to enroll multiple passkeys. iOS also automatically supports a third party app for using or enrolling passkeys with.
> And if a passkey were somehow stolen and added to a bad actor’s device, it would become useless because the thief wouldn’t have access to the true owner’s biometrics.
I’m not sure if the author really understands passkeys well, because this statement seems either illogical or false (depending on which platform, device and passkey app one is using).
The biggest hurdle to passkey adoption is going to be, how complicated they are to implement for developers (relative to their advantages). I think that's the much more pressing matter than user adoption.
Can you tell more about it? I never tried to implement it myself, but when I quickly skimmed over relevant info, I didn't find anything particular hard about it. Just some web APIs and some simple crypto (which probably further abstracted in the libraries, but you can use crypto primitives directly if you want).
Doesn't look harder than proper password implementation with hashing, salting, etc.
The #1 issue as far as I'm aware is that there's no good story around portability. It sounds like using Passkey equals vendor lock-in right now.
Idk how representative this is, but there's been some criticism recently, and the response from some of the people behind passkeys implementation seem mostly dismissive of the criticism. I base this opinion after watching this 'debunking' video on the criticism of passkeys by some key players:
I was kind of surprised they sort of looked down on the people with concerns. I didn't really have a strong opinion about Passkeys, before watching this. But after watching, I got the impression they people behind Passkeys are probably smart as hell but perhaps not the best stewards of developing open standards and advocates for the general public.
Disclosure: I'm the author of the first blog post.
I think my personal biggest learning when developing passkey-based authentication is that there's a bunch of useful WebAuthn libraries for every major language / framework. However, these libraries only cover very basic uses cases to login and create a passkey. In real-life applications though there are so many scenarios (users deleting the private key of a passkey, users using non-passkey-ready devices, etc.) that require substantial work on your own and it's not really obvious when you start developing a passkey-based auth solution. It's something that most devs discover on the journey.
I implemented them for a personal project about 6 months ago. The library support is pretty good. The biggest draw for me was that it's easier for the users of my site to use passkeys.
So your auth will then be tied to their API and you'll be paying $30 a month + a per user fee.
What bugs me about that kind of thing is that there have been secure password and oauth implementations that are easy to get started with for years, yet there's this continual edging into this space by people looking to make a buck and able to sell it to management because it has pretty dashboards. My personal take on these paid for solutions is you have to do nearly as much work, and you lose understand and power not having it integrated into your own product. Plus when one of these auth services gets compromised it's a far worse situation.
To be clear, what I meant is starting with mTLS and asking “how would that work?” leads in the direction of Passkeys. With mTLS there are client and server certs and keys to establish unambiguous identity, but how do they get on the personal device for the client? Old-school enrollment was hard, and autogenerating the client key and cert for each website is easy. But there needs to be a way to tell the website “this is a new user” and the like — a protocol. And, since the keys are credentials there needs to be protection for them (Keychain, biometrics).
In other words, they'll use Passkeys as a way to deepen the vendor lock-in. It has already started. For example, try to log into your Apple ID account using Safari, and it works via passkeys. No password needed. That's because Apple created a Passkey for apple.com automatically behind your back.
Now try the same from Firefox with BitWarden, and it doesn't work. And of course, there is no way for you to set up the passkey manually.
There's also no API to export it. Wouldn't it be nice if you could install BitWarden desktop client, and then use it migrate your passkeys? Nope. Not an option. The entitlement to interact with the Keychain for passkeys is only given out to browser vendors.
I'll be using keepassxc and passwords until I'm forced to use passkeys and then I'll use passkeys in keepassxc. No way am I tying my accounts to one of more devices controlled by multinational advertising companies.