Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What a bunch of none sense .

So instead of storing a password they will store a file in your computer? Now I am tied to the computer I am currently using? What happens if the hard drive gets wiped?

Passwords are great because they can be memorised and used any where. There is no need for Apple to do this as any password manager can do the same really if they agree on a standard. Either way, passwords on servers are stored in encrypted form therefore any one who access them can't make much use of them because it will like reading hieroglyphs without the Rosetta Stone.

None the less, general public will find it amusing that "it just works!" until their data gets corrupted or lose access to icloud.
 
For those asking how this works, here's a simplified explanation based on my understanding from reading and watching the online resources about it.

To register on a new site, say widget.com
  1. You go widget.com and navigate to its new-account creation page
  2. Type in what you want your username to be and then click "create account"
  3. Your phone will bring up a system sheet confirming you want to create a credential for widget.com. After you confirm, the phone will create a site-specific credential token (called "passkey" in FIDO parlance), the security of which is based on public-key encryption.
  4. The phone will store the token and private-key portion of the token on your iCloud Keychain. It will share the public-key portion of the token with widget.com so it can save it on their server.
Whenever you visit widget.com in the future, Safari will know you have a saved credential for the site and will confirm you'd like to login, similar to how it works today for traditional passwords saved in your keychain, including you proving you have rightful access to your keychain (Face ID, passkey, etc...). But instead of a password, Safari will present the passkey (token) to the site (which it already has stored on their server to compare), then verify you're the rightful owner of the token by proving to the site that your phone has the private key associated with the token (challenge/response).

This is an improvement over passwords because there is no password to be stored on a server or presented for each site, which reduces the attack surface of your credentials. It also solves the problem of weak user passwords, or users reusing their password across multiple sites.
Thank you for the clear explanation. I see the value for individual accounts. However, some accounts are shared with others. Will I be able to share passkey's for certain shared accounts with my wife with such a system?
 
  • Like
Reactions: DotCom2
Thank you for the explanation. Two quick questions. 1) Will the passkey token used by widget.com enable widget to track my activity across the internet (in the same way that widget.com can track my activity with cookies). 2) what happens if my phone breaks or I loose my phone? Presumably I am locked out of all my accounts until I buy a new device?
Btw, in addition to having your passkeys in your iCloud Keychain for recovery (my previous reply), Apple also added a new keychain escrow feature in case all your Apple devices are lost. You can read about it here - scroll down to "recovery security"

 
I think you can’t. That is part of the design, no one but you can access your accounts.
I'm afraid that you are right. But that means that the design is flawed. For example, my mortgage bank has given my wife and me one account. With a passkey, we would have to choose who has access. This example is not unique in any way, even though it doesn't apply to the majority of accounts. Yet, these are very important accounts where passkey's won't be usable.
 
Thank you for the clear explanation. I see the value for individual accounts. However, some accounts are shared with others. Will I be able to share passkey's for certain shared accounts with my wife with such a system?
Good question. I don't have a definitive answer but I'm assuming passkeys can be shared using the same AirDrop mechanism as password sharing, which is described here:

 
What makes a yubikey interesting for you in the future while you already carry a phone?
YubiKeys with FIDO and Passkeys (With FIDO) are the same. They both use the FIDO and WebAuthn standard. The difference is that the YubiKey stores the Private key ONLY on the YubiKey. It is never exposed outside the Key and can never be extracted. Passkeys use the same technology, but he private key is synced across an internet account (Keychain). This potentially exposes the private key should the internet service be compromised. This is not a threat vector that I am willing to live with.

Any authentication service that supports FIDO2/WebAuthn today, will support Passkeys. You can even register both FIDO keys and Passkeys on the same website. Apple has made FIDO a household name (and called it Passkeys to boot). This should drive passwordless authentication to the masses. This is a good thing. Passwords are just too easily hackable and other phishing attacks make them obsolete.
 
  • Like
Reactions: tomnavratil
I've been using Microsoft's passwordless account option since they lunched it last year and it is great! It uses the Microsoft Authenticator app to authenticate. It will be interesting to see which implementation I like better. I can have the MS Authenticator app installed on more than one device in case I lose one, and my wife has my MS account in her Authenticator app as an extra backup. I don't think we will be able to do that with Apple's version.


Question, does this mean that Apple can never implement this for Apple IDs? All the documentations say that to restore Passkey on a new device that your Apple ID password is needed. So it sounds like they can not implement this for Apple ID and remove the password because, then how would you sign into a new device if you no longer have the old device.
 
So I’ve no idea how these work. Sounds great if you are using your own device. But what happens if you left your phone at home, and want to log on to, e.g. internet banking on a friend’s PC. Will it just be impossible? Or you’re on holiday and lose your phone, are you locked out of everything until you get your phone replaced when back home?

You need your phone, or another device synced with your passkey. If this is bad for you, then you should continue to use passwords. The problem though with passwords is how many people use bad passwords or old breached passwords or variants of passwords, etc. Passkeys eliminate these problems, so you have to assess what you want with your online accounts, do you want to be able to login at random computers, or do you want better account security?

So that sounds that Passkeys will only work if a website offers it. In the Apple Event it sounded like you can replace any passeord with a Passkey.

They never made it sound like that. They were quite clear this is based on an open standard that web servers need to support, webauthn.

Does anybody know how this will work if I share an account with my partner? For example, we have one account for our newspaper app or for our energy company, could I then share my passkey?
You can send her the passkey over Airdrop. People can share accounts using this method.
"The phone will store the token and private-key portion of the token on your iCloud Keychain",

1. but what you have not explained is what entities (companies) have access to the token and private-key portion?
2. Does it work with a local private keychain?
3. Can the user control access to the token and private-key?

This seems like other Apple security features, in that it is half baked to make Apple look good.
1. No one but you has access to the private key. It's stored on device, though it can be synced to other devices with your iCloud account (using another layer of encryption between devices so even Apple can't get your Passkeys). The "token" you speak of sounds like a session parameter which companies do need to use to track your logins, but this has nothing to do with Apple's technology, everyone is using session variables or else there would be no sessions.
2. It is a system keychain, it is local and it is private but it's not something you can directly access.
3. As said above, private key is local but Apple doesn't give you direct access to it, presumably so you can't send it to a scammer online who would use it to steal your stuff.
What a bunch of none sense .

So instead of storing a password they will store a file in your computer? Now I am tied to the computer I am currently using? What happens if the hard drive gets wiped?

Passwords are great because they can be memorised and used any where. There is no need for Apple to do this as any password manager can do the same really if they agree on a standard. Either way, passwords on servers are stored in encrypted form therefore any one who access them can't make much use of them because it will like reading hieroglyphs without the Rosetta Stone.

None the less, general public will find it amusing that "it just works!" until their data gets corrupted or lose access to icloud.
You're recommended to backup your device, or you use more than one device (iCloud syncs passkeys with another layer of encryption). If you don't backup your device, then yes please use passwords, but most people would be well-served with passkeys, which are fully optional by the way, you can still use passwords and not give a crap about the existence of passkeys.

Passwords have their use but a lot of people are better served with passkeys. For instance, we don't need 2-factor any more with passkeys.

my understanding is that reputable companies never have your passwords, they have something called "hashes" which is encrypted form of the password
Hashes are used to compare a supplied password while not needing to know the password itself. The issue with hashes is they have hash tables generated to guess at a person's password, and the worse a person's password is, the more they are susceptible to a data breach. Such a thing is not possible with passkeys, as they can have a full breach of the server side public key and it won't help an attacker at all.

I'm afraid that you are right. But that means that the design is flawed. For example, my mortgage bank has given my wife and me one account. With a passkey, we would have to choose who has access. This example is not unique in any way, even though it doesn't apply to the majority of accounts. Yet, these are very important accounts where passkey's won't be usable.
You can share passkeys over Airdrop. You can also use multiple passkeys on an account, so it's possible for an Android device to have its own passkey and an Apple device has a passkey.
 
So I’ve no idea how these work. Sounds great if you are using your own device. But what happens if you left your phone at home, and want to log on to, e.g. internet banking on a friend’s PC. Will it just be impossible? Or you’re on holiday and lose your phone, are you locked out of everything until you get your phone replaced when back home?
If your bank is competent it should have some form of 2FA at this point. You shouldn’t be able to log in to your account even today on your friend’s PC if your phone is left at home. Also, PassKey is supposed to work alongside passwords, which should mean it eventually becomes a choice of either a 1-step passkey from a trusted device or a password + 2FA combo when you try to log in somewhere.
 
I'm afraid that you are right. But that means that the design is flawed. For example, my mortgage bank has given my wife and me one account. With a passkey, we would have to choose who has access. This example is not unique in any way, even though it doesn't apply to the majority of accounts. Yet, these are very important accounts where passkey's won't be usable.
How so? The passkey for an account is able to be set up on multiple devices and platforms. What’s to stop you from setting up passkeys on both yours and your wife’s devices for that single account?
 
  • Like
Reactions: anshuvorty
YubiKeys with FIDO and Passkeys (With FIDO) are the same. They both use the FIDO and WebAuthn standard. The difference is that the YubiKey stores the Private key ONLY on the YubiKey. It is never exposed outside the Key and can never be extracted. Passkeys use the same technology, but he private key is synced across an internet account (Keychain). This potentially exposes the private key should the internet service be compromised. This is not a threat vector that I am willing to live with.

Any authentication service that supports FIDO2/WebAuthn today, will support Passkeys. You can even register both FIDO keys and Passkeys on the same website. Apple has made FIDO a household name (and called it Passkeys to boot). This should drive passwordless authentication to the masses. This is a good thing. Passwords are just too easily hackable and other phishing attacks make them obsolete.

I'm definitely no expert in cryptography or this type of password security. But from my experience using some of it in the past? It seems like what Apple's done here makes sense from the perspective of many of the users just doing so for personal use, as opposed to part of a managed corporation issuing employee or contractor logins?

The places I worked where a Yubikey was required used it in lieu of typing in a password, but you still had a password for your company login (and needed to use it, at least for email authentication). The thing was, a Yubikey could fail on you and with no other place the private key was stored? The only fail-safe they had was issuing people a pair of Yubikeys and highly recommending people register both of them in their initial setup process. If people neglected to do that or damaged/lost BOTH Yubikeys somehow? The alternative was to issue them a new pair and have an administrator reset their account so they could do the initial pairing process again.

For your typical consumer using "Passkeys", the (small) risk that storing the private key (encrypted) in the cloud via Keychain could result in getting hacked is weighed against the problems people would have if their only Apple device (say, an iPhone) fails on them or gets lost/stolen, and the private key was only stored in it.
 
A hash can be stolen just as a password can. Same difference.
Not necessarily. As a software engineer who has implemented password security before, if you do it right, no one can get it unless they physically steal the computer it's stored on. Most businesses use databases like Oracle or SQL Server. What you would do is to see the password when the user first creates the account one-time only and store a write-only hash in the database. You cannot pull that item from the database no matter what because it's not retrievable.

Any stored procedures that use the password would take the input from the subsequent login attempt, pass a hash of that password to the database and ask the database if they match. At no time is the password ever actually retrieved. If the company is reasonable competent, your password cannot be stolen even by a database dump because any commands will be refused to read the password tables. If they're not competent, well, you lose your data.
 
  • Like
Reactions: Vlad Soare
I'm definitely no expert in cryptography or this type of password security. But from my experience using some of it in the past? It seems like what Apple's done here makes sense from the perspective of many of the users just doing so for personal use, as opposed to part of a managed corporation issuing employee or contractor logins?

The places I worked where a Yubikey was required used it in lieu of typing in a password, but you still had a password for your company login (and needed to use it, at least for email authentication). The thing was, a Yubikey could fail on you and with no other place the private key was stored? The only fail-safe they had was issuing people a pair of Yubikeys and highly recommending people register both of them in their initial setup process. If people neglected to do that or damaged/lost BOTH Yubikeys somehow? The alternative was to issue them a new pair and have an administrator reset their account so they could do the initial pairing process again.

For your typical consumer using "Passkeys", the (small) risk that storing the private key (encrypted) in the cloud via Keychain could result in getting hacked is weighed against the problems people would have if their only Apple device (say, an iPhone) fails on them or gets lost/stolen, and the private key was only stored in it.
The FIDO spec actually calls for websites to allow multiple FIDO security keys to be registered. Specifically for backup purposes. I always register at least three. Passkeys could be a 4th.

Yes, Passkeys (IMHO) are designed for the consumer, not the enterprise. Doubtful that any business will allow a corporate credential (Passkey) be stored on a personal phone. There is still a place for both security keys and passkeys in the world.

The FIDO Alliance has been working with industry on the FIDO solution for almost 8 years. Apple and Microsoft are finally bringing this into the mainstream. It's about darn time!
 
Only your phone will have access to the private key, which itself will be protected on the keychain with your existing passcode. The keychain can be local-only if you prefer, or replicated securely online in iCloud.
How is it replicated securely on-line with iCould if I cannot set the encryption key?
 
It's not an Apple standard. All the major companies are adopting this open standard.
The open standard is not the problem, it is the way the private info is stored in the Apple ecosystem. Can I manage my own encryption keys in the Apple ecosystem? I think not.
 
Only your phone will have access to the private key, which itself will be protected on the keychain with your existing passcode. The keychain can be local-only if you prefer, or replicated securely online in iCloud.
Please explain how "replicated securely online in iCloud" works. I don't ever see an option where I can set my iCloud encryption key. So how is it that you claim that Apple can't access it. What encryption key protect it?
 
Please explain how "replicated securely online in iCloud" works. I don't ever see an option where I can set my iCloud encryption key. So how is it that you claim that Apple can't access it. What encryption key protect it?
Your keychain is encrypted with a combination of device-unique data and your passcode. The encrypted keychain then replicated into the cloud via end-to-end encryption.
 
How is it replicated securely on-line with iCould if I cannot set the encryption key?


There is also some more details about how the Secure Enclave and the initial key generation in the Apple Platform Security Guide.
 
That is just a cheap trick be Apple to make it more difficult to leave the Apple ecosystem and switch to Android, as long as you still need an iPhone in order for your Passkey to work on a Windows device. Hacking a good password is virtually impossible. Even if you only use nunbers and lowercase letters, there are 36 combinations for each letter of the password. So to more letters already makes it 1000 times more diffictult to hack.

Hacks usually happen at the server level and not at the user level. When millions of passwords for Ebay or Yahoo were hacked, Passkey would not have prevented that.
Passkey absolutely can solve the servers getting hacked issue. Not sure you quite get how they work.
 
Read a bunch of comments, and they all describe upside. However, being me, I know there must be drawbacks of this new tech, however small it might be. But what are they?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.