From the moment you log into your Mac until you log out again (and, for some services, even when there’s no user logged in at all), it depends on its keychains, secure databases mainly stored in Keychains folders in each of its Library folders. Keychains are used to store, access and manage secrets, including passwords for all purposes, security certificates, private keys, passkeys, and secure notes. This article outlines their function.

login keychain

For each user, their default personal keychain is the login keychain, located in ~/Library/Keychains/login.keychain-db. This is unlocked automatically when you log in, and has the same password as your username. Even when you share your keychain in iCloud, this remains the default personal keychain. It’s here that you should store certificates, passwords, etc. for general use.

Although kept unlocked, readable and writeable while you’re logged in, that doesn’t guarantee access to its contents. If an app you’re using makes a call to the macOS security system to retrieve a stored password for its use, the macOS security system decides whether that app is trusted to access that information, and whether that keychain is locked. Assuming the password is stored there, the app is trusted (as Safari might be, for example), 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 dialog asking you for the password to that keychain to authenticate before it will provide the password to the app. That authentication dialog is very important: although malware might try to forge it, it contains distinctive features you should always look for:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component which has asked to access the keychain.
• The bold message text names the app or component which has called for keychain access, and states which item it’s asking to access: here, a named secure note.
• The smaller lettering specifies that it’s asking for the keychain password, that is the password used to unlock the named keychain, not your Apple ID or any other password.
• If you’re in any doubt about its authenticity, click on the Deny button and the request will be denied.
• If you’re in any doubt about its authenticity, you can open Keychain Access, lock the keychain there, and repeat the action while watching the keychain to ensure that it’s unlocked and handled correctly.

Older versions of macOS may display this slightly differently, but still contain the same key items of information to reassure you that the request is genuine.

As a user, you cannot determine which of your 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 your keychain. At its most restrictive, the system can limit all other apps from access to a particular secret in the keychain, but specific secrets can be shared between several different apps.

System keychains

For the system, there are two vital groups of keychains:

• in /System/Library/Keychains is 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 your 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 those 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 not normally kept unlocked. If I or an app want access to them, I’ll be prompted for that keychain’s password. For old login passwords, that’s just my old password from that Mac, of course.

Keychain in iCloud

If you have more than one Mac or Apple device, sharing your keychain in iCloud is recommended as an excellent way of ensuring that all have access to passwords. However, it can’t be used to share security certificates such as those used by developers for code-signing, which must be installed manually in each login keychain required. Keychain in iCloud does, though, share passkeys very well.

Conceptually, it’s better to think of Keychain in iCloud as synchronising certain types of data, including passwords and passkeys, between local login keychains, rather than storing them all in iCloud. Data in iCloud keychains are protected by end-to-end encryption, and are stored locally, transferred, and held in iCloud in encrypted form, which is the highest level of security provided by iCloud. Encryption keys use device-specific information to ensure that no one else can access keychain data. As that includes Apple, keychains in iCloud can’t be recovered by the iCloud Data Recovery Service: only you can access them on your Mac and devices when you’re signed into iCloud.

Tools

The bundled tool for working with keychains is the Keychain Access app, in /Applications/Utilities. A few third-party utilities, including my own free Mints, give additional information which can be helpful in resolving keychain problems.