Inside Sequoia’s new Passwords app

After taking a deep dive into the new Passwords app in Sequoia, I’m delighted with it. Unless you’re convinced that you need your secrets protected by another password, I think you should look carefully at it, as it could save you the subscription to a third-party password manager. This article looks inside it to explain which secrets it gives access to, as they can become confusing.

Macs and Apple devices have one common keychain, the Data Protection or iCloud keychain. This is the one that used to be accessed through Passwords settings in Safari and System Settings, which the Passwords app replaces. Macs also have additional keychains, including one that’s equally important, the user’s login keychain. The Passwords app has nothing to do with that, or any other file-based keychains, so I’ll leave them to the end.

Data Protection keychain

Since OS X 10.9, Macs have had one and only one Data Protection keychain for each user. If you share your keychain in iCloud, this is the local copy of that shared keychain and is known as iCloud Keychain; if you don’t share it in iCloud, then it’s known as Local Items instead. The local copy of this is normally stored in ~/Library/Keychains/[UUID]/keychain-2.db, where the UUID is that assigned to that Mac.

The Data Protection keychain can store almost all the standard types of secret, including internet and other passwords, certificates, keys and passkeys, but not secure notes. Prior to macOS 11, it only synchronised internet passwords using iCloud, but from Big Sur onwards it synchronises all its content, including passkeys, which are first class citizens at last. Unlike file-based keychains, secrets in the Data Protection keychain can be protected by the Secure Enclave, and can therefore be protected by biometrics including Touch ID, and Face ID on iOS and iPadOS. Hence they’re required for passkeys, which aren’t supported by traditional file-based keychains.

Passwords

The simplest category of secrets accessed by the Passwords app are internet and website passwords, listed in the All category, and candidates for the Security category if they’ve been compromised, reused or are weak. For these, Passwords is the only place to edit and maintain them, as the listing provided by Keychain Access is almost absent. Other categories such as application passwords don’t appear here, and are only accessible in Keychain Access. But for most common purposes, the Passwords app provides access to those you’re most likely to need.

Passkeys

Although not yet as widespread as they deserve to be, increasing numbers of websites now encourage you to use a passkey to authenticate, and so you should if you can. The Passwords app is the only way to access them, as they’re omitted completely from lists provided by Keychain Access.

Creating and using a passkey requires some form of biometric ID. If your Mac has a keyboard with Touch ID, that’s straightforward, but there’s a simple workaround when you need to use a passkey on a Mac without that, provided you have an Apple device with its own Touch or Face ID.

When you try to log into a passkey site and are prompted for biometric authentication, select the item in the popup menu below to use a passkey from a nearby device. Open the Camera on your iPhone or iPad and frame the QR code being displayed on your Mac. You should then be invited to sign in on the device. This may appear clumsy at first, but soon gets quite slick.

Wi-Fi passwords

Although these are also stored in the Data Protection keychain, what you see on each Mac and device also depends on which networks are listed in its individual Wi-Fi settings as Known Networks. To inspect those, open Wi-Fi in System Settings and click on the Advanced… button at its foot.

This can appear confusing, as you can easily end up with very different lists of known networks on different Macs and devices. On each, the networks shown in the Password app’s Wi-Fi group should tally with those in its list of Known Networks.

The remaining keychains on a Mac are file-based, and can’t be accessed by the Passwords app.

login keychain

For each Mac user, their default personal file-based keychain is the login keychain, located in ~/Library/Keychains/login.keychain-db. This is unlocked automatically when the user logs in as it has the same password as that user account. It’s here that each user should store their certificates, secure notes, etc. for general use on that Mac.

Although kept unlocked, readable and writeable while the user is logged in, that doesn’t guarantee access to its contents. If an app makes a call to the macOS security system to retrieve a stored password for its use, that system determines whether the app is trusted to access that information, and whether that keychain is locked. Assuming the password is stored there, the app is trusted, and the keychain is unlocked, then the password is retrieved and passed back to the app. If the app isn’t trusted or the keychain is locked, then the security system, not the app, displays a distinctive standard dialog asking for the password to that keychain to authenticate before it will provide the password to the app.

The user cannot determine which apps are trusted as far as the security system is concerned. Those are determined by the security system, the specific access it grants to an app, and to individual items in that user’s keychain. At its most restrictive, the system can limit all other apps from accessing a particular secret in the keychain, but specific secrets can also be shared across several different apps.

System keychains

There are two essential groups of keychains for macOS:

in /System/Library/Keychains, in the SSV, are SystemRootCertificates and others providing the set of root security certificates for that version of macOS;
in /Library/Keychains is the System keychain and others providing certificates and passwords required for all users, including those to gain access to that Mac’s Wi-Fi connections.

Custom keychains

Apps and users are also able to create their own keychains. Among those I have on my Macs are shared keychains with Parallels virtual machines, several for Microsoft apps, and some for Adobe’s products. I also tend to make a copy of the login keychain from my last Mac and copy it across under another name to ~/Library/Keychains, so that if I happen to have left any important certificates or passwords behind when migrating to a new Mac, I should be able to find them there.

Although these additional keychains may be included in the keychain search path, when macOS is looking for a secret kept in a keychain, unlike the login keychain they’re normally kept locked. If I or an app want access to them, I’ll be prompted for that keychain’s password. For old login keychains, that’s just my old login password from that Mac, of course.

One of the biggest security problems with file-based keychains is that they’re relatively easy for malware to exfiltrate and, given suitably powerful hardware, to brute-force access to their contents.

Keychain Access

The bundled tool for working with file-based keychains is the Keychain Access app, which has now been moved into hiding, and can be found in /System/Library/CoreServices/Applications. Much as Apple might like to deprecate this app, and file-based keychains generally, they can’t go away yet, no matter how good the Passwords app might prove.

References

Apple TN3137: On Mac keychain APIs and implementations
Apple Keychain Services