Live data from Hacker News

Apple Passkey

developer.apple.com

41–50 of 421 posts

Re: Apple Passkey

#41

Earlier quoted context omitted.

As a long-time Safari user who uses keychain heavily in lieu of 1Password or other managers, I probably will migrate to using Passkey because it sounds pretty seamless. But the lock-in point seems like a founded critique. Does anyone disagree with this claim?

I'm not sure this is any more locked in then the parent post is locked into 1password. Moving auth tools is a pain. Anyone implementing FIDO should allow you to enrol multiple devices. As long as the auth consumers allow multiple keys, there's no lock-in. You just need to setup your new device before ditching apple.

Moving auth tools is actually quite simple. I migrated from lastpass to 1password a few years ago and it was very straightforward.

Re: Apple Passkey

#42

Woah this is awesome. Does anyone know if this is using web authn under the hood? Or is this a new spec? Would love to see Pub/Priv replace passwords

Yes, it uses WebAuthn under the hood. Passkeys have technically been available to developers for a while I think but very experimental still. I guess they've begun hitting new milestones.

This is basically the biggest problem with WebAuthn today: the credentials are tied to the browser -- or really whatever application is using WebAuthn, browser or not, name aside -- which means that if you register for a service with Firefox, you have to re-register with Chrome. If the service is designed for it, it might associate multiple public keys to a single "user." So Passkeys are just a pretty natural combination of two things to fix that: "WebAuthn keys, but inside iCloud Keychain." Presumably any apps that integrate with iCloud Keychain can then use them as expected.

Of course you can just export the key material, which in a sense is "all" Passkeys are doing: they're a formalization of how to export and manage those keys in keychain.

But there are still some major issues:

- Enrolling new devices from old ones. This is especially tricky for platform authenticators. For example I register for a website using FaceID on my iPhone, which uses the "platform" authenticator rather than the "cross-platform" authenticator, and now I need to now enroll my Macbook and Windows desktop. They both need new keypairs, because the original account is using a platform authenticator. And the new keypairs might be either platform or cross-platform authenticators. This is especially prevalent on browsers (apps can work around it with a more specific scheme; see below.)

- Similarly: cross-platform software for sharing or syncing credentials. Something like 1password but with WebAuthn support for handling those cross-platform webauthn keys.

Both of those require a lot of software and decision making to get it all working correctly, both on the side of operators and clients. For example, in your own application (not a browser), you could simply use a platform authenticator like FaceID to read a cross-platform WebAuthn credential from iCloud Keychain, which would avert part of problem 1. But in a browser, mac or iphone users would probably like to use FaceID/TouchID, which are only available as a platform authenticator, so you'd have to handle that case of new enrollment.

There are also a million other issues, for example Windows Hello has like a million weird edge cases for how it works in and outside of the browser. macOS seems to be the furthest ahead here with the introduction of Passkeys, and the strong system-wide support for TouchID/FaceID/etc. I do not know what the state of Linux is; presumably you could integrate this with something like gnome-keyring but there's no synchronization service either.

So we're still a ways away from actually eliminating passwords. WebAuthn works today but does need a lot of extra oil to make it smooth, and it's still not a primary authentication mechanism unless you're very careful about your userbase. But Passkeys are a good start and will mean you'll need passwords in less apps, and you'll be able to log in securely more quickly. It's a small but needed step.

Re: Apple Passkey

#43

Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace ( https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ ), making it passwordless login instead of 2FA is trivial and fully supported by webauthn. What’s different about this?

>> Apple has described Passkey as a new kind of credential in the iCloud keychain. The technology is based on the Web Authentication API (WebAuthn), a rapidly emerging standard that uses public key cryptography instead of passwords for authenticating users to websites and applications.

Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect

Re: Apple Passkey

#44

Earlier quoted context omitted.

As a long-time Safari user who uses keychain heavily in lieu of 1Password or other managers, I probably will migrate to using Passkey because it sounds pretty seamless. But the lock-in point seems like a founded critique. Does anyone disagree with this claim?

I'm not sure this is any more locked in then the parent post is locked into 1password. Moving auth tools is a pain. Anyone implementing FIDO should allow you to enrol multiple devices. As long as the auth consumers allow multiple keys, there's no lock-in. You just need to setup your new device before ditching apple.

1Password et al offer many export options including very simple csv

Re: Apple Passkey

#46
This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. The syncing of passkeys in iCloud solves this backup problem.

https://fidoalliance.org/apple-google-and-microsoft-commit-t...

Re: Apple Passkey

#48
post #29

Importantly, if you switch platforms you lose all your auth tokens and have to reauth everywhere. It ultimately is yet another way to do vendor lockin, except it has the FIDO alliance's blessing this time. The competition, password managers like 1password and bitwarden, do not have any sort of vendor lockin. You can freely export your passwords from one manager and into another.

If you can extract tokens from a device, then they're basically passwords, not tokens — i.e. anyone who can hack your device can get them. Tokens only add multi-factor security insofar as they have distinct exfiltration requirements from passwords. Services that properly support MFA should simply support accounts having multiple bound authenticator devices, each with their own private key/seed. In such setups, the pr…

Your first paragraph, restated, is that passwords are superior to tokens.

Your "proper way" is absurd and nonsensical for the vast majority of users. The first time they get burned by this is the last time they'd rely on anything but the one memorized password they reuse everywhere.

Re: Apple Passkey

#49
post #27

Earlier quoted context omitted.

I think Apple encrypts the pass keys locally on your device, then stores encrypted copies in iCloud, which you can download and decrypt on a new device. On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.

iCloud (and anything on iCloud) is explicitly not encrypted, though [1]. [1] https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

That’s iCloud backups, not everything icloud. iCloud Keychain is encrypted (https://support.apple.com/en-gb/guide/security/secdeb202947/...) tho I’mnot sure I trust their escrow system to not escrow data to the gov if asked.

Re: Apple Passkey

#50

Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace ( https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ ), making it passwordless login instead of 2FA is trivial and fully supported by webauthn. What’s different about this?

Passkeys are available for general use in any application through the system frameworks, not just the browser; they simply use WebAuthn under the hood, but it's meant to expand support outside of the browser for more apps in more use cases.

I wrote another comment elsewhere but there are some other issues with using WebAuthn as a primary authentication mechanism right now, especially things like new device enrollment when using platform authenticators (not trivial but not what people are used to), so most people opt to design it as a 2FA mechanism since that normally fits into existing designs easier ("just another auth device" like TOTP or SMS.) So Passkeys will help smooth that a bit for Apple users.

Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled.

If you can use WebAuthn today in the browser and handle new device enrollment and have designed with it in mind as a primary auth mechanism, you're way, way ahead of the curve. This is just Apple's attempt to help kick the can further down the road for their users; you may not need to use Passkeys at all. There's just more to do before we can actually use WebAuthn as the basis to replace passwords in more places.

Post reply on HN