Hardening macOS 4: Secrets Management & Hardware Security Keys
Long week.
I worked on Aradia, mainly. It’s something I’ wi’ll discuss with you shortly - but for the time being: remember I was complaining about a noticeable scraping attack? Well, Aradia is the answer.
_Another news that can be of interest for you: all the content of these lessons, enriched with theory, exercises, and tips will be part of the “Digital Self-Defence Manual” - an ebook I’m publishing, that should see the light in Q2 2026. Hopefully.
‘til then, only these posts, sorry about that!
Previous posts on this series
- macOS Hardening: a new series
- First hardening of the network layer
- Hardening macOS pt.3: Browsers compartmentalisation
Introduction
In this post we’ll talk about one of the most important aspects of security: managing access to systems and services.
In general, when you access a system, you need to provide your credentials. These are evaluated and then access is granted. Once access is granted, you can perform some activities, according to your authorisation level.
So: Authentication, and Authorisation. Whilst Authorisation is totally outside of your sphere of influence, Authentication is. You have passwords, and increasingly other pieces of information required to access the system (tokens and other forms of MFA).
Therefore, Authentication is mostly based on something you know (passwords), and quite often on something you have (tokens, certificates), and sometimes, on something you are (biometric information such as your face or your fingerprints). Some advanced mechanisms also work on something you do, but they are not so widespread enough to be relevant here.
Our objective now is protecting our secrets (passwords, API Secrets, certificates, other debris) from a plethora of enemies:
- ourselves. We are our own worst enemy when we reuse passwords and certificates. Revoking, changing, and rotating secrets is basic hygiene. You wouldn’t take a shower and put on your dirty undies, would you?
- cybercriminals. I know, I never mention them as enemies, but they’re there. They act in weird ways, targeting different attack surfaces, such as:
- yourself - indeed, dude: this happens more often than you’d think. Not always via computer (I bet you’ve received tons of calls in which someone asks you for personal data)
- your browser - as solid as your browser may be, it’s still a browser. It is not a password manager. Distrust browsers pretending to be password managers - if for no other reason, because you don’t always use your browser (think about a terminal connection, for instance).
- your trust - although not really secrets-focused, keep in mind that you should give your passwords to no living being. Not even that hot chick you met on a random social (yes, sometimes they ask you for passwords)
- system corruption - very unlikely, but it happens. Countless times a cute OS with a cuter penguin scrambled its
/etc/passwd. Especially in its cute, early years…
So, let’s get the elephant out of the room first: calls and scams. I never planned to cover this, but I’ve been receiving too many calls from too many people with strange accents and broken English that I think giving you some hints can’t hurt. Then we move on to the good stuff.
Scams
What do the following plots have in common? Note - I’m not transliterating the accents.
Phone call 1: “Good morning, Sir. This is Mr. <unspeakable name that spoken backwards would summon Pazuzu> from the Court of London. We have a file on you. You owe <a consistent amount of money> and if you don’t pay, this will impact:
- your credit score
- your criminal records
- your hairline - you’ll become immediately bald
- other things Now you give us your personal data, but you need to wire 5k to us. “
Phone call 2: “Good morning, Sir. Here is mr. <another unspeakable name, but this time, if you speak it backwards, you’d summon Cthulhu> from <your mobile carrier>. We have a new contract proposal for you, if you accept the proposal you’ll receive
- 123 days a month of free phone traffic
- 190 hexabytes of free traffic. Per hour
- every week, the winning EuroMillions numbers
- Charlize Theron (yes, I am that old)
- Santa’s sleigh The only thing you need to give us is your name, your phone number, and the pin of your contract… “
So, what is the punchline? Several aspects:
- these guys don’t know anything about you. Otherwise, they would not ask for your personal data.
- something “too bad” about to happen to you? Well, you’d suspect — at least — that something was coming. Nothing that big comes out of the blue, does it?
- something “too good to be true”? Well — you’ve only had one stroke of great luck in this life: stumbling on my blog. Seriously: if your carrier wanted to get in touch with you, they would use other channels, not a phone call.
- Nobody asks you for a pin or a password on the phone. If they do, and you tell them to go do pushups on the motorway, nobody could blame you. You can always say that it sounded like a scam.
The answer? My polite answer is “Ok, nice. What’s my name?”. Then, you have the funniest answers like “how dare you, not cooperating with the Court?”. Ibid - if it were really the Court, even a newly graduated solicitor could defend your position. But the Court does not contact you like that, sure as taxes and death.
Uh, by the way: these dialogues are exaggerated. Real scams are more subtle — which is precisely why they work. But the patterns are real.
Now, let’s come back to business.
Most Apple users don’t really think much about secrets management. It’s kind of normal - “do you want to save the password not in Safari but somewhere else on your system? Plus, it is safe! AES256!” sounds very reasonable. And if we look at this from a sceptical perspective, it’s not entirely false.
The Passwords Utility and the Apple Keychain are two great pieces of software. Very secure, indeed, but with some limitations.
Many colleagues complain about the portability factor, their arguments being:
- the Combo Passwords Utility/Apple Keychain works solely on Apple. Linux, other BSDs, Windows - no access at all. Tough luck
- It’s closed source. You have to trust Apple. Full stop. Nobody can audit it.
- Everything passes through Apple’s servers. And although communication is E2EE, you have no control over the infrastructure.
- Apple can change their policies when they want and you have no control over that.
I find these arguments quite naive, actually. Perhaps because I don’t spearhead any crusade, but to me the real issues are different. They’re not wrong — but these are ideological concerns. The practical ones bite harder.
- You wanna talk about Vendor lock-in-ness? Here we go:
- if you lose access to your Apple ID, you’re on your own, buddy. No access to your passwords. Including the password of your Apple ID. Yes, really.
- Technical limits:
- try to export your passwords. You get an unencrypted CSV file. My corneas are still bleeding.
- no terminal access. This is painful, especially if you’re like me (I currently have 42 open terminals, not counting the pseudo-terminals from VS Code, Zed, and RustRover)
- No SSH key management. At least, not integrated.
- No custom fields for API keys/secrets, tokens, recovery codes, notes… anything that you would really need.
- limited secrets sharing. Only with Apple users, at that.
Warning - If you ever use Apple’s CSV export, delete that file with srm or immediate disk wiping. Leaving an unencrypted list of all your passwords in your Downloads folder is the digital equivalent of leaving your house keys taped to the front door.
However, “the Combo” has several good aspects:
- AES 256 encryption. An industry standard.
- Biometric unlock. It seamlessly integrates Face ID/Touch ID. From a UX perspective, this is perfect.
- Smart Autofill. Phishing-resistant — it fills in credentials if and only if the domain matches. Kudos!
- Sandboxed in the OS. Not a third-party app, with its own attack surface.
- It is already there, in every fresh macOS installation. You don’t need to install anything.
- You’re nudged into using it. You use a password, you are asked to save it.
- Decent password generator.
- Automatic sync among iCloud devices.
- Native passkeys support.
There’s one aspect that goes unnoticed, and to me it’s the real differentiator: at the end of the day, the best password manager is the one that people actually use. So if your grandma was used to writing her password in her scratchpad-for-everything and starts using “the Combo”, bring her some flowers. She deserves them. If only for her unbeatable Apple cake!
In my opinion, the only viable alternative is the kdbx format.
The kdbx format
This time I’m referring to a format rather than a program, for a reason: there are multiple programs that interoperate with it, so everybody can choose according to their preferences.
If I am not mistaken, the support matrix is as follows:
| Program | Platform | Notes |
|---|---|---|
| KeePass | Windows (Linux/macOS via Mono) | The original. Interface from another era, but rock solid. |
| KeePassXC | macOS, Linux, Windows | The community fork. Modern, actively maintained, browser extension. The desktop reference. |
| KeeWeb | macOS, Linux, Windows, Web | Electron-based, clean interface. Also runs as a web app. |
| Strongbox | macOS, iOS, iPadOS | Native Apple client. YubiKey support, free tier + Pro. |
| KeePassium | iOS, iPadOS | Open source, independently audited. YubiKey NFC/Lightning. Free tier + premium. |
| KeePassDX | Android | Modern, actively maintained. The Android reference. |
| Keepass2Android | Android | YubiKey challenge-response support. Solid alternative. |
| AuthPass | Android, macOS, Linux, Windows | Cross-platform, friendly interface. Less known, but capable. |
| kpcli | Linux, macOS | Command line interactive shell. For terminal lovers. |
| passhole | Linux, macOS | CLI inspired by pass. Python-based. |
| KeePassXC-Browser | Firefox, Chrome | Browser extension, connects to KeePassXC. Autofill done right. |
Pro’s and con’s, indeed. Choose your bane. In this post I will talk about Strongbox because it is my choice, but it’s a matter of personal preference.
Download and install the client of your choice, and run it. The first thing you need to do is create the database for your keys. There are multiple options here, depending on the client itself, but at the end of the day there’s a choice to make: online vs. offline databases.
This choice obviously depends on your needs and use cases, so I’ll just give you some criteria. Remember, security is useless when it hinders usability, so make a choice and secure it.
| Online (cloud-synced) | Offline (local file) | |
|---|---|---|
| Availability | Access from any device, anywhere | Only where the file physically is |
| Sync | Automatic across devices | Manual (USB, SCP, rsync, your problem) |
| Backup | Cloud provider handles redundancy | You handle it. No excuses. |
| Attack surface | Cloud provider is a target. Breach = your vault exposed (encrypted, but still) | No remote attack surface. They need physical access. |
| Trust | You trust the cloud provider with your encrypted blob | You trust yourself. And your backup discipline. |
| Single point of failure | Provider goes down / bans your account = locked out | Disk dies without backup = game over |
| Forensics | Metadata: when you access, from where, how often | No metadata leakage |
| Convenience | High | Low to medium |
| Control | Partial | Total |
At a glance: Offline means more secure, Online means more usable.
Let’s imagine a use case where the user wants to mimic Apple’s Combo, so we opt for the online solution.
To set up the client as we planned, first we create a database. In my case, Strongbox offers a few good options:


Strangely enough, Strongbox doesn’t explicitly list iCloud Drive as a storage option in the creation dialog — but if you choose ‘File’ and save it in your iCloud Drive folder, it works and syncs across devices. If you don’t like this, you have plenty of options, as Strongbox supports its own Sync technology, local files, OneDrive, Dropbox, Google Drive, SFTP, WebDAV.
We want to make our life easy and sync with other Apple devices, therefore we opt for the native solution. Note that this option may not work with third-party devices, such as Android phones or Linux boxes. Choose wisely.
The creation of a database gives us:
desdinova@HardenedPanettone ~ % ls -al /Users/desdinova/Library/Mobile\ Documents/com~apple~CloudDocs| grep kdbx
-rw-r--r--@ 1 desdinova staff 1093 16 Feb 11:54 A new database.kdbx
Neat. The file actually saves to iCloud.
The rest is really client-dependent, and some aspects may vary. Creating an entry is trivial, but Strongbox offers some interesting options:


Notice the passphrase generator: 134 bits, over 100 million years to crack. This screenshot is worth more than an entire post on password theory.
I want to show you some Strongbox settings. I open Database settings (⇧⌘,) to get

Now, this comes in handy: the extensions for your browsers:
- Firefox, LibreWolf, Mullvad: https://addons.mozilla.org/en-GB/firefox/addon/strongbox-autofill/
- Chrome, Brave, Chromium-based browsers: https://chromewebstore.google.com/detail/strongbox-autofill/mnilpkfepdibngheginihjpknnopchbn
- Safari: see below
The remaining part of the settings is either client-specific or crypto-related. The good thing is that our password manager is now partially integrated with our browsers. To finalise the integration, we must enable it system-wide.
To do so - System settings, General, AutoFill & Passwords: enable the Secret Managers you want.

Multi-Factor Authentication
Your password manager is set up. Your passwords are strong, unique, and stored in an encrypted database. Good. Now let’s talk about what happens when your password gets stolen anyway.
Because it will. Breaches happen. Phishing happens. Keyloggers happen. The question is not if someone gets your password, but what they can do with it.
The answer should be: nothing. That’s where Multi-Factor Authentication (MFA) comes in. You already know the concept — something you know (password) plus something you have (a token). Enable it everywhere. No exceptions.
Now, not all MFA is created equal:
- SMS codes: better than nothing, but barely. SIM swapping is trivial for a motivated attacker. If this is your only option, use it — but don’t sleep well at night.
- Authenticator apps (Google Authenticator, Authy, etc.): better. The code is generated on your device, not sent over the network. But if your phone is compromised, so are your codes.
- Hardware security keys: the gold standard. A physical device that must be present to authenticate. No phishing, no remote compromise, no SIM swap. You either have the key, or you don’t get in.
The two main players in the hardware key space are YubiKey and Google Titan:
| YubiKey 5 Series | Google Titan | |
|---|---|---|
| Protocols | FIDO2, U2F, PIV, OpenPGP, TOTP, Smart Card | FIDO2, U2F |
| Connectors | USB-A, USB-C, Lightning, NFC | USB-A/NFC, USB-C/NFC |
| Passkeys storage | ~100 | ~250 |
| Price | £50–70 | £25–30 |
| Versatility | SSH agent, PGP signing, smart card, TOTP — the Swiss army knife | Web authentication only |
If all you need is solid 2FA for your online accounts, Titan does the job at half the price. If you want a single device that handles SSH keys, PGP signing, smart card authentication, and TOTP on top of FIDO2 — YubiKey is the answer.
I use YubiKeys. Two of them — because hardware dies, gets lost, and goes through the washing machine. Always register two keys on every service that supports it. Keep one on your keychain, one in a safe place. If you lose both, recovery codes are your last resort — and yes, those should be in your password manager too.
One final note: whatever you choose, register your hardware keys on all critical services first. Email, cloud storage, password manager, banking, code repositories. These are the dominoes — if one falls, the rest follow. Start from the top.
One last thing: back it up.
Your secrets are now in one file. One encrypted, portable, beautiful file. Which means: lose that file, lose everything.
If you chose the online route, your cloud provider handles redundancy — but don’t rely on that alone. Download a local copy. Put it on an encrypted USB drive. Store it somewhere safe, somewhere physical, somewhere that is not your laptop bag.
If you chose the offline route, this is entirely on you. No backup, no sympathy.
In both cases: test your backup. Open it, unlock it, verify it works. A backup you’ve never tested is not a backup — it’s a hope.
Conclusion (with Will-o’-the-Wisp)
We covered a lot of ground today. We got the scam elephant out of the room, discussed why Apple’s Keychain is good but not enough, explored the kdbx ecosystem, set up a proper password manager, and put a hardware lock on our digital lives.
None of this is paranoia. This is basic hygiene — the digital equivalent of locking your front door and not leaving the key under the mat.
But if you’ve been paying attention, you’ve probably noticed some gaps. Things I haven’t mentioned. Tools I haven’t recommended. Practices I’ve deliberately avoided.
That’s not an oversight. In the next and final post, we’ll talk about what I consciously left out — and why. Because in security, what you choose not to do matters just as much as what you do.
Stay paranoid, but have fun.