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.
>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.
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.
>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.
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.
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.
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)
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.)
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
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)
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.
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.
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?
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?
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?
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?
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.
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.
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.
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.
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 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.
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.
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.
[+] [-] zxcvgm|3 years ago|reply
https://fidoalliance.org/apple-google-and-microsoft-commit-t...
[+] [-] al_borland|3 years ago|reply
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.
[+] [-] userbinator|3 years ago|reply
[+] [-] Vladimof|3 years ago|reply
But then apple has your keys....
[+] [-] gsibble|3 years ago|reply
[+] [-] highwaylights|3 years ago|reply
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.
[+] [-] dmm|3 years ago|reply
[+] [-] weberer|3 years ago|reply
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.
[+] [-] native_samples|3 years ago|reply
[+] [-] protomyth|3 years ago|reply
[+] [-] albertgoeswoof|3 years ago|reply
What’s different about this?
[+] [-] aseipp|3 years ago|reply
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.
[+] [-] tialaramex|3 years ago|reply
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)
[+] [-] jrockway|3 years ago|reply
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.)
[+] [-] dwaite|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] anony999|3 years ago|reply
Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect
[+] [-] microtonal|3 years ago|reply
https://developer.apple.com/documentation/authenticationserv...
I am already using Passkeys on some websites.
[+] [-] samwillis|3 years ago|reply
[+] [-] smileybarry|3 years ago|reply
[+] [-] toomuchtodo|3 years ago|reply
[+] [-] firloop|3 years ago|reply
[+] [-] dyml|3 years ago|reply
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.
[+] [-] pronlover723|3 years ago|reply
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.
[+] [-] dane-pgp|3 years ago|reply
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.
[+] [-] psanford|3 years ago|reply
FIDO2 resident keys do support multiple identities for a single relying party (site).
[+] [-] alerighi|3 years ago|reply
[+] [-] yieldcrv|3 years ago|reply
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?
[+] [-] throwaway92394|3 years ago|reply
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?
[+] [-] gingericha|3 years ago|reply
[+] [-] mhoad|3 years ago|reply
[+] [-] tgsovlerkhgsel|3 years ago|reply
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)
[+] [-] epaulson|3 years ago|reply
[+] [-] hackererror404|3 years ago|reply
[+] [-] snowwrestler|3 years ago|reply
On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.
[+] [-] gruez|3 years ago|reply
[+] [-] blktiger|3 years ago|reply
[+] [-] xmdx|3 years ago|reply
[+] [-] babypuncher|3 years ago|reply
[+] [-] FollowingTheDao|3 years ago|reply
They must have considered this because that's would be a huge hassle.
[+] [-] jeroenhd|3 years ago|reply
[+] [-] paxys|3 years ago|reply
[+] [-] samwillis|3 years ago|reply
[+] [-] EtienneK|3 years ago|reply
[+] [-] SEJeff|3 years ago|reply
[+] [-] scottlu2|3 years ago|reply
[+] [-] camkego|3 years ago|reply
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.
[+] [-] stetrain|3 years ago|reply
[+] [-] whiteboardr|3 years ago|reply
[+] [-] sholladay|3 years ago|reply