About Passkey – the password-free tech Apple is betting on | Hacker News Reader

About Passkey – the password-free tech Apple is betting on

fastcompany.com

30 pointsgautamsomani36 comments

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.

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.

Passkeys are stored in Keychain which is stored locally and synced (unlike Sign In with Apple which requires an active Apple ID)

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.

You do know that you can swap a passkey for another using a new provider?

It's not like if you create a passkey on a Google device, you're forever bound to Google.

Isn't that like saying that password managers don't need to support exporting, since websites support changing your passwords?

Many sites stupidly only allow you one passkey or FIDO U2F key.

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.

you can have multiple passkeys i passkey everything i can on ios and then also add my yubikey

> 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

> and then I'll use passkeys in keepassxc.

If the auth cartel deigns to allow it:

https://github.com/keepassxreboot/keepassxc/issues/10407

https://news.ycombinator.com/item?id=39698502

https://news.ycombinator.com/item?id=39706876

Attestation makes passkeys inherently anti-user, full stop.

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.

Also shoutout to Bitwarden. Passkey doesn't have to mean lock-in.

I was having trouble understanding what they are.

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 have terrible branding, with passkeys being used to describe multiple things over time and depending on what you're reading.

Passkeys are similar to Apple Pay. Instead of authorizing a financial transaction, you are authorizing a login.

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.

Probably worth checking out: https://www.hanko.io/ "Open source auth management for the passkey era"

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.

Not an endorsement (haven't read it fully!) but this article goes into some of the difficulties with implementation:

https://www.corbado.com/blog/passkey-implementation-pitfalls...

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:

https://www.linkedin.com/events/debunkingmisconceptionsabout...

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.

I'd be really interested in your implementation. Can you share a link or some code?

I'm inebriated and curious, allow me to ask the laymans' question:

Is this just public/private keys with apple managing the keys and the security of the keys via their auth stack?

Essentially, yes.

So why isn’t it just mTLS?

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

It's an open standard and supported by most major browsers. But yes there is currently a vendor lock-in, regardless of which vendor you start with.

Yeah, Apple's gonna Apple.

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.

Why would you need to "migrate" a passkey, you can just log in to wherever it is and create a new one instead of the old?

Because it's tiresome if you have hundreds of sites. You'll need to run password recovery flows on all of them.

Reply on news.ycombinator.com