How could someone steal your keychain’s secrets?

Putting all your Mac’s secrets in just a couple of places makes those prime targets for attack. Given that your Mac’s keychains can’t be locked away in hidden vaults, otherwise they couldn’t do their job, how might someone steal your secrets from within them?

Recall that your Mac has two different types of keychain:

file-based keychains, including most significantly your login keychain, which aren’t shared,
one Data Protection keychain, normally that shared in iCloud, or stored on your Mac as Local Items when it’s not shared.

Both types are stored locally in your Mac’s several Library/Keychains folders, and the local copy of the Data Protection keychain is synced via iCloud when that feature is enabled. Although /Library/Keychains will contain some attractive secrets, main targets are the login and Data Protection keychains held in ~/Library/Keychains.

How to tell whether a password is stored in the right keychain

Given the better protection provided by the Data Protection keychain, it’s good to have confidence that the apps you use that keep secrets do so using that, rather than a file-based keychain. Background processes and helpers that are run by launchd can only use file-based keychains, but an app with a GUI should be free to use either.

The simplest test is to enter a new secret into the app, see whether that appears in the list in Password settings, and syncs to other Macs and devices sharing the same keychain in iCloud. As not all secrets are visibly shared, if you can’t see the synced password, watch the Modified timestamp on the keychain-2.db file in the ~/Library/Keychains/UUID folder, where the UUID is that Mac’s Hardware UUID shown in System Information. If the password is saved instead to the login keychain, then the Modified timestamp on ~/Library/Keychains/login.keychain-db should update instead.

Searching unencrypted keychains

The simplest way for an attacker to try to obtain data from a keychain is to look through for contents stored without being encrypted. As file-based keychains remain in their traditional format, some of the metadata, but none of the secrets, may appear in plain text. In the past, before the use of Data Protection keychains to store website and other passwords, these could have been useful to an attacker, but are of limited value now. In contrast, Data Protection keychains appear to encrypt their entire contents, making this approach worthless with them.

Stealing the keychain password

By far the easiest way for an attacker to obtain your login keychain password is to ask you for it, by displaying a fake dialog prompting you to enter it. Without checking such dialogs carefully before giving them a password, many users fall for this simple trick. If you’re in any doubt, don’t enter anything into the dialog and click on the Deny button every time.

This trick is most effective in attacks against the login keychain, which lacks the more advanced protections of the Data Protection keychain. Those limit access to secrets according to app entitlements, for example, making it impossible for an app without a specific entitlement to gain access to many of its secrets. Other secrets may not even be stored in the Data Protection keychain, but kept in the Secure Enclave.

Stealing the keychain

If an attacker can’t trick you into giving away the password to a keychain, then they could try to brute-force the password instead. That requires ‘exfiltrating’ (copying) the keychain from your Mac to a remote system where they can run software to guess the password. While your Mac’s Secure Enclave can impose limits on the number of times passwords can be tried, there’s no way to impose such limits on the keychain when it’s on another system, so their software will run many millions of attempts to guess the right password if necessary.

The same approach can be used if an attacker gains physical access to a device sharing the same passwords, in which case they’ll prefer to try this from the least-protected device, such as an old Mac or device that’s sharing the same iCloud keychain.

Forcing a password takes computer power, suitable software, and time. One popular means of accelerating the process is to run as much as possible on a GPU, but that’s only effective for certain types of password. Forcing is normally only feasible when individuals are being targeted, rather than as part of a general campaign of attacks. Different types of password and vault/keychain require different approaches, and some can be faster to force than others. Among the most difficult to force at present are those used by LastPass, while macOS file-based keychains are among the quicker to force. But, given the right tool and sufficient time, all vaults/keychains can be broken into.

To protect your keychain:

Never give your password to anything that might not be completely legitimate. Know how to tell genuine password requests from forgeries.
Ensure your Mac is well-protected against malware, and never takes chances that might download it onto your Mac.
Use the macOS password manager, or a reputable third-party equivalent.
If you’re at additional risk of attack, consider using a software firewall to monitor attempts at exfiltration.
Wherever possible, use apps that save their secrets to the Data Protection keychain.
Consider removing old devices from iCloud keychain, as they could prove its most vulnerable point.

3Comments

Add yours

1

Brian on August 25, 2023 at 3:50 pm

Thank you, very helpful. You made a good point about fake dialogs maybe being granted access to upload your keychain for remote decryption. That’s a good reason to have a good Mac admin password, whatever that’s considered to be these days. Can you recommend something Mac password length and complexity?

Sometimes my Mac will wake from Sleep with no reason I can determine from looking at the log with Ulbow. And rarely when manually woken, it will ask for my login password endlessly after hitting cancel until its entered, which I’m confident was a legitimate Apple request. While I’ve seen this occasional behavior over years and clean OS installs, it’s another good reason for a good password.

Can or should “System.keychain~orig” be safely deleted that’s several years old? I assume it’s a backup from an OS update where the format changed.

There’s also lots of “login.keychain-db.sb-…………” with random characters at the end, some are a few MB, but about half are Zero bytes. I assume Zero byte files are safe to delete. Thank you.

LikeLiked by 1 person
- 2
  
  hoakley on August 25, 2023 at 4:00 pm
  
  Thank you.
  The admin login password is a difficult one. While it should never be something that can be guessed easily, neither should it be a truly robust password that you’re going to struggle to type in correctly, as often as you need. That should prevent simple dictionary attacks to guess that password. AFAIK the encryption keys used for keychains also use other secrets, so guessing the key should be impossible without a lengthy series of trials, hardly something to be attempted live on that Mac! But nothing’s going to prevent brute-forcing on another system.
  It’s easy to tell which keychains and remnants are now redundant: look at the date they were last accessed. If that’s older than your current Mac, I think you can safely delete them, or perhaps start by moving them to another folder before doing away with them altogether. But if you’ve migrated from a series of old Macs, there may be quite a few of them still hanging around.
  Howard.
  
  LikeLike
3

Larry Goff on September 8, 2023 at 9:24 pm

how do you Ensure your Mac is well-protected against malware?

LikeLiked by 1 person