Introduction

These are my thoughts on what you might commonly know as a "password manager." As a reasonably paranoid and autistic platform security engineer, personal secrets storage is very important to me. Secrets storage is a broader term that I choose to use that encompasses things like TOTP secret tokens storage, and any other critical information that you store in a note field, like detailed banking information, API tokens, etc. Along with two-factor authentication, having and using a secrets storage system is a critical part to online safety for everyone who uses the internet.

I should start out by saying that I reject using centralized, cloud-based password management service providers. This post is how to not use those things. For non-technical folks, of course, I would not recommend this article. Centralized, cloud-based password management service providers are much better than no password manager at all.

What's important to you?

Things that are important to me when choosing a secrets storage system:

1. Multi-platform. Linux, macOS, iOS, iPadOS, etc.

2. Redundancy. The secrets database needs to exist in multiple locations, and on multiple devices in case one is lost or stolen.

3. Cryptography.

3.1. Data at rest, aka the local storage of the secrets database needs to use state-of-the-art encryption and hashing. Redundancy is critical here too, because the systems that store my encrypted database also needs strong full-volume encryption that is protected with its own secure enclave.

3.2. Data in motion, aka the moving around of parts of the secrets storage system need to be redundantly and strongly encrypted. Ideally, trustworthy end-to-end encryption (E2EE). Parts include the raw encrypted database blob, metadata about this secrets system, and keyfiles, if used.

3.3. Authentication, meaning how we authenticate with a secrets database. Typically with password managers there is a "master password". But there are other points to consider, like how we log into our computers and mobile devices that store these secrets. Maintream password managers allow people to authenticate from anywhere in the world to their closed-source API. Threat actors with local access to your computers and mobile devices is a serious threat, depending on how well-funded, educated, and determined any threat actor is about your chosen technology. Not all threats are the NSA -- most threat actors are the people that know us best, like our friends, family, or employers.

4. Single point of failure minimization.

4.1. Offline password management -- No risk of Lasspass-like breaches where they fail at securing master passwords, or fail at enforcing the use of strong master passwords that are later copied of their insecure cloud services. The ineptitude in corporate leadership is crazy.

4.2. Offline TOTP - No risk of Google-like breaches where they arbitarily decide to sync your TOTP names and secret tokens to their NSA/FVEY-owned cloud.

4.3. No browser integration - Nice to haves are not nice to have if your browser gets popped. There's a multi-billion dollar industry around web browser explooits, there's a multi-trillion dollar industry around ad farms that will happily push malware to your browser without your permission, and ad blockers are not based on safelists. It's just a matter of time without targeting.

Prefered Technology

My preferences might not be your preferences. Again, these are my opinions based on personal threat modeling. If you'd like to hire me to help you with your threat model, get in touch!

Multi-platform

1. Strongbox for iOS and iPadOS
2. KeepassXC for macOS

A KeepassXC-created database is perfectly compatible with Strongbox when syncing. In other words, KeepassXC databases can be opened with Strongbox, and vice-versa. Changes made on one device can be made to sync and keep other devices up to date. However, my preferences are to only make updates with KeepassXC from my laptop devices.

Redundancy

I'm an Apple ecosystem user. I appreciate Apple's Advanced Data Protection and Security Keys features for iCloud. Using multiple Apple devices along with a highly secured iCloud account allows me to sync arbirarty data with strong security properties, including already-encrypted KeepassXC/Strongbox databases.

I choose to use KeepassXC as my default database, meaning any changes I make to my passwords or TOTP secrets get pushed from those laptop/desktop devices. iCloud keeps the encrypted database synced, so when Strongbox is used on my mobile devices, it likely has an updated copy of the database to open. If for some reason it hasn't synced yet, I can manually pull down a revised copy that has always been present in iCloud.

If I lose a laptop or a mobile device, my secrets database is not lost. The more devices that I have logged into iCloud, the more copies I have of my secrets database. It's imperative, in my opinion, that if you travel with a Macbook and iPhone, that you always leave behind one device that has a copy of this database.

Encrypted USB devices should be used for secured backups and off-site archives.

Cryptography

As of November 2023... here's my crypto-agility cryptographic inventory. I'm going to keep this brief, meaning i'm not going to go into detail why some of these things are better or worse than alternative choices.

iPhone with iOS 17.x, iPad with iPadOS 17.x

Data at rest - device encryption

Begining with Apple's hardware (Ring -3) Secure Enclave, which is a hardware-based key manager that’s isolated from the main processor, a device's secure boot chain cryptographically validates the integrity of partition encryption, file system encryption, kernel integrity, and up to application layer integrity.

iPhones and iPads are one of the most secure devices in the world. Having physical access to a fully patched iPhone/iPad is not enough to break into one -- exploit chains to break into such devices can cost millions dollars. However, and obviously, for well-funded and highly-determined threat actors, millions of dollars is a trivial amount of money, if and when such exploit chains exist.

There are too many aspects of Secure Enclave to get into in this article. Please read it directly from Apple. In short, if a device does not have a hardward-driven Secure Enclave, it's a bad decision to trust that your secrets are adequately protected against modern threats.

Data at rest - application database encryption

I'm only going to define this once even though its applicable accross all devices that hold the encrypted database. KeepassXC/Strongbox can be configured to use Argon2id as its Key Derivation Function, and ChaCha20 256-bit as its encryption algorithm. Transform Rounds and Memory Usage should be increased as well, the above link to the OWASP Cheatsheet defines clear baselines. Whatever is set with KeepassXC/Strongbox is what is used by the other devices, as these cryptography settings are synced along with any content changes. These kinds of settings are above and beyond what an end-user can control, or even an enterprise can control, when using cloud services from bad companies like Lastpass.

Authentication - device access

Authenticating into an iPhone or iPad is built on top of the security processes and cryptographic properties of Apple's Secure Enclave.

iPhone/iPad PIN/passphrase:

The user's PIN or passphrase is not stored directly on the device. Instead, it's used to derive cryptographic keys. When a user sets a PIN/passphrase, the device combines it with a device-specific unique ID (UID, from Secure Enclave) key to create an encryption key. This key is used to encrypt the data on the device. The UID key is embedded in the hardware and is not accessible to the operating system or apps. Like is common with PINs and passphreases, the length and/or complexity of the PIN/passphrase is very important. Apple's default of 6 numbers is not enough, dpending on your threat model. It's generally understood that 11 or more numbers/characters is a highly secure PIN/passphrase for an iPhone/iPad, resistant to many types of brute-forcing attacks. Again, it's important to understand the details of the implementation and related security features. Apple has made it so repeated failed attempts quickly forces an attacker to wait longer for the next PIN/passphrase attempt to be made. But, historically, that system too has been defeated by certain exploits, and later patched.

iPhone/iPad Face ID:

During Face ID setup, the facial recognition data is captured and converted into a mathematical representation. This is accomplished by the camera system projectng thousands of infrared/invisible dots onto the owner's face to create a detailed depth map of the face. This data is encrypted and stored in the device's Secure Enclave. When authenticating, the new depth map data is sent to the Secure Enclave, comparing this new scan with the stored data. If the match is confirmed, it releases a cryptographic key to unlock the device, or perform other secure operations. Face ID also includes attention-aware features, ensuring that the device unlocks only when the user looks directly at it with open eyes. Using Apple's machine learning, which is performed by another dedicated procesor, Face ID continuously learns and adapts to changes in the user's appearance using machine learning algorithms within the Secure Enclave Processor.

It's critical to understand the details of how device authentication systems work in order to broadly understand threats, vulenrabilities, and risk associated with the manaagement of personal secrets. For example, if someone is going to go to a political protest where there is likely to be police activity, one might consider disabling FaceID, or not bringing important devices at all.

Authentication - application

On an iPhone/iPad, Strongbox can be configured to use Apple's PIN/passphrease/FaceID systems. Strongbox can also support FIDO2 hardware authenticators, key files, and other factors, and also can combine factors for two-factor authentication. Of course, the implementation details of these authentication factors is critical, so be sure to understand the base hardware, firmware, OS security features of your devices.

Strongbox can also be configured to automatically close itself, or, stop access to the encrypted database, based on a timer. This forces a user to re-authenticate with the applicaton for secrets access. This is automatic if the device is restarted, and this is in addition to re-authentication to the device itself, if device access has also timed out.

Macbook Pro M1 with macOS 14.x

Data at rest - device encryption

Apple employs AES-XTS for volume encryption, protected by Mac's Secure Encalve. Again, the more complex, but more importantly the longer a PIN/passphrase is, the better.

Authentication - device access

Right now, at time of writing having been researching and writing for several hours, I am too lazy to go into this, and recommend you read Apple's latest (but now old) Platform Security document.

Authentication - application access

WIP

Notes

Specific unpatchable hardware vulnerabilies must be considered.

Apple iCloud services

Data in motion - device VPN

My devices use Wiregaurd, congigured with a preshared key. In this context, this affects sync traffic to Apple servers and redundantly protects TLS encrypted data that Apple services negotiate (see below). There may be times that I temporarily disable my client VPN, and in which case, only Apple's TLS and the KeepassXC/Strongbox cryptography is protecting the secrets database.

Stacking a diversity of transport encryption might help from the perspective of threat actors copying encrypted data off the wire. But it also requires a user to work through the challenges that arise when stacking transport technologies, like when (not if) there are lower-level connectivity issues that impact my Wireguard services or Apple services.

An important factor here is that Wireguard is not terminating to Apple. Wireguard is terminating in a datacenter that might not have direct peering to Apple, meaning, there is clear access to Apple-encrypted TLS traffic at some point, making it vulnerable to off-the-wire copying or maybe even downgrade attacks.

Data in motion - client/server negotiation

Apple, sadly, for asymetric PKI, uses EC 256 or RSA 2048 (they support both). for symmetric crypgraphy, Apple prioritizes TLS 1.3 (AEAD) cipher suites. Probably TLS_AES_128_GCM_SHA256 (0x1301), ECDH x25519 (eq. 3072 bits RSA), FS is negotiated by my devices and their servers. They do choose to use weak fallback suites, some of which do not use Forward Secrecy, which is incredibly shameful.

Authentication - cloud services

As previosuly mentioned, my iCloud account is protected with Apple's Advanced Data Protection and Security Keys, which leverages my device's secure enclave in tandem with a FIDO2/WebAuthn hardware Yubikey.

Access to iCloud data is not possible with ADP turned on without your device. No other Apple device in the world can access your E2EE iCloud data when ADP is enabled, short of Apple API security, backend security, or cryptography failures.

Single point of failure minimization

4.1. Offline password management

WIP

4.2. Offline TOTP

WIP

4.3. No browser integration

WIP

Things that I worry about

Someone stealing all of my devices

If someone robs me of all of my belongings, I would be in serious trouble.

Border security forcing me to open my devices

I'm comfortable with completely giving up a device or two if a cop steals my things. I'm wealthy enough to deal with that situation, and i'm very priviledged becuase of it. However, when cops steal our things, we will never know what happens to them. It's possible they will hold onto them for a few months or years, waiting for when there is a new exploit to get around Apple's otherwise strong defenses. They can get access to the encrypted database if they really want to, if I'm a valuable enough of a target. If they hold onto the device for long enough, with quantum computers, they could even feasibly break into the encrypted database, too.

A lack of post-quantum cryptography

Syncing encrypted databases accross the internet to Apple servers in both the United States and Europe means this TLS encrypted content is copied off the wire by various intelligence agencies. TLS, as of November 2023, does not offer quantum resistance. It's just a matter of time that this content could be decrypted, making layered encryption paramount due to this known and expected risk.

Concerning Apple's Secure Enclave, I do not know how quantum computers might endanger the condifentiality of data on an iPhone, iPad, or Macbook. It's clear that their Secure Enclave performs standard PKI functions with asymetric EC and RSA keys.

Someone else's computer

Syncing data accross someone else's computer, where this data is stored for years and is in Apple backups for many more years, even using E2EE (due to post quantum risks), is not ideal. What i'd really like is for KeepassXC and Strongbox to support serverless Tor onion services syncing. Tor really needs to deploy quantum resistance as well.