What is wrong with Apple Passkeys?

Quite a lot.

I assume you already know how u2f (Universal Second Factor) works, what is webauthn standard developed by Fido alliance is, and so on. The Wikipedia article is detailed enough if any of those words sound unfamiliar to you.

Or, at least, here is a picture to freshen your memory, simplified:

(image credit: Paul Haskell-Dowland)

You touch a fingerprint sensor, and the phone “magically” logs you in. It is secure, and phishing-resistant. For those worried about data collection, your fingerprint does not go anywhere outside your phone — even Apple does not keep a digital copy.

Don’t get me wrong; I am a big fan of webauthn. It is the best thing that has happened to user authentication since OpenID (the “social network login” button we all love). But as always, the devil is in the details. Apple introduced a controversial “improvement” to webauthn called Passkeys, which could impair the security of your most valuable online resources.

With “pre-Passkeys passwordless”, you could secure the trust relationship between your computer and a service, say, a crypto exchange. It was a strict one-to-one relationship with known parameters. If you want to use another computer, phone, or tablet, you either authorize it explicitly or buy a hardware token device that needs to be physically present to let you in and access your funds, like one of those:

(source: https://twitter.com/herrjemand . don’t worry, one would be enough for all websites!)

Physical presence is an important trait as it could protect the online service in case of client’s workstation compromise. The trust relationship is formed between the physical key (or TouchID processor that is running independently from iOS) and the operating system only acts as a transport. Touching the key button explicitly authorizes cryptographic authentication via a mechanism that is hard to subvert even if the computer is compromised.

So, you explicitly know which device has been used for authentication in a particular session and, of course, with most services you can have multiple devices tied to your account.

With Passkeys, everything changes. For the sake of “convenience”, there is not just your device or token on your side. It is Apple’s iCloud Keychain, which covers all your devices and, in a certain sense, Apple itself. Your attack surface is now enormously huge and includes nasty scenarios like theft of any device to bypass the biometric lock, “AppleID access recovery” (down to SIM swap attacks!), service shop technician going rogue, etc. The rabbit hole is deep.

You, as user, have no way of understanding, yet proving, what device has been used for authentication. It’s all “iCloud Keychain”.

Let’s consider what is already available if you stay within the Apple ecosystem:

• Good, old, and (as explained later) dead passwords
• Keychain: drop-in replacement for passwords with a shared key’s security properties: it is securely generated, automatically synced via iCloud to all your devices, and works with zero friction. The only drawback is that the Keychain password can be copied and used outside the Keychain.. which may be tempting if you use at least one non-Apple device.
• u2f (Universal 2nd Factor) token leverages the webauthn standard to securely authenticate you anywhere with a small hardware dongle that communicates via USB, NFC, or Bluetooth. In this text, the terms webauthn and u2f generally refer to the same thing, don’t get confused! The webauthn private key is generated on the token and cannot be exported or duplicated; there is no more shared secret between client and server, and the public key cryptography is used instead.
• u2f on the T2 chip is like a token, but it is physically embedded in your Mac, iPhone, or iPad and protected by the biometric scanner.

Passkeys (singular?) is essentially a “portable” webauthn token that sync across all your devices via Keychain, just like your password.

Security properties of different authentication methods

Summary: Passkeys technology is not that better than Keychain passwords; however, before Passkeys you had a nice combination of one ultra-convenient authentication method and one ultra-secure (u2f), and now the later one lost its most crucial security properties. “Retiring” old built-in passwordless authentication was a mistake.

1. Passkeys is not a dramatic improvement in authentication security.
   I would say that a more important thing happened a long time ago — and was not considered a revolution. And that thing was the good old Keychain password manager.
   When Passkeys proponents say it is a huge step forward to move away from “old insecure passwords”, it is not fair. Because the password is already dead: iCloud Keychain has been here for almost a decade, since 2013. You still may use insecure and typically re-used, leaked, compromised, etc., human-generated passwords (humans are notably bad entropy sources). But you do not need to. Everything was flexible enough: iCloud password is available if you need one-click effortless authentication everywhere, and biometry-backed webauthn is the ultimate method if your security requirements are more strict. You want to ensure the attacker cannot take advantage by hijacking your iCloud account or getting unauthorized access to only ONE of your devices. With sufficient effort, biometry could be bypassed; we all know that. If your iPhone is lost or stolen it is better if it would not contain all the keys to the kingdom. If, for some reason, neither of the two scenarios fit your case, buy a Yubikey that will make your authentication portable (say, use it as a backup access method and put it in a safe place).
2. Passkeys is an abuse of the webauthn security model.
   The cornerstone of webauthn security is non-exportable keys. One key, one token. Enroll a new device if you want to authenticate more than one device using a built-in token. That’s how it works because we want to set a baseline expectation for the private key security; that’s why major browsers did not implement the software security element for u2f. Technically, there are no obstacles to storing webauthn keys in a user profile, just like passwords and certificates, but it has not been done for a reason. An optional authentication count value is shared between client and server to ensure no “rogue” authentication ever happens undetected. The latest webauthn draft, however, contains an amendment that looks like a last-minute hack to make Apple’s implementation legitimate. Yuck!
3. Passkeys break the enterprise use case.
   A modern enterprise needs to be flexible. The era of tightly controlled workstations is gone with the emergence of BYOD and WfH. Everyone needs a reasonable balance of security and accessibility. Apple was never prominently friendly to enterprise security requirements, but hey, webauthn was a thing! It was the ONLY way to ensure both basic device attestation (that it is precisely that one computer, phone, or tablet is used for access as intended and not some random friend’s computer that happens to be nearby) and key attestation (that the authentication key is appropriately secured and has not been replicated or stolen). Both requirements are crucial for functional Zero Trust adoption. With Passkeys, neither could be guaranteed. Apple does not support multi-tenancy, either: that means there is a single Apple ID per device, and for most companies, it is a personal one.
4. Things will only get worse when others jump on the bandwagon.
   Questionable as it is, Passkeys provides the consistent security of the Apple ecosystem; it is just as good as it is, but not worse. And we may hope Apple may blacklist devices with unpatchable security flaws in hardware (causing major unrest among users, no doubt). Imagine any heavily backdoored Chinese Android being able to sync with your private key.

Now let’s see the bright side. Is there anything else that provides Passkeys an advantage over Keychain? Yes, quite a few things — there are attack vectors that Passkeys mitigate while Keychain does not.

• More sophisticated phishing attempts may still convince the user to override the default system behavior and authenticate at the wrong website, and thus the attacker may steal the password. With Passkeys, it is technically impossible.
• Harvesting user passwords via a malicious browser extension. Well, a malicious extension may steal your browser session or inject arbitrary data anyway, but with Passkeys, there is no password involved, and the private key would be inaccessible to the attacker, so while the session would be compromised, the authentication is still intact and any changes made there are noticeable.
• Similar concerns are applicable to remote code execution exploit in the browser context. However, a compromised browser may try to trick a negligent user to approve a bulk password export. Keychain dialog provides explicit hint about what is going to happen, but user may ignore it.
• The password may be compromised server-side or via TLS fronting services like Cloudflare.

What Passkeys does not mitigate, however, is a severe Keychain vulnerability that could provide an attacker full access to the decrypted data. Would it be a password or a private key, there would be no difference.

Addendum: on third-party browsers

I have to admit that essential ecosystem boundaries are quite weak on desktop MacOS. On the contrary, all iOS apps enjoy the same Safari API to implement website authentication and thus are provided with transparent Keychain access to stored passwords. O̶n̶ ̶M̶a̶c̶O̶S̶,̶ ̶e̶a̶c̶h̶ ̶a̶p̶p̶ ̶i̶s̶ ̶r̶e̶s̶t̶r̶i̶c̶t̶e̶d̶ ̶t̶o̶ ̶a̶ ̶s̶u̶b̶s̶e̶t̶ ̶o̶f̶ ̶K̶e̶y̶c̶h̶a̶i̶n̶ ̶e̶n̶t̶r̶i̶e̶s̶ ̶b̶e̶l̶o̶n̶g̶i̶n̶g̶ ̶t̶o̶ ̶a̶ ̶s̶a̶m̶e̶ ̶s̶o̶f̶t̶w̶a̶r̶e̶ ̶v̶e̶n̶d̶o̶r̶ ̶-̶ ̶t̶h̶u̶s̶ ̶n̶e̶i̶t̶h̶e̶r̶ ̶C̶h̶r̶o̶m̶e̶ ̶n̶o̶r̶ ̶F̶i̶r̶e̶f̶o̶x̶ ̶m̶a̶y̶ ̶a̶c̶c̶e̶s̶s̶ ̶S̶a̶f̶a̶r̶i̶ ̶p̶a̶s̶s̶w̶o̶r̶d̶s̶. Unfortunately, Google and Mozilla decided to ignore the Keychain. And once you replicate a Keychain entry to Chrome password manager, it is not just a manual inconvenient action that requires copy-and-paste — now your password is exposed to Google ecosystem where security expectations are much lower. Passkeys, however, are accessible from any browser or app. Don’t ask me why Apple did nothing to deal with the situation before, the relevant bugs in Apple, Mozilla and Google bugtrackers are up to 20+ years old (original Keychain is older than iCloud itself!) and are resolved as WONTFIX.

Orignally posted at https://glanc.ltd/articles/what-is-wrong-with-passkeys/
Thanks to everyone who helped me with this article: Kevin Reed, Oleksander Nikitin, Oleg Tsarev! It would not be half that readable without you.