How does your keychain work?

Most of the time we take it for granted, and it just works. But when your keychain plays up, it quickly becomes very tedious, and can get in the way of the simplest of tasks. So how does (or should) it work?

I’ll keep my example simple, and use a local user keychain which is being asked for a stored password by a running app. This might be a browser, for example, wanting to retrieve the password which you use to access a particular website or service.

The app which you are using next makes a call to the macOS security system to retrieve the stored password for that particular service. What happens next depends on whether password is in the keychain, whether the app is ‘trusted’ to access that information, and whether that keychain is locked. Assuming that 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, passed back to the app, and inserted into the correct place in the web form.

If the app is not trusted and/or the keychain is locked, then the security system – not the app – will display the 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 some malware might try to forge it, it contains some distinctive features which 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. In this case, it is given as a signature, but normally it is the app’s name. That same message states which keychain it is asking to unlock: here, as is almost always the case, the default login keychain, named login.
  • The smaller lettering specifies that it is asking for the keychain password, that is the password used to unlock that specific keychain, not your Apple ID or any other password.
  • If you’re in any doubt about its authenticity, you can click on the Cancel button and the request will be cancelled.
  • 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 is unlocked and handled correctly.

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, and 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 specific ‘secret’ in the keychain, but specific ‘secrets’ can be shared between several different apps.

The most common reason for the security system repeatedly asking you to authenticate, to enable apps to access your keychain, is because your keychain is being locked after that access. When that keychain is locked, even requests from trusted apps will result in the system displaying the authentication dialog. So if you find yourself having to keep entering your login keychain password, it is almost certainly because that keychain – your default user keychain – is being locked automatically. You can control that using Keychain Access.

Another reason for being asked to authenticate more often than you should is when you have multiple user keychains, and the items being used are stored not in your default keychain, but a secondary user keychain. This should become clear if you read the dialogs carefully, as they will not refer to your login keychain, but to that other keychain. If you intend keeping that secondary keychain, you should ensure that it does not lock automatically (use Keychain Access to do that), but unlike the login keychain it will not be unlocked by default when you log in, so you will still have to unlock it at least once.

Thankfully, iOS devices only have one local keychain, which is available to all apps; they also have a distinct iCloud keychain when connected to iCloud and sharing their keychain.

Using an iCloud keychain simplifies access to shared ‘secrets’ between your different devices, and allows you ready access to website passwords, for example, no matter whether you’re using your Mac or iPad, but it also makes keychains more complex.

This is because an iCloud keychain does not replace a local one, it supplements it. Some items can only be stored in your local keychain, and continue to be kept in the login keychain as a result. Those items which are marked as being synchronizable are put into the iCloud keychain, and are then automatically synchronised across all other iCloud keychains on your other devices.

When an app makes a call to retrieve a password through the security system, if you have an iCloud keychain active, the password may need to be retrieved from either the local or shared keychains. Authentication dialogs should then make that clear.

Keychains are little more than databases containing entries which can be encrypted, and which have strict and elaborate access control. Like all databases, it is possible for the data within them to become corrupted, and for them to stop working properly. Keychain Access allows you to check and inspect entries in the keychain database; although it no longer has a tool which can repair damaged keychains, if the data it shows are correct, and the keychain is unlocked, apps which are entitled to access specific entries should be perfectly capable of accessing them without your being asked to authenticate.

If you are having to authenticate a lot, it suggests that they keychain is being locked automatically, or that the app trying to access those data is not trusted to do so by the security system.

Note: Mark kindly informs me that some MacBook Pro models which develop ribbon cable faults – a not uncommon hardware failure – repeatedly ask for the keychain password. So if you have a MacBook Pro which starts to misbehave like that, remember that it could be a ribbon cable which is causing the problem. That seems most bizarre!