It’s essential to know when an authentication request is genuine. Without that knowledge, it’s all too easy to give your password away to malware, or to a badly-behaved app that’s trying to work around macOS security rules. By far the best way to authenticate now is using Touch ID, but many Macs don’t support it, either because they can’t, or because their keyboard doesn’t, and macOS doesn’t always offer it anyway. This article looks at how you can recognise genuine requests.

All Macs

The traditional non-biometric dialog is still in widespread use, and can appear on any Mac, even when Touch ID is available, and in Sequoia. I’ve been trying to work out a simple rule to predict when you should expect to see a classic request, and it appears to be associated with more traditional apps like Keychain Access, and when asking to access a file-based keychain such as the login keychain. But there don’t appear to be any simple and robust rules.

When an app needs to access a secret that requires authentication, 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 or other secret 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 that has asked to access the keychain.
• The bold text names the app or component that 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 that for your Apple Account 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, open Keychain Access, lock the keychain there, and repeat the action while watching the keychain to ensure that it’s unlocked and handled correctly.

Note that this doesn’t provide or ask for your user name, only the password for that keychain.

Macs without Touch ID

If Touch ID isn’t currently available to your Mac, either because it doesn’t support it, or because it doesn’t have a keyboard connected that includes Touch ID support, you should see the non-biometric versions of other dialogs requesting authentication. These are for purposes other than keychain access that require elevated privileges, such as for a process to run a privileged helper, or to make changes in System Settings.

This new vertical format should contain the following:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Enter your password to allow this.
• There are two text boxes, to contain your user name (already completed) and password.
• There are only two buttons, one of which may be OK or something more specific, and the other is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

Macs with Touch ID

If your Mac supports Touch ID (all Intel Macs with T2 chips, and all Apple silicon Macs), and currently has a keyboard connected to it with support for Touch ID, macOS should offer you the biometric version of that authentication dialog.

This should contain the following:

• The icon consists of a Touch ID fingerprint, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Touch ID or enter your password to allow this.
• There are only two buttons, the upper being Use Password…, and the lower is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

This dialog has distinctive behaviour that’s difficult to forge. When you place your fingertip on the Touch ID button on the keyboard, it will either authenticate successfully, so dismissing the dialog, or the dialog shakes to indicate you should try placing your fingertip on the button again.

If Touch ID authentication fails, or you click on the button to Use Password…, the dialog expands to resemble the non-biometric version above, with the following two important differences:

• The icon still consists of a Touch ID fingerprint, with a superimposed miniature icon representing the app or component.
• The instruction remains to Touch ID or enter your password to allow this.

Although you will continue to encounter classic non-biometric authentication dialogs on a Mac with full Touch ID support, you may also come across some that you might have expected still to use the old dialog, but which now use a biometric dialog, such as that below.

Perhaps as Touch ID support extends this will become more consistent.

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