This article explains how passwords and their replacement passkeys (‘WebAuthn’) work.

Passwords

When you create your password, the characters you enter for it are sent via TLS secure connection to the server. That server then applies a hash function to that password, and stores its hash, not the password. When a cryptographic hash function is used correctly, it should ensure that it’s not practically possible to discover your password from its hash.

When you try to connect to the site, your Mac sends your username (typically your email address) and password over TLS to the server. The server applies the same hash function to those characters, and compares that with the stored hash value for that username account. If they match exactly, then your authentication is complete, and you can access that site as that named user.

Several problems can result. Sometimes, servers store unhashed passwords, a major security failing, or the hash function used is weak, making it feasible to work out original passwords. The biggest shortcoming with passwords, though, is that anyone with your password has full access to your account, hence the widespread use of two-factor authentication (2FA), essentially an admission that passwords themselves aren’t sufficiently secure in the first place.

Passkeys

Each passkey consists of two keys (extremely large integers), one kept private, the other public. Although generated as a pair, it’s not feasible to discover the private key from the public one, ensuring that the private key remains secret.

When you create your passkey-protected account, your Mac creates a new pair of keys to be used only for that account, and the server is given only the public key, which it stores in your account record. While that can still include a username, your public key is sufficient to identify you from others.

When you try to connect to the site, your Mac identifies you, either using your username or public key, and sends your public key to the server. The server then sends your Mac a cryptographic challenge, which requires it to use its private key to generate a response that the server can recognise as coming from the same source as your public key. Access to your Mac’s private key is only provided following successful local authentication, which normally involves biometric identification by Touch ID (or, for devices, Face ID), although there are alternatives for Macs that don’t support Touch ID. The server checks your Mac’s response, and if it matches that expected, your authentication is complete, and you can access that site as that user.

Two-factor authentication should never be necessary, particularly when biometric identification is used to control access to the passkey.

Fallback

There’s nothing more comforting than a little book containing all your usernames and passwords, and passkeys can’t provide that. Even if you had access to your private key, writing it down on paper is hardly a practical solution, and there’s no facility to generate the public key from that anyway. However, it’s the very convenience of passwords which is their undoing: if you or anyone else can enter your password, the protection it provides is too easy to defeat, hence the proliferation of 2FA.

The best way to ensure that you’ll not lose access to a passkey is to share it, in its keychain, in iCloud. That ensures your other Macs and devices can also use that passkey, and use your account. However, that doesn’t provide for the situation in which all Macs and devices that can access that passkey are lost, or unavailable, something covered by iCloud keychain escrow.

Apple describes this in detail in its account of the security of passkeys. In essence, this provides a recoverable keychain to which only the user has access (making it separate from normal iCloud Recovery).

To recover a keychain, the user logs into their iCloud account with their normal Apple ID and password. That triggers 2FA, sending a message to their registered device with a PIN to be entered. Once past that barrier, the user then has to enter the device passcode. Only ten attempts are permitted before the escrow keychain is locked, and the only way any more attempts are allowed is following approval by Apple, otherwise the escrow record will be destroyed. There’s also an option to set up an account recovery contact who can ensure you retain access to your account even when you’ve forgotten your Apple ID password or device passcode.

Bear in mind that Keychain in iCloud, and iCloud keychain escrow, are available anywhere in the world with Internet access. They don’t rely on the physical existence of paper records, nor can they be burned, stolen or mislaid.