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.

Postscript

For those wanting to import CSV files into Passwords, the fields that it exports are: Title,URL,Username,Password,Notes,OTPAuth. I expect that reformatting a CSV file exported from another password manager to conform with that, including that as its first line, will make its import more likely to succeed. A spreadsheet such as Numbers is good place to perform editing on CSV files.

References

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

It’s strange to think that, as we’re wondering whether and when to upgrade to Sequoia, Apple’s engineering teams are already at work on macOS 16. While they’re thinking out what we’ll chew over next summer, you may well be asking if you should upgrade to 15.0 next week, wait for the AI features coming in 15.1 next month, or leave your decision until 2025?

For those with Macs and iPhones that can both be upgraded, iPhone Mirroring is probably the most obviously attractive new feature. It completes the integration of Continuity, and could transform your workflows. Fortunately for such a key feature, it should work with all supported Macs, not just Apple silicon models. There’s one small and temporary disappointment, though, as drag and drop between Mac and iPhone isn’t expected in 15.0, but in an update “later this year”.

The new Passwords app should spare you from wanting to pay for a third-party password manager. This is much more than just shelling out the existing Passwords feature from Safari and System Settings, and at last gives full control over passkeys and other shared secrets in your Keychain in iCloud.

Although some see Sequoia’s new dislike for apps that aren’t notarized (or from the App Store) as an unnecessary burden, for most of us this will raise the bar against running malware and increase our margin of safety. It has been some time since any malicious software has been successfully notarized, and most of the current epidemic of stealers aren’t even signed with a Developer certificate. Instead, they usually prompt the user to open them using the existing Finder bypass, something that no longer works in Sequoia without explicitly and individually giving permission to that app in Privacy & Security settings.

It will be interesting to see how malware developers respond to this challenge, as trying to give the user detailed instructions as to how they can be run without being blocked by Gatekeeper should now arouse the suspicion of even the most careless and inattentive.

While we’re on the subject of security, remember that Sequoia is now the only version of macOS that gets full security updates over the coming year. While Sonoma and Ventura will still get some, if you want the lot then you’ll need to upgrade. Monterey, of course, now gets none at all. This gets more brutal when considering other bugs that aren’t relevant to security: those will only be fixed in Sequoia, not even in Sonoma.

For those who virtualise macOS on Apple silicon, support for Apple ID gives VMs access to iCloud Drive at last, although it stops short of enabling the App Store or its apps, so isn’t as useful as it should have been. There are two important restrictions to this:

• Apple ID can only be used in a Sequoia guest running on a Sequoia host, and
• the Sequoia VM has to be built from a Sequoia IPSW file, and can’t be upgraded from a Sonoma or earlier VM.

As long as your Mac stays with Sonoma, you won’t be able to use Apple ID in any of its VMs, including Sequoia. This still leaves us with the paradox that Apple wants us to buy and run apps from its App Store, but VMs are the one place where you can’t use them.

Among the less prominent improvements that have caught my attention are a timed messaging feature of Send Later in Messages, and a batch of improvements in Freeform. If you’ve come to like that relatively new app, you should find Sequoia worth the effort. I’ve also been impressed to see one of the oldest bugs remaining in the Finder has finally been addressed in macOS 15. I’ll be putting the bunting out in celebration after I’ve upgraded on Monday.

As with Sonoma, some of the most important new features haven’t been documented even for developers. Among those are changes to XProtect in terms of its updating and management, and speculation as to how that might affect its function. As I have explained, XProtect’s detection rules have grown enormously over the last few months, and it’s likely that Apple intends improving how XProtect can apply its Yara rules, and making their updating more efficient.

Finally, Sequoia is almost certainly going to be delivered as if it were an update, and won’t download its installer app unless you’re upgrading from a significantly older version of macOS, just as has happened in all recent macOS upgrades. Remember that upgrading macOS these days comes with a one-way ticket: changing your mind afterwards will cost you a lot of time and messing about to step back to Sonoma. However, accidental upgrades shouldn’t be feared. For instance, if you inadvertently click the Install all updates button in SilentKnight and want to reverse that for a macOS update, let the download complete, shut down, start up in Safe mode, wait a minute, then restart in normal mode.

Whatever you choose tomorrow, I hope it works well for you. And in case you’re wondering, if you’ve got an Apple silicon Mac, you’re going to love 15.1.