Beware! Critical Apple bug wipes out passkeys

[iSecurityGuru]

I'm mad at Apple. They've botched up their passkey implementation that will result in disappearing passkeys! You can imagine, if your passkeys disappear unexpectedly, you will be locked out of your account.

I was almost locked out of my Google account yesterday. It was a close call. For the less tech-savvy people, they can easily lose access to their important accounts due to Apple's screw ups.

More details of the bug is explained here: https://terencekam.substack.com/p/beware-critical-apple-bug-wipes-out I'll be interested if anyone here can reproduce this bug. I could reproduce this bug myself a few times.

How did Apple's QA process let this show-stopping bug through?

 

[Darcon]

Quality Assurance is hard. Anticipating every scenario is difficult.

In this case, it could be due to how Apple operates. They expect each user to have their own Apple ID and that Apple ID is used at only a site or two. So thinking about managing multiple Apple IDs in the Passkey keychain for the same site did not cross their mind.

I can see several issues with this implementation.

When you go to a site, is it expected that Passkeys would prompt you to choose the login to use? This would break the seamless login experience, but would provide the functionality of multiple logins at one site. If you have multiple email accounts at Google and use the browser to access them, what is there in the Passkey protocol that can identify which account to use? A browser based access differentiates between the accounts with the order they were logged in. First account will have a "/1" in the URL, the second will have a "/2" and so on. The path changes based on the order logged in, so unless the Passkey protocol has a method to select which account to use.​

​

If you have 2 different iPhones on the same Apple ID (a scenario they don't expect) and each user has a different login to the same website, should it prompt for which ID to use or associate a particular ID with a particular device? If it does device, this breaks the seamless log in on any device scenario. If face recognition could go across devices, perhaps this could be resolved assuming you can link the face to the account.​

​

Storage of credentials seems to be a problem. It appears they are storing them by URL which causes the first login to be wiped out and replaced with the second.​

​

This is the early days of passkeys. There will be hiccups like this and more. There is a need for interoperability between Passkey implementations so the user is not locked into a particular solution. Passkeys need to be tested by more people like Terence Kam to verify it is usable by the masses before we adopt it as a primary solution to passwords. Though I would prefer SQRL.

 

[iSecurityGuru]

In iCloud Keychain, each passkey entry has a user name associated with a website. Optionally, you can also include a password, notes and OAUTH verification code in that entry.

For example, when I create the passkeys at Google‘s website by scanning the QR code, I saw a prompt to create a passkey for that user name. What happened was that in my iCloud Keychain, that passkey was added to the existing password entry in the iCloud Keychain. So, in that entry, it has:

• User name (Google email address)
• Password
• OAUTH verification code
• Passkey

When I created the passkey for my second Google account, I noticed these unexpected things in the iCloud Keychain:

• The passkey in the entry for my first Google account disappeared!
• A new entry appeared: It only contain the passkey with the user name of my second Google account.
• The entry (user name, password, OAUTH) for my second Google account was intact.

What I expect:

• A new passkey to be added to the entry for my second Google account.
• The existing passkey in my first Google account to be untouched.

That would imply that in the UI, you can choose which passkey to use for any given website. This is very similar to how passwords works.

Testing on webAuthn.io​

I went to https://WebAuthn.io, which is a test implementation of passkeys. This time, I was able to create multiple passkeys for that website.

The difference?

• In Google‘s website, the passkey was created on the iDevice by scanning the QR code on the desktop computer. In WebAuthn.io, the passkey was created natively through the iDevice’s web-browser.
• In WebAuthn.io, there was no existing entries in iCloud Keychain for that website.