Apple Passkey | Hacker News Reader

Apple Passkey

developer.apple.com

817 pointssamwillis398 comments

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

>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced.

This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you.

I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done.

A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.

While I don't like passwords and understand their very real security limitations. I'm also not a fan of my phone becoming my identity.

> as a means to avoid locking 2FA to hardware

Tying 2FA to hardware is for most of the common use cases a bad idea. Instead always use TOTP and keep the seed in a secure storage with multiple backups.

If on top of that you like to keep it on your phone to generate the code that way, fine. But at that point you can destroy the phone and it doesn't matter, you'll still have access.

> While I don't like passwords and understand their very real security limitations.

When used correctly, password are a fairly great solution with fewer limitations than competing solutions. By properly I mean generate yourself 128 bits from /dev/random, never reuse and store securely.

> Tying 2FA to hardware is for most of the common use cases a bad idea.

For me, I don't consider that to be true.

I have a Yubikey on my keyring, and a backup Yubikey in my safe.

Losing my keys is an extremely rare thing (I've never actually lost my keys, closest I've come in the last 30 years is temporarily misplacing them or locking them inside).

I'm happy enough to deal with losing my digital access (via 2FA) tea[orarily under the same sort of circumstances where I've lost my keys. I might need to call a locksmith to get inside my house/car if I've locked them inside, or possibly to get me inside so I can replace the locks (and get my backup Yubikey out of the safe).

When I travel for work, I at least try to make sure I can get into critical systems using TOTP (on my phone and backed up with cloud accessible seeds), to protect against losing th4e Yubikey while abroad. I don't usually bother doing too much of that when I'm on vacation travelling.

Any OTP can be phished. There is no automatic authentication that the OTP is being given to the correct party.

A public/private key alone would have a similar issue, but the browser for FIDO keys gives the domain it's actually talking to. The domain is authenticated with TLS or the browser on an uncompromised machine won't send that domain over. The device only signs the challenge with the private key generated for that specific domain.

TOTP is prone to phishing. Not to mention that you still need a password so it's both insecure and hard to use. You could ague that "When used correctly, password are a fairly great solution " but as passwords are flawed they are exploited and even the "experts" happen to fall victims to "improper" use of passwords.

Only if by "never reuse" you mean "never ever log in after the initial login". The problem that WebAuthn/FIDO solves is that even if you read my encrypted communication, you won't be able to use it to gain access to my identity.

> always use TOTP

TOTP can be phished or man-in-the-middle'd and isn't as secure.

Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.

You can use SMS as a backup 2FA to login to your online Apple ID account, but that's not enough to access the iCloud keychain.

The decryption keys for that data are only stored on your iDevices. It's E2EE after all. So while you can access your Apple account via the SMS 2FA backup, you won't be able access your actual iCloud Keychain data/passkeys without some sort of access to your iDevices. (it might be sufficient if they're online somewhere and you have their login credentials?)

A bit confusing, but if it really is E2EE, then you can see why SMS alone wouldn't be enough to recover your Passkeys.

> Apple’s implementation uses SMS as a backup.

I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.

So if I have a single device, a phone, and it gets stolen... what is the path to get my data back? And in the interum, if the theif swaps my SIM into another phone they now have my 2FA via SMS?

This all seems very messy when bad things happen.

A password can very well be as secure as the ownership of a device. Compared to most 2FA schemes I love them because they are simple. I think if people are trained adequately it isn't an insurmountable barrier. But the industry never did develop good practices and bad ones are still around.

I don't like to have my key chain in the cloud at all. Loss or lack of access is far more likely this way. I already hate that services profile my device or location.

> I think if people are trained adequately

When will this happen? How will it happen?

Websites/services just make this way too difficult. Banks will host official services (that require login) on domains like www2.citionline.com with no way to know whether it's legit or not.

Apple has a marketing site at offers.appletvapp.apple which leads to prompts to sign up - how is any normal person supposed to understand this is legit? That domain is virtually indistinguishable from some phishing site at apple-iphone-offers.online

Password managers like Bitwarden can do TOTP with syncing. Doesn’t help with Apple though which uses non-standard 2FA. I actually have some accounts using SMS still, because I can fairly easily get a replacement sim if the device is lost.

You don’t need to have your second device to get past 2FA in a disaster scenario. You can phone up Apple Support and as long as you know the code you use to unlock your old phone (which is a reasonable ask), you can regain access to your iCloud account, and hence to your iCloud Keychain/devices.

Apple don’t know your unlock passcode, so they can’t do it for you, but this is designed to cover the “my house burnt down with all my devices inside” type of scenario, or your own “I no longer have access to a device”.

> When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done.

As per the Apple FAQ[1]:

"you can get a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign-in screen and choose to send a code to your trusted phone number. "

[1] https://support.apple.com/en-gb/HT204915

Oh wow. I thought those keys were the foundation for real end-to-end encryption, i.e. Apple doesn't have access to them. Does this mean their "E2EE" is basically fake?

> A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.

I've heard this approach of cloud-based second-factor auth keys called "1.5FA". It's probably enough for most people, most of the time.

That said, in the case of a broken phone and away from your computer, you'd still need either a second device that's already logged into your vault or a backup recovery code. That's a good thing for all of us to keep in mind the next time we're traveling.

>"I'm also not a fan of my phone becoming my identity."

I see that many people are slowly moving this direction and just can't fathom why do they fall for this corporate trap.

Convenience. It's the reason for most mass-market uptake.

They don't know any better.

Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days: https://support.apple.com/en-us/HT204915

>You're forced to have 2 devices

Do you consider a U2F key a device?

And it's not exactly 2. It's n+1, where n is the number of 2FA physical factors you expect to lose/break. If you expect to lose/break 0, then you need 1. If you expect to lose/break 5, then you need 6.

It's strange and rather unfortunate to see this constant reinvention of authentication methods. Asymmetric encryption as used in things like SSH keys and TLS client authentication have been around for decades, are very much standard, and the only changes to those have been stronger algorithms and longer keys. Smartcards as hardware secure elements have also been around for a long time. I'm not sure how much of a conspiracy theory it is to say that things like this are merely attempts by Big Tech to stronghandle everyone into their own idea of "standards" and run away from all the smaller players in the industry, but I'm sure that we had everything necessary for "passwordless authentication" two decades ago, or at least methods in which it's not necessary to send a password to the authenticating server nor store them there.

Its absolutely not a conspiracy theory, but it is a bit more complex than that there is was a coordinated push - there was a big push a while back from the likes of Microsoft to e.g. eradicate ssh credentials - in favor of stuff like AD (ugh, why?), specifically wrt to git clients. I know, GitHub still takes ssh (they'd break too many people otherwise), but places started moving towards AD, or "password manager integration" clients.

Part of that is on the "security contractors", who are objectively snake-oil salesmen (when you make a living selling people publicly, freely available, publicly supported software, and charging 6 figures for it, that is the definition of a swindler), especially since they started propagating their whole "security regimen" as a set of tasteless, mostly useless "security awareness" trainings. They harped a lot on choosing good passwords, caused a lot of bad password security practices on almost every website (I still see this everywhere online - please use 10 characters with one symbol from (!$./ ... etc) and 1 number - no - use entropic password measurement and maybe don't assume your site is important enough to warrrant a high-entropy password).

So, once we were all left with an unsustainable bag of crappy passwords for every buytoothpaste.com website out there... well we all had to try to invent something else. There was SSO OAuth, that failed because it was overcomplex (or got rolled into a banal corporate policy system which was horridly complex to deploy and the security contractors got paid to audit the bad systems).

Then pile on the other heap of bad password strenghtening abstractions (2FA), etc., you get to today. We never had SSH for the browser, GPG/PGP remained meh, so the result is a constant stream of "new solutions" to a problem which could have been solved by a) Not caring as much about passwords, communicate risk to the users instead b) fixing ssl/ssh.

And why did nobody do a) or b)? Again, I blame "security contractors" for a) and b) people not being paid to do it.

Yeah, profit-seekers will always try to capitalize on chaos, that's hardly conspiracy, that's just business.

Perhaps not reinvention but rather repackaging. Web Authentication (on which this is based) is (just) asymmetric encryption in an authentication challenge/response protocol.

It is at an API level, rather than the transport level like SSH and TLS, because applications often often have more complex requirements than these provide. In particular, SSH and mutual TLS typically expect traffic to be authenticated at the transport level on use, and for the credential to exist and be evaluated at first interaction. Websites typically have registration and self-service management functions, as well as anonymous access.

There is also nothing especially new about the use of hardware secure elements, nor was anything new claimed.

I will say as someone who implemented website smartcard-based authentication a decade ago - the experience was typically very poor, because the software stack had not been built for that use case, and often relied on third-party components which were simply sub-par.

There's a lot to be said for reusing technology, but there's also a lot to be said for creating the best possible experience. The MTLS experience that has existed has not gotten any notable consumer adoption for very valid reasons.

Well, there's encryption algorithms, and then there's authentication methods... Don't confuse the two. There's actually been a lot of interesting developments in authentication methods... not the least of which have been the FIDO 2.0/WebAuthn standards. While you might perceive them as plays by Big Tech, smaller companies like Yubikey are kind of at the core of it, and without WebAuthn in particular, it was rather hard to have confidence in browser based authentication. Yes, there were certificates, but the general public has struggled to understand and adopt device certificates in a way that doesn't lead to them being stolen.

There was already a passwordless authentication mechanism in browsers called SSL client certificates. Approximately nothing uses it because it’s hard to use.

My understanding is that this basically the same asymmetric public/private key encryption.

WebAuthN is the standards for defining how this works on the web.

Fido is the alliance (+standards?) for multi-platform interoperability. How do I get my private keys from my iPhone into Chrome on my PC?

> The syncing of passkeys in iCloud solves this backup problem.

But then apple has your keys....

I would assume that they are at least encrypted locally before being uploaded to iCloud. (But yes, Apple could always change things)

Don’t be so certain - we need more details from Apple on this. Last I checked iMessage was still (!) not encrypted when backed up to iCloud.

https://www.howtogeek.com/710509/apples-imessage-is-secure.....

iMessage backups are encrypted, they are just not encrypted as much as some people would like.

In particular, Apple has HSM servers outside their hosting environment for auditable release of encrypted backups. This could be done for a support request for a lost user password or as part of a legal demand (say, family of the deceased seeking access to photo history, or requested by law enforcement with a court order).

The passkeys system uses iCloud Keychain, which is a separate mechanism and is encrypted before being sent to Apple using user-device-private keys. You should need to both get iCloud access _and_ provision a device into the "ring" before you can access passwords or passkeys.

iCloud Keychain is end-to-end encrypted, Messages isn't because Apple took the tradeoff of allowing people to keep their imessage history even upon a support-initiated account reset, which otherwise will wipe your entire iCloud Keychain.

Passwords in iCloud Keychain are already E2EE, it seems reasonable the private passkeys would be too.

> iCloud ... backup

> E2EE

If you can lose all your existing devices, and can still restore your data, then that data isn't end to end encrypted.

I'm taking the "end" in e2ee to mean your devices. Nothing but your devices can decrypt your e2ee prospected data. If a new device can enter the circle of trust without an existing device's corporation then there is a backdoor.

I imagine icloud keychain supports synchronization rather than backup

The password stored in your backup via iCloud Keychain use the passcode of your devices as a secondary encryption/lock method, which doesn’t have a password recovery mechanism like the Apple ID used to secure your iCloud backup. Not sure that meets the definition of E2EE but it’s not like the passwords are recoverable by another party (or even you, if you forget the passcode) just because they’re in your iCloud backup.

Maybe usage of user account password would allow for E2E without any device?

How could one verify that? like for compliance audit?

https://support.apple.com/guide/sccc/introduction-sccccea618...

Introduction to Apple security assurance

As part of our commitment to security, Apple regularly engages with third-party organizations to certify and attest to the security of Apple’s hardware, software, and services. These internationally recognized organizations provide Apple with certifications that align with each major operating system release. …

iCloud Backups != iCloud syncing iiuc. Passwords/Wifi/etc. syncing is a different E2EE system.

You can disable iCloud Backups and still use iCloud

ahhh so they already have what they need to do iCloud E2EE, they just decide not to use it for your data....

Yup. Probably because law enforcement would be livid if Apple did that. In the San Bernardino terrorist case, Apple basically said triggering an iCloud backup is the best way to get the contents of a locked iPhone. Apple routinely supplies law enforcement with contents of iCloud backup.

It’s end to end encrypted. Apple doesn’t have access.

Same as the don't have access to your iMessage messages ... unless you happen to use iCloud which they purposefully make really inconvenient to not use.

Yes Apple is willingly staying quiet about your iMessage backup being accessible by them. But it does not change the fact that iCloud Keychain is end-to-end encrypted with Apple incapable of accessing your keychain.

I would expect passkeys to be a massive liability for Apple in case they get breached. Why would they even want access to them? Do you think they want access to your accounts?

No it's not. Apple has the key for iMessages. Does NOT have it for Keychain.

iCloud Keychain is end-to-end encrypted.

How will this work on Linux?

FIDO usb devices just use the HID protocol so they work fine on linux. Chrome and Firefox both support them.

I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido

There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.

> just use the HID protocol

This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device sub-protocols like your mouse or keyboard (or the built-in "take a photo" button on your web cam). Instead they provide a FIDO-specific HID sub-protocol, which is publicly documented, instead of operations like "Caps Lock pressed" it's got stuff like "Begin enrolment" or "PIN xxxx entered by the user" which only makes sense for this specific problem.

Oh, thanks for the explanation. I guess this new protocol is why I don't see as many tokens randomly appearing in chat sessions these days.

some yubikey modes of operation do emulate keyboards and paste a string of characters in text fields or terminals

Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :)

iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. This was a bit of an issue when I tried setting up a similar fido2 emulator in a container, as the Google container OS doesn't allow loading kernel modules. Do you know if that's still the case, or if there's a way to mock a fido2 key systemwide without uhid?

> there's a way to mock a fido2 key systemwide without uhid?

On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.

Isn't this approach significantly less secure than Apple's though? As far as I understand the secure enclave coprocessor in Apple devices stores key material and implements user verification (TouchID etc.), right? Instead software like tpm-fido bridges (in software) a user verification mechanism (maybe even a fingerprint reader) and the system's TPM. But such a system can be interposed with mere root access, and the TPM tricked in giving out its secrets, no? Please correct me if I'm getting it wrong, but Apple's approach is instead resistant even to full kernel compromise, precisely because the communication between TouchID/FaceID and the secure enclave cannot be interposed.

I'm a tpm-fido user myself by the way, thank you psanford!

Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration.

> TPM tricked in giving out its secrets

To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting the TPM to sign messages it shouldn't. But you couldn't steal the key from the TPM and use it somewhere else.

But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.

Is there a software implementation that would work without a TPM module where I can generate the keys myself?

Check out rust-u2f/softu2f[0].

[0]: https://github.com/danstiner/rust-u2f

Ok.. but hear me out here.

What if the only computer (or even the only Apple computer) a user has is an iphone, and someone swipes it?

Surely in that case you're now locked out of literally everything, no?

Please explain to me why this is stupid because I'm certain someone thought of this very early on.

As mentioned, the Passkeys are synced in iCloud, so a lost device doesn't mean the credentials are lost.

If you still can log in to iCloud, you're fine.

If your Apple ID password has been changed, Apple provides a workflow to regain access to your Apple ID [1].

There's also a process for account recovery for situations where you can't access your Apple ID because of two-factor authentication [2].

[1] https://iforgot.apple.com [2] https://support.apple.com/en-us/HT204921

A lot of sites allow you to create backup codes that you can print out and use once instead of the security key.

>As the authenticator, your Apple device generates a unique public-private key pair for every account it creates on a service. The authenticator retains the private key and shares its public key with the server, known as the relying party.

Its about time something like this really took off. Hopefully it will get rid of dumb hacks like text message verification that a lot of companies use. Plus database leaks will no longer be a big deal since they can't really do anything with just a public key.

This was around for a long time in the form of SSL client certs, but that never took off for all sorts of reasons. Presumably Apple nailed the UX problems but the general issue of how to back up your keys, get back access if you lose them, the confusion created by not having passwords etc were real isses.

Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.

Yes, this! Without a export/backup function for these data, you could easily lose access to nearly everything and the lock-in effect would also be something currently unseen.

There's nothing to backup/import. If you have an iPhone, you use your fingerprint or Face ID. If you sell your iPhone and buy an Android, you use your fingerprint or face recognition on that device.

That doesn’t sound correct. It’s not the finger print which identifies you to the website, it’s the public private keypair.

The private key is stored in the device’s Secure Enclave. It’s the face and fingerprint recognition which authenticates to the Secure Enclave in order to retrieve the private key.

When purchasing an android phone, you do need to sync the private key to the new device. Hence Passkey, which uses iCloud as its secure and authenticated syncing scheme.

I haven't dug into the docs yet, but I don't quite follow this. How does it know that the ex-iPhone owner and current Android owner are the same person (and should have access to the same account)?

If you did switch ecosystems, you'd probably need to do the whole re-enroll dance on every website that had your previous key. I don't see any sort of passkey backup/import functionality coming anytime soon simply because people don't change ecosystems that often, and those that do can simply keep both their iCloud and Android-based passkeys on services.

That's not how it works.

If you lose your only iPhone, you lose the keys. Using your face is different device does not get you access to your old keys.

> If you lose your only iPhone, you lose the keys.

But they're in your iCloud Keychain. You should just log in to iCloud and have them again.

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.

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

That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE connection so that your phone can sign the login request remotely.

Yes, obviously, but I was mostly referring to being able to share outside iCloud keychain, and in general 3rd party software support for this -- but, I wasn't aware of the BLE option, which is very interesting! I'm already very invested in 1Password (which I would like to integrate somehow, ideally) but that's good to know

I'm writing this on a non-Apple computer that doesn't have any radios. Now what?

As far as I can see this is Apple's (thus macOS / iOS) platform for FIDO, whereas WebAuthn does FIDO for the Web.

So, if you have macOS or iOS software for Mailpace, this is a way to have the same workflow for that as you get with WebAuthn for the web site.

Android likewise has an API for apps to get this, as well as the Chrome browser on Android having WebAuthn, and if you have apps on both platforms it might make sense to do that there too.

Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS.

So, GitHub won't get your Facebook credentials because github.com and facebook.com are different DNS names. Likewise "The 100% Legit Mailpace App" on iOS can't get the credentials for "Albert's Real Mailpace App" because they have some different internal iOS ID.

At the backend, validation is pretty similar except the RPID is different, and you'll need to read the documentation carefully to figure out what the RPID is for these app APIs, if you have a pile of magic numbers for "your" app it's probably one of those. You don't get to specify, because the whole point is that nobody can impersonate your app (well, obviously on an iPhone Apple could impersonate it, and on Android Google could)

> Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS.

The native APIs on Android, Apple and Microsoft platforms leverage relying party IDs which are web origins (e.g. https://github.com) whether doing native or web apps. The same native API is typically used by say Github Desktop as say the Chrome Browser.

A native app needs an entitlement and a file on the web server to enable functionality for particular domains. A browser gets an entitlement to request credentials for all domains.

Reading the linked page, it certainly looks very similar. I've also implemented WebAuthn from scratch and the term "relying party" is burned into my brain, and this document also uses that term. It's a reasonable term to use in any authentication context, though, so not a smoking gun I guess.

WebAuthn continues to work great on iOS and Mac OS, so I'm not sure there's a good reason to add some other new standard. (Though I do have the controversial opinion of wanting Apple to share my credentials between all devices. I have my iPad, iPhone, Macbook, and portable security key all enrolled in SSO. I don't mind this but I feel like it probably hinders adoption over an easily-hackable pasword that you just remember.)

Relying Party is the jargon for the entity that gets to rely on the fancy cryptographic technology to determine something that would otherwise be difficult / expensive / unreliable. They're relying on the maths working, and on certain other parties doing their jobs correctly.

Everybody here is a Relying Party when they use HTTPS. The Web PKI promises that this is really news.ycombinator.com to you, the HN reader, so long as the math works (RSA, Elliptic Curve Cryptography and likely AES) and so long as your browser vendor did their job, and the Issuing CA (DigiCert) did their job.

Relying Parties should ideally know why their trust is well-founded. For example, in the Web PKI examining this cryptography is the job of the Internet Research Task Force (related to the IETF), the browser vendors are responsible to you directly, and the Root CAs are overseen by m.d.s.policy, run by Mozilla on behalf of their users and everybody else's users.

WebAuthn is a Web-facing Javascript API for accessing passkeys, which it calls Public Key Credentials.

Technically, a Passkey is 'just' a key pair and other authentication information, associated with a web origin. It's meant to be a broad consumer facing term that resonates similarly with 'passwords' to convey its similar usage.

Apple platforms, along with Android and Windows, are implementing a system that synchronizes passkeys within their respective ecosystems. They are adding ways you can entitle an application to work on behalf of a web domain, and thus get native access to register and authenticate with passkeys as well.

A Yubikey or other FIDO device has been doing hardware-bound passkeys for ages. They just didn't use that term, instead calling them FIDO credentials.

The above platforms are also working on processes to allow usage across ecosystems - for instance, using your iPhone to sign into a Windows desktop.

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

Same as what they did with Bluetooth and AirTags, AirPods, etc.

They start with the standardized technology, do their little twist (which usually involves fixing some standardized bug that affects performance and people have been complaining about for years), and patent it.

Beta support for Passkey is already in the current macOS/iOS releases:

https://developer.apple.com/documentation/authenticationserv...

I am already using Passkeys on some websites.

Yes, it looks like it’s been around for a couple of months, after a somewhat quiet announcement. It’s the first I had heard of it though.

There was a WWDC session last year about Passkey:

https://developer.apple.com/videos/play/wwdc2021/10106/

Since Fall 2019 actually! (at least that's when I first used it)

I think you are confusing this with U2F support using the secure element, which has been added much earlier (I have also been using it for years already). The difference between that and Passkey is that Passkey syncs private keys between Apple devices through iCloud Keychain. The older U2F support is per-device.

It is, but annoyingly you need to enable it via Xcode, so if you only own idevices you can't turn it on. (Unless you mean just normally adding an iPhone as a security key & using Face ID to authenticate it, which is just how Apple implemented FIDO2 and isn't synced like Passkeys)

Is there a list of web properties that support passkeys?

I think it's supposed to work on websites that support Webauthn/FIDO2. For example, I have been using experimental Passkey support in Safari as a second factor for GitHub.

Yup, I think the bigger announcement today is around it becoming available on non-Apple devices.

This is wonderful news! If anyone is interested in experimenting we built an API that makes it very simple to add WebAuthn (passkeys) to your existing web app.

It’s available at https://passwordless.dev

Note: We also maintain the open source fido2-net-lib, the API just lowers the friction for devs.

You might at least want to put a warning there for people who access the page with unsupported browsers? There's nothing on the left of "⬅ Go ahead... click it." for me.

Good idea, thanks!

I've used this gem for rails apps https://github.com/cedarcode/webauthn-ruby

This is really cool! And well-timed - I have a project coming up this would be perfect for. The only thing I wonder is, if a user didn’t have biometrics on their device, how would they authenticate? Would I have to maintain a backup system for these users?

Biometrics are not needed, however device support is not 100%.

If the user is not running a model OS they could still be supported by using what is known as a security key (yubico) etc.

The Passwordless API can also help with out of band authentication (using a iOS device to sign in on unsupported old laptop)

In general they just need _something_. If Windows Hello has even a pin number, Chrome and FF webauthn prompts will use Windows Hello as a TPM provider (assuming the website is using actual Webauthn and not the older U2F-compatible standard, which some sites still use for compatibility, eg google). If they don't have anything, then they will definitely need at least a usb hardware key.

i use fido2-net-lib for a personal auth site, it works great! thanks for all your work!

Hey! Happy to hear Making this tech available has been our goal since inception

How does this bode for anonymity and multiple identities?

I'm imagining a world where all PCs/Macs/Smartphones have FIDO/WebAuthn and there's no other way to log in. Can I setup up multiple IDs on my iPhone and decide which services get to be associated with which id? I get that supposedly iPhone (etc) will (may?) give out a different number to each service but they'll still be associated with a single account at Apple's level. Further, it's likely these services will ask for more info and Apple will give it to them.

As it is I have a different id for almost every service. I'd like to keep it that way.

> I'm imagining a world where all PCs/Macs/Smartphones have FIDO/WebAuthn and there's no other way to log in.

You won't have to imagine that for long, because that's the world we are sprinting towards.

Once practically everyone has accepted and adopted this system, governments (having already banned E2EE messaging apps by this point) will complain that Big Tech are allowing cyber-terrorists to maintain anonymous identities online and not doing enough to protect the children.

The offices of Apple, Google, and Microsoft would then receive calls from the national tax/anti-trust authorities saying the government was thinking of launching an audit/investigation into those companies and wouldn't it be a shame if something happened to their profit margin that year.

Within a few months we'd see these companies all "voluntarily" release software updates which add a "Citizen ID" field to every FIDO interaction, with those IDs being issued by a government API and verified using a bank card and facial recognition.

FIDO logins are not shared across relying parties (sites), each site gets its own (that's what makes FIDO phishing proof). If you want a single identity that multiple sites know about you'd, login using a third party identity provider where you'd use your passkey.

FIDO2 resident keys do support multiple identities for a single relying party (site).

I don't get what it's all about this passwordless. I make my browser (Firefox) generate strong password and store them in its password manager, this is synchronized with end to end encryption to all my devices, I have only to remember a master password. It's kind of the same but it works with every website. It is not complicated, doesn't require certificates that you may loose, and that sort of things.

Try explaining a password manager to your nana, and having her use it. Then explain to her how she can install it on her phone and have it synchronised across all her devices. Password managers are awesome, but way too technical to become mainstream. You shouldn't have to install 3rd party software for something so fundamental. The password system really needs an overhaul and hopefully this will go along way towards fixing it.

Apple already has a password manager as part of iOS/MacOS. Your passwords sync seamlessly on other Apple devices via iCloud. There is nothing to install. My octogenarian mother uses it daily on her iPad and iMac.

Password managers are already pretty easy to use from a nana's perspective. The main problem is that nana does not know that password managers exit itself. Most of them just input password as 'nana1234' and store it in their browser password manager (usually chrome password manager) and use chrome's autofill.

Eg., I was telling a middle aged person (50 years) about password managers and were unable to grasp the idea of it. 'Why would you store passwords in cloud based password manager from a company I have never heard of, just type a password and write it down on your diary (OS notes app) or just store it in chrome. I trust google (chrome) to keep my passwords safe rather than with some sketchy company I have never heard of (the sketchy company if one of the most reputable cloud based password management company).

> I was telling a middle aged person (50 years) about password managers and were unable to grasp the idea of it.

This is more than a little ageist, don’t you think?

> Why would you store passwords in cloud based password manager from a company I have never heard of?

This is actually a very valid question; hope you didn’t just dismiss it due to “the oldie doesn’t understand.”

> Try explaining a password manager to your nana

It's an interesting issue, and wildly varies depending on who manages her devices. For instance if she has an iPhone with a windows computer, a third party manager brings uniformity to how she deals with login on any device she happens to use. Same if she happens to use a Chromebook.

Or even if she uses an older Apple device, I'm assuming passkeys won't come to previous OSes, and upgrading a 2018 MBP just to get passkeys would come with a lot of trade-offs.

Perhaps I'm seeing it as, it's already a complex mess already, and Apple didn't come with a silver buller to solve all that complexity in one swoop.

PS: password managers are fairly straightforward to explain: it's a digital equivalent of the password notebook they keep in the side drawer

Sometimes I wonder how bright nana or papa really is as a result.

If you won't dig into even an iPhone's settings to learn what's available, what it can do, good luck to you. That curiosity and willingness to play around, accompanied with Google searches when they don't know what something does, is critical in making it in the world today. Or if you remain a rube, and they will, you'll get scammed someday because you're not on the top of your game mentally. Just lazying it up.

I've come to two solutions. Either Bitwarden or KeePass with only a mobile client to begin with. If they are managing that, then I graduate them to clients on multiple systems and the integration advantages that brings.

I'm a KeePass Windows and Strongbox Pro user on iOS myself. Prefer to keep that database where I want it. Bitwarden is probably the ticket for most people though. If you start them on mobile only, it helps a lot.

What a ridiculous thing to say.

Nana and Papa are not locksmiths.

Nana and Papa still deserve to have a front door to their house that can't be lockpicked.

Normal people, who have other interests in life than configuring technology, should have secure devices and data from criminals. And they shouldn't have to configure 5 different obscure password managers to do so.

Society shouldn't allow criminals to take advantage of Nana and Papa.

This is one of the most embarrassing comments I've read on Hackernews.

The point is to make it harder to export your credentials to another platform. An iOS refugee with a keychain full of passkeys will have to do a password reset for every account, instead of a relatively simple export/import into a third-party password manager.

I don’t get that too, you can already build such a system yourself quite trivially with gpg+rsync

Impossible to tell if this is serious or sarcasm, well done if it’s the latter.

It’s not the same because you have to actually tell the websites your password, while with this, like with certificates, you only have to prove that you have access to the private key. So, if the server is hacked they don’t get a dump of encrypted passwords and if the hack persists they can’t sniff your password. Because the server never gets your password.

But this is irrelevant if you use a password manager.

Not entirely. If I MITM your connection to a website that uses a password, I have access until the breach is detected. If I MITM a public/private key log in, I only have access to the session (which can be made arbitrarily short if logging in is painless/automatic).

No, because if the server gets hacked and the attacker can intercept your password, your password manager is managing a password that is, unbeknownst to it, known to an attacker. Who can now use that password to just login to the service.

It eliminates phishing since there is no password to share and the authorization is locked to a specific domain.

Flip side of the coin: this system now manages what domain you can log to, and when it gets it wrong you're probably toast or go through a backup option (is there any if yhey maximize for security ?)

I used Apple keychain for a while, and it wasn't good at recognizing which site needed which password, not even including account switching when you want to use a different one. If it hasn't significantly improved, it will be a pretty frustrating experience for user heavily relying on it (and not just using the same 5 sites the same way everyday)

In general "passkey breach" events aren't possible.

How does apple get your data that way?

Apps.

1Password supports mobile apps. Probably other password managers do too.

Sure, but how does that relate to the GP's comment about Firefox? Did Mozilla release a FirefoxOS for Apple devices that I didn't hear about?!

I think we need a browser level or OS level notification about which passwordless service we used last time.

Did we use Gmail, Twitter, Signin with Apple, Github, Linkedin, or do I actually have something stored in my password manager associated with an email and if so, did I store it in the browser's password manager, the OS's password manager, or my third party password manager?

Such a great point. I forget all the time. Next auth service I write will remember this for you and prompt you based on the service you used last time. Take my upvote!

One trick to this is to put an entry in your password manager for the site that's just a note that says "log in w/ X". So you always check the PM first- it'll either have credentials or a pointer to how to log in.

Why do you use more than one password manager? I have disabled all password managers in every app that I use except for the one I store things in. I have multiple folders with their own passwords too but they're all stored via the same solution.

Because Google Chrome on iOS pops up asking to remember a password

Safari on iOS suggests a password even if I'm trying to paste on in from my password manager

OSX can be the same way

They all sync

and I never bothered to disable them because I never thought about it, but sometimes I'm in a rush with a service I think I'll never use again and use the suggested solution in one of the browsers

Unfortunately, and I hate to "victim blame" (though you say you are not yet a victim), I think you have to take some responsibility and use a password manager with deliberation. IMHO the browsers all make this worse by giving you something that seems to work and your first notice that it doesn't anymore is when it stops, which is a terrible way for a security feature to work, but obviously they have incentives to lock you in, and boy oh boy is this one of the biggest ways that a browser can lock you in.

I think you should resist sooner rather than later and switch to something cross-browser and third-party.

But it's up to you, of course.

>Why do you use more than one password manager?

Work vs home is one driver.

And for some cases, "Login with Google" or similar is nice because it integrates Google pay, removes sign-up friction, etc. I'm aware it has downsides, but it remains useful in some niche areas.

Most password managers allow you to separate work from home, though. You don't need to store them in different platforms to have them in different places.

The browser and the OS credentials managers essentially obsolete the third party password manger so that part is sort of 'solved'. Integration between the browser and OS one (with sync) is quite a bit trickier but the real blocker is that Apple and Google aren't much interested in solving it. The terawatts of brain power that went into the anonymized COVID tracker phone thing which turned out to be largely pointless could be applied to this, it just doesn't feel very likely.

I don’t actually know how many Reddit accounts I have for this reason.

Does anyone know how this/FIDO/Webauthn affect privacy? How well supported are alt accounts? Are they easy to tell they're from the same signer?

I figure privacy is fine as long as the implementations allow you to select which account to login with. Is this currently a thing? From everything I read it seems like the current implementations are only meant to support one identity?

EDIT: These are great responses, also curious if anyone is aware if Apple's current implementation supports multiple identities?

FIDO2/WebAuthn don't have anything to do with user management from an application architecture perspective. They leave all the work of combining the attestation credentials and your application's concept of a "user" to the application.

This means you can (and should as a designer) have multiple sets of credentials for one "user", multiple distinct credentials that you (the user) can register to multiple separate "user"s in the application, etc.

I believe all FIDO2 authenticators (like hardware keys) should generate a new hardware / key ID for each request for pairing a new credential. I know that my key does that, when I was working on implementing WebAuthn for $DAYJOB.

https://developers.yubico.com/WebAuthn/ is a good jumping off point.

FIDO2 resident keys (the thing people are now calling passkeys) allow for multiple credentials for a single site. If you have a device that supports resident keys you can try this for yourself on https://webauthn.io.

There is also no way for a site to know if two sets of credentials belong to the same physical hardware device or not. Sites can request the attestation certificate, but that is not unique per device (the spec says the attestation cert should be shared by at least 100,000 devices). If you want to see the attestation cert for a fido(2) device, I made a little tool that will show it to you: https://what-the-fido.sanford.io/

Got "failed to register" on your website on my phone after doing the os level fingerprint auth

Thanks for the heads up, it should be fixed now for android platform authenticators.

FIDO/WebauthN are generally "the good guys" when it comes to privacy bc "bring your own secure hardware key" is always an option. I'm kinda torn over the "use your cellphone as a key" approaches as not privacy friendly but we can't actually prevent them (you can always simulate a key).

> you can always simulate a key

But you can't simulate an attestation that you're using a device from one of the "approved" manufacturers in the cartel. This is basically DRM for human identity.

https://nitter.net/sleevi_/status/1392903827712512001

Maybe only tangentially related, but does anyone user Apple Keychain as their primary password manager? Is that even a viable option if you're completely within the Apple ecosystem?

I mainly use Bitwarden for my passwords, but for things I usually open in Safari (for example food ordering sites which accept Apple Pay) I also save the password in Keychain so it's easier / faster to log in (in case Bitwarden is locked and I would have to unlock it (Face ID) with the app instead of the extension).

Yes I started using Keychain exclusively after the LastPass app got progressively shittier. No issues so far, and really no differences. Even tells you when something gets compromised.

Any tips on transferring data from e.g. LastPass to Keychain? Also, are you now tied in to Safari on all devices or is it interoperable with other browsers at all?

I'm not sure if there is an actual transfer available. I just gradually accreted passwords into Keychain by having LastPass on normally, and then accepting the prompt when Safari asked me to save the password.

iCloud passwords works with Chrome and Edge on Windows but generally yeah you need to be all-in on Safari :V

There’s a csv import and export, it’s supposed to be compatible with things like 1password, chrome and a few others.

I used it for a few years, then switched to a paid password manager. Keychain just doesn't (didn't?) have features that I need: cross-device functionality, family sharing, groups for different credentials (work/private), browser integration, etc etc. Also, its UI sucks.

It's definitely a viable option, and probably the simplest/easiest password manager to use if you're only using Apple devices (of course, that is by design).

Yeah, I use it for most logins. Quite capable and entirely free.

How do I leave the Apple ecosystem if I go all in on this? Sounds like major vendor lock in under a deceptive title of “open standards” but I’m hoping I’m wrong here. Does anybody happen to know yet?

Just add more authenticators to every RP (site you auth into). From the point of view of an RP, "your account in the Apple ecosystem" here is the exact same thing as "one of your Yubikeys", basically.

That seems like an enormous pain if you have dozens or hundreds of services. It could take hours to do this one at a time. (I'm assuming one minute per service, though that depends on how hard it is to find the "add another authenticator" page for each service.)

It's possible I'm unaware that there is a simple protocol for this. Am I incorrect here?

Yeah, that's going to be the next big ecosystem challenge for WebAuthn in my opinion. Ideally platforms would support 3rd party password managers, so you could manage your keys without having to tie your credential database to any one specific platform.

I'm sure as the popularity of WebAuthn grows there'll be more and more demand for cross-platform compatibility until eventually the big players are forced to implement it, but it's going to be kind of rough in the short term until then.

Except Apple are kind of notorious about avoiding cross platform compatibility which is why I ask. Find them hard to trust at this point.

I can already hear them making the “we can’t because it will impact users security” argument in my head.

That would be nice. I used Hanko for one service I built that uses WebAuthn+email, so new devices get a one-time code in their email and existing just use WebAuthn. It would be kind of nice not to have to rely on email, but it's better than making people remember passwords.

I always was curious about this stuff. I don't want all my eggs in a basket and have to depend completely on others for "logging in". Apple and Google and other Big Corps(tm) have shown they are just fine with terminating your accounts without any recourse and/or warning with no practical way to appeal it. Passwords managers aren't subject to that limitation and all faang companies can do is kill your accounts for their particular services.

As long as your account is tied to your email address, there should be something similar to a password reset.

Hopefully this will be compatible with WebAuthN in practice and encourage web sites to implement it (in a compatible manner). It often does take Apple's heft to force a change across the web.

Most importantly, hopefully web sites will implement support for multiple authenticators, so you can actually use this safely without relying on a cloud-synced solution.

I hope this pushes out other, less secure and more tedious 2FA methods. However, once it becomes popular, sign in with WebAuthN only will likely not be enough, as attackers learn to attack it (e.g. stealing software-based tokens, adding a cloud-synced device, hijacking already-authenticated sessions from compromised machines)

I can be onboard with this if Apple opens up an iCloud API for syncing, so I can sync a non-Apple device through iCloud, and if I leave Apple and iCloud behind, my non-Apple devices keep working, even if I never sync through iCloud again.

C'mon. Non-Apple devices aren't _even remotely_ a priority for them. Just look how bad Apple Music is on Android and web.

I'm going to sound like an Apple apologize, but what's wrong with Apple Music on the web? I just launched it (for the second time in a while), and after signing in, was presented with a familiar looking UI and all my playlists, and was playing searched-for music in under a minute. I know Apple prioritizes their platforms first, but this doesn't seem like an example of Apple failing a competing platform.

Apple Music on Android is actually really good, I use it daily. On some level it was a priority for them for market share, to compete with Spotify. I don't see the "competitor" in this space (cloud) though that would drive that necessity.

The AppleTV app on my LG TV is the best third party app on it, IMO. Looks and works great.

Their Roku and AndroidTV apps are also good. I'm not sure I've ever even used the service on a piece of Apple hardware, and it's never been a problem.

Why not just use 1Password or a similar service?

What happens if you lose your device or it breaks or something? Do you lose access to anything tied to it?

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

This is false; some data is end-to-end encrypted, including Health and Keychain data. Photos, contacts, and Drive are "encrypted on server" which means Apple can read them.

https://support.apple.com/en-us/HT202303

That’s not universally true.

https://support.apple.com/en-us/HT202303

> If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service.

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.

Data in iCloud is going to be encrypted by the host provider in-transit and at rest. That is not the same as being encrypted at the source by Apple. It means that Google, Amazon, Azure (and whatever other platforms Apple uses for iCloud storage) will be doing that encryption with keys that they have for Apple. All the major vendors have storage encryption both in-transit and at rest. I suspect that it would be a requirement from Apple for any future vendor, too.

It does mean that the data is not sitting in clear-text form on the provider's disks. But the exact details of that encryption may vary from provider to provider.

Photos need to be encrypted on server so they can be scanned for CSAM. Apple tried to move that bit to the phone so they could encrypt photos on server too, but we all know how that went.

Literally in the article:

> Instead of protecting all of iCloud with end-to-end encryption, Apple has shifted to focus on protecting some of the most sensitive user information, such as saved passwords and health data.

> But backed-up contact information and texts from iMessage, WhatsApp and other encrypted services remain available to Apple employees and authorities.

Same thing that happens if your FIDO/U2F key breaks. If you have a backup key (or in the case of this implementation, icloud backup), then it shouldn't matter. Otherwise you're at the mercy of the site that's requesting the credentials. They might allow you to authenticate via another method (security questions?), or lock you out permanently.

Ideally, if you can’t identity proof in person, recovery flow should be Stripe Identity or another proofing system that will consume government ID and output pass or fail. It’s the next best thing to showing up in person and having a human proof you, and saying “oops keys all gone” isn’t going to fly for the masses at scale.

It's tied to a key stored in your iCloud. So basically as long as you have a device tied to your iCloud you can get in. Presumably, if you lose access to iCloud you will have problems.

What happens when you're not using an apple device?

I saw a screenshot. Somehow a QR code is presented and you scan that with your phone. I’m not entirely sure what happens from there.

But there was a picture of them using it with a Windows machine. So they’ve thought of it.

Apple is the face on the screen. There is no lady with a hammer.

https://youtu.be/OYecfV3ubP8

This is based on an open standard and is entirely optional.

So your analogy makes absolutely no sense.

They said in the event that everything is synced on iCloud so all your devices can use the keys, which makes me think no, it's just a password manager, without the password bit. Maybe they create a separate key for each device, but then why mention iCloud syncing at all.

It's a password manager with cryptographic vendor lockin.

There are definitely some benefits though, such as immunity from phishing. Surely we as the industry can bring them about in a way that doesn't involve cryptographic vendor lockin.

There is no password so it can't be a password manager. Without a password it avoids all the downsides of passwords like having to store them securely on both ends, rainbow tables, credential reuse, weak password choice, and having to remember them. It's a cryptographic keypair manager. Key management is always the barrier to really good real world cryptography, so I'm heartily in favour. Anything that makes it possible for regular people to use strong cryptography is a huge win.

Since it's all just FIDO2/webauthn under the hood it's hardly lockin. It's a bit of Apple UI tinsel to make life simple and their excellent icloud keychain sync.

The industry doesn’t seem to have a working software solution for mobile phone authentication secrets that both is 1) immune to persuading a user to export their data (to get phished), and 2) allows a user to export their data at any time (to prevent lock-in).

What would it look like to do #2 safely, without enabling the phishing that we see today with #1?

The secrets can be exported - whether or not they will allow that though...

It sounds like your private keys are stored in iCloud, so they should be accessible on a new device as long as you remember your Apple ID, password, the device-specific PIN/passcode from your old phone.

I would guess you could not sign into it on another computer, right?

They must have considered this because that's would be a huge hassle.

The page doesn't state it explicitly; is this Apple's implementation for FIDO2?

The video presentation said it was part of the FIDO standard.

Ah, okay. I'm not interested in Apple's periodic product ads so I didn't really understand why this was linked again, especially since it's been available for a while now.

It’s been available in beta/nightly form for a little while, I think.

But at todays WWDC presentation they announced it as an official complete feature for the next releases of their OSes.

(That’s why there is so much Apple stuff, presentation just eneed about 15m ago)

It is linked because it was covered in the keynote.

And what is new is that it looks to become a widely supported FIDO standard i.e. Google/Microsoft are onboard whereas before it was an iOS/macOS only technology.

What standard is this using? The doc doesn't specify.

According to the WWDC Keynote they are working with the FIDO Alliance on it: https://fidoalliance.org/

FIDO2/WebAuthN

Under the covers, this is webauthn, which is based on FIDO2/U2F. I knew it was webauthn as soon as I read "relying party" and the two keypairs.

Comment from the presentation: “Worked with fido alliance to work across platforms”.

For those in the know, will I be able to export my private keys and data from Passkey somehow, so that if I wanted to, I could switch to another FIDO device or system?

I would speculate Apple is not going to support this, and Apple will retain control of the private keys, and do the request signing like an old-school USB FIDO device, but I don't know for sure.

They allow export of everything else in iCloud keychain so I don’t expect this will be different.

For context: https://arstechnica.com/information-technology/2022/05/how-a...

> available to the masses in the form of a standard adopted by Apple, Google, and Microsoft that allows for cross-platform and cross-service passkeys.

Any way to use this standard if you're not Apple/Google/Microsoft? I'd prefer an option that Apple/Google/Microsoft can call a service (that I control and authorize). I want to be able to self host such a service or have an open marketplace that can compete to serve this service.

Apple Passkey is an implementation of WebAuthn. It's a feature which their devices support (and will soon be able to synchronize through iCloud), not a service -- there's nothing that needs to be "hosted".

https://webauthn.io/

What I want is to use the device password instead of biometrics. So the device itself and its TPM are the FIDO authenticator, the thing I have in 2FA terms, and the device password is the thing I know. Personally, I feel I can better protect a password than my fingerprint. But I still want the benefits of 2FA and public key crypto where the app/website doesn’t receive any sensitive information. I’d be okay with pressing a button to prove user presence. I’d avoid syncing the keypairs between devices, instead enrolling a new keypair for each device. I guess that last part could be annoying but it’s pretty much how I use SSH today and it’s not that bad.

That first part is literally how it works. If you have your Mac closed (so you can't access TouchID), it asks for your Mac password.

I’ll have to try that. Wish there was a way without an external display. I’d like this on my phone, too.

You can also just not setup touchid or faceid and it’ll use device password/passcode

I don’t understand how passkeys aren’t stored on external servers and can’t be phished, and yet they sync via iCloud Keychain (which is a nice thing to have). How does that work? Or do you have to trust Apple not to get hacked?

It is webauthn under the hood if you want to do further googling.

When setting up a credential the secure enclave in your apple device generates a public/private keypair. The public key is sent to the web service for storage and the private key is stored securely and synced between apple devices using end to end encryption. When you want to login the website sends a message to be signed, the apple device prompts for finger or face id to unlock the private key and the message is signed and returned to the website. The website uses the public key to verify only you could have signed the message. If an attacker dumps the website database all they get is a public key which is useless without the private key.

It's unphishable since the browser checks the origin hostname before the faceid prompt. Spell-alikes like g00gle.com will prompt for their own unique key that you don't have since it was never created. Apple's security doesn't matter since they never had the private key; it is sent between Apple devices using end to end encryption.

Several WebAuthn Software authenticators: https://github.com/herrjemand/awesome-webauthn#software-auth...

https://news.ycombinator.com/item?id=31272867#31274677

> FIDO security keys that explicitly support backing up and restoring their master secrets?

I hope 1password gets annihilated by this move. I really liked what they built but over the past few years they have been very user hostile to ensure their extensions fail the Chrome binary signature. When you build a product that people start relying on it's very much of a dick move to go out of your way and make them not work anymore in hopes that they start dishing out a monthly subscription fee. Imagine if Gmail started charging money to read your email.

I have used 1p for several years now and it works great for e.g. me and my wife, but fails repeatedly for my parents who are just not savvy enough to deal with all the little sharp edges that a password manager can't handle (e.g. over stringent or under stringent password rules, the ability to save in all situations like password reset/update interstitials, etc).

I am hoping that if Passkey becomes mainstream they can finally stop pestering me when they hit an edge case.

I doubted Apple's touchID and FaceID but honestly, without it my parents would be a lot more vulnerable. My hope is that this gets them to strong auth everywhere instead of really weak passwords.

Can I use a password manager like 1password it’s FIDO2 the way I currently can in iOS/macOS? iCloud Keychain is the most barebones of password manager

Seems like this will be possible: https://blog.1password.com/1password-is-joining-the-fido-all...

Excellent. I actually like Apple's practice in this regard: they have a barebones/baseline functionality but allow third parties to provide a value added replacement that can be a first class replacement.*

Apple is almost there with mail, addressbook, and calendar but perhaps surprisingly they aren't as seamless as it is with passwords.

* For example this allowed me to plug 1password into my parents' phones and computers and use the shared vaults to make sure I could help them get unstuck from various web sites. Plus when they pass on I'll still be able to help the surviving parent to get access to things they need from the other parent's device. The apple one is disabled so they can't even accidentally get something confusingly stored in it.

They also demoed this working directly in Safari - does anyone know how to support this in languages other than swift/obj-c? Can this be done with js?

As an RP, there is nothing Apple specific for you to do, just WebAuthn.

While we're talking about authentication: Once the user is logged in, how practical is it for native apps on Apple platforms to use something more secure than bearer tokens to authenticate with the service on each request? I'm reminded of https://mjg59.dreamwidth.org/59704.html

What I would like to know is if this takes off, will I finally be able to use my Yubikey on all the same sites that suppprt Apple Passkey?

Probably. Google and GitHub already support WebAuthn for 2FA so it's relatively trivial for them to ditch passwords altogether and use WebAuthn as the single credential.

If this is about "[hardware devices] for generating and authenticating accounts" like WebAuthn FIDO et al what happens when I upgrade my Macbook. Do I revert back to password in order to associate the new private key (or hardware generate password) with my existing account?

The keys are synced through iCloud Keychain, presumably also to your new Mac.

Could Passkeys ever be used for SSH? I purchased a Yubikey to use as an ed25519-sk key but found the implementation to be too drastic of a change to my workflow to be comfortable with. TouchID / FaceID for SSH would be a totally palatable solution however.

Interesting question. Though, if you don't specifically need syncing, there are already apps for storing SSH keys in the Secure Enclave, such as Secretive:

https://github.com/maxgoedjen/secretive

1Password supports this: https://blog.1password.com/1password-ssh-agent/

How do I deal with this when I move from an Apple to a non-Apple device (Android, Chromebook, Linux, Windows, whatever)? With passwords it's straightforward. I just log in.

Any word if something like this can be shared with Bitwarden?

Why not, it seems to be coming to 1Password: https://www.youtube.com/watch?v=lYFxfchhR1g

I wonder what this means for services like Plaid and other aggregators. Will apps / websites continue on with standard username/password option?

I feel like a bank implementing this before they did Oauth (the proper way for those sorts of services like Plaud) would be kinda strange.

I'm ok if Plaid loses their model.

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.

> This is basically the biggest problem with WebAuthn today: the credentials are tied to the browser

That's definitely not true. My Feitian ePass for example (very cheap USB dongle that lives with my house keys) works just fine to sign me into GitHub on this desktop PC w/ Firefox on Linux, it works fine via a USB-C to USB-A adaptor to sign in on my Android phone w/ Chrome, and likewise on the Windows laptop I use for work when I needed to access my personal site briefly at Christmas and that was the only laptop I'd brought with me.

If you have credentials tied up in some proprietary system then, yeah, they're trapped in there, and in Apple's case they've decided to make it possible to move the credentials to another Apple device via iCloud.

Yeah, since Apple's (and Google's) soft WebAuthn implementation is designed for syncing across devices, it should also work with many browsers on the same machine.

Is this the return of the html tag <keygen> ?

Can you use this without biometrics? I don't use biometrics because they are not protected by the Fifth Amendment in the USA.

How does this impact 1Password going forward?

1Password is also part of FIDO. I assume if you want to use 1Password on Apple devices to store passkeys that should work fine, just like it does for passwords today.

https://blog.1password.com/1password-is-joining-the-fido-all...

They've already put this WebAuthn teaser up: https://www.youtube.com/watch?v=lYFxfchhR1g

So they emphasized that this is going to kill "phishing" I doubt it.

Phishing is an artifact of stealing and reusing passwords. Even if you need to enter a PIN, there is nothing reusable that you provide to the site you are logging into.

I hope they add support for Yubikey integration for iCloud with this.

Whatever happened to the idea of NFC auth rings you wear?

A more generalized solution: https://passage.id

trust apple? I'll pass

My wife signed up for calm.com using Sign in with Apple. Thanks to this, I am not able to occasionally use her login to listen to the wonderful music. There's just no way in hell I'm paying the $60 a year or whatever they're asking to listen to a couple songs every now and then. In a normal setting, she'd add her login to her 1password and I'd be able to use Calm.com, and who knows, I would've grown to love it, and gotten myself a second subscription.

But since this experience has been so confoundingly annoying, Calm.com won't get a penny from me. (Not even sure I want to blame them... but rather how it's impossible for my wife to just "share" that credential with me even if she wanted to)

Not being able to share a certain type of login (for this kind of family sharing scenario) has really soured me on the more personal use cases for these technologies, even though they are really solid from the tech side.

Like people often say, most products are competing with Word, Excel, and email, authentication is competing with me just being able to tell a human my username and password.

Again, there are many instances where being able to share these credentials seamlessly between non-power users is totally legit. When I sit with my dad to help her log in to his patient portal to get some medical info. Or when my mom wants help to review her Verizon cell phone bill. Or when I get my wife's credentials to cancel a hotel reservation.

How are they going to solve the totally legitimate sharing use cases? Using PKI actually gives you a wonderful set of tools to do this (underlying implementation could be that we generate a temp cert that expires in 24 hours, signed by her original credential certificate saying it's a shared credential, etc)

I really hope these are the use cases that get more fleshed out before these technologies reach mainstream.

> How are they going to solve the totally legitimate sharing use cases?

According to their Terms, there are no legitimate sharing use cases. "You agree that you won’t disclose your Account password to anyone". That said, Calm has a family plan (6 users) for only $30/year more.

This sounds like exactly the dark pattern Netflix will be clamoring for. “Oh gee, looks like you can’t share passwords anymore…”

"Sign in with Apple" does have a very bare-bones OIDC flow in the browser on non-Apple devices/browsers. That flow takes you through a typical Apple Cloud login flow with Apple ID email and password and usual 2FA if it's the first time on that browser/device.

To meet bare minimum requirements sites like Calm.com often only show the "Sign In with Apple" button for iOS and iPadOS user agents. You can sometimes fake an iOS/iPadOS user agent and get the buttons to show up and then switch the User Agent back to get the boring in-browser OIDC flow.

As an iOS/iPadOS but Windows PC user I find it frustrating how many websites intentionally hide that button in other browsers, just when dealing with my own accounts.

I feel like Apple could maybe do a better job of education here: "please don't hide the button on non-iOS/iPadOS user agents". I hope Apple has strong developer education plans for Passkey.

For a business, implementing FIDO in this case seems like a win. They get more lockout of password sharing, and have to explicitly work to enable shared logins (if that's something they want). Of course it's nice for an end user to be able to share credentials, but I think long term outlook will be towards businesses and applications pushing to improve their user management tooling.

Anecdotally, in the instance you described they net the same $60/yr regardless of wether you use your wife's login, so they're getting more stringent access controls (though you could always use the device in question, too) in line with their terms of service.

(Would also note that my response does not cover your latter points on helping users manage their accounts with their presence, but without their device presence, which I agree is a valid concern)

You also ignored the point that perhaps they'd have gotten to like the service enough to get a subscription for themselves, but refusing out of spite now.

Is that not a use-case for Family Sharing?

Apple says you can "download content" bought by other family members[0], but I guess this doesn't work for subscriptions?

That's a real missed opportunity. I would expect them to at least allow the app developer to opt in to sharing. Selling two licenses into a household has to be pretty rare, whereas having happy-family customers is great word of mouth. "My wife uses FooApp and now I use it too!"

[0]: https://support.apple.com/en-us/HT201085

The app developer has to specifically support Family Sharing if they want to allow people to share subscriptions.

Most IAPs and non-Apple subscriptions don't work with Family Sharing, and the few that do there's no way to tell before you buy.

Family Sharing is set up in such a way that you're punished for creating child Apple accounts as Apple recommends, because you'll need to repurchase MOST IAPs several times over.

Apple's subscriptions are the exception rather than the rule, but they like to promote it in such a way as you'd think all Subscriptions/IAPs are shared when they're not.

Consider paying the developers and artists for their work. It’s hard out there and it’s about to get a lot worse for both.

Thank god the touchbar continues to disappear

Does this explain at least some of the Okta drop in share price?

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.

Plus, password managers have fantastic backwards compatibility even on old, crufty sites that will never be updated.

We really should be working to allow better, standardized integration with password managers (communicating password length and alphabet requirements, well-known URIs to do zero-touch credential rotation, etc.) rather than trying to do "Log in with BIGCORP" in another way.

There are some efforts to make things easier for password manager. E.g. differentiation new password, old password and 2FA token fields: https://developer.apple.com/documentation/security/password_...

I believe some password managers also look at the regex attribute to understand required or disallowed characters.

For resetting passwords there‘s at least a way to deep link to the right page: https://web.dev/change-password-url/

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 proper way to rotate out an authenticator device is to add a new device first, and then remove the old device; and the proper way to protect against a lost device, is to keep an extra bound device in safe cold storage somewhere (e.g. a safe deposit box.)

Basically, look at how the crypto people handle the "hardware wallets" (really, smart cards) they use for multisig transactions. 2-of-3 confirmations, two hot smart cards held independently by company officers, one cold smart card held by e.g. the company's law firm.

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.

MFA itself is absurd and nonsensical for the vast majority of users. It's security theatre unless you do it right, and if you're doing it right, it's — as you've said — too hard for most people to bother. Properly implemented, MFA is an Enterprise feature, not a personal feature. Like SAML SSO, or having audit-log APIs.

The point of setting up MFA is to secure things that really need to be secure, where the person with the data is aware of real attacker threat-profiles that have real interest in their data. It's a thing that companies that hire CISOs care about.

Any implementation of MFA you see in the wild is either part of a product that has an enterprise tier that has customers like that, where the product devs decided to "trickle down" the feature [in a less-secure, but possibly optionally secure, form] to lower plan tiers; or it's a cargo-cult reimplementation where a company "saw other companies doing it and it seemed like a good idea" — but they exchanged actual security for convenience.

(You can usually distinguish one from the other, because the companies "actually doing MFA" will almost always support smart-card authenticators — and have for decades, back since doing so required a Java applet. Because "issuing each employee a smart card" is what companies that actually care about cybersecurity — e.g. defense contractors, investment banks, etc. — do as a matter of course.)

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

Looking at how various places do 2FA, it's likely that at least some websites will not support multiple keys even if they ought to.

Also, I imagine that many people do not have the luxury of multiple devices. So if you lose your phone, you'll need to buy or at least borrow another iOS device to recover it from iCloud before you could switch to Android.

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

I think they must know they need to have some sort of migration/export strategy. Maybe its just to early for that to be implemented yet. I mean I'm not even aware of any websites that support Passkeys as the sole auth method.

How are these handled in Chrome/FF/Windows/etc.

Oh, I see now. Don't think I will be using it.

Sorry for the somewhat but not quite off topic post, but can we please prevent HN from becoming yet another Apple billboard? There are more than enough of those already. Thank you.

Yes I've heard that there may be some Apple manifestation going on or something but to have every little Apple tidbit hoisted directly to the front page (at least 7 articles and counting) is a bit much imho.

Downvote me if you must, but I think it is important to have my opinion heard, and I don't think I am the only one.

This post is related to a large number of developers and startups (read: HN users), many of which have at least an iOS app or support safari. I don't see what the problem is.

My reply was not directed at this post in particular, but at the worryingly large number of Apple related posts making it to the front page lately. It makes me worry that HN is becoming biased towards favouring news about Apple's activities above other interesting subjects.

Companies release new products all the time, I'm not sure that HN is the proper place to discuss them unless they are truly innovative or newsworthy.

That's just how Apple does their announcements: in big piles at few dates. The alternative would be to dribble them out slowly. As someone who is not particularly interested in Apple news either, I actually prefer this. Better get it out of the way in one fell swoop than have one announcement every other week that dominates the discussion all the time. Things being as they are, there are 3-4 Apple events per year, and so there are 48-49 weeks without big Apple news.

Reply on news.ycombinator.com