Securing one’s computers and accounts (or one’s organization) is a challenging balancing act between convenience and security.
Implementing too much security (such as using very long passwords) hurts productivity while too little will likely result in getting pwned.
Striking the right balance and avoiding common misconceptions requires a deep understanding of how password security works… which requires time… a rare commodity among humans.
In this story, I will guide you down the password policy rabbit hole shedding light on password entropy, hardware random number generators, key derivation functions, secure elements and why deeply understanding these topics is fundamental when adopting (or drafting) password policy suited to one’s threat model.
I would like to thank TrustToken for supporting this research. 🙌
In the context of macOS, password is secured using PBKDF2-SHA512 (generally using over 25,575 iterations) and, when FileVault is enabled on Macs equipped with Apple T2 Security Chip, media key (used to encrypt data) is wrapped (double-encrypted) using key derived from password and unique ID (UID) fused to secure element.
On recent T2-equipped Macs with FileVault enabled, brute-forcing password is theoretically impossible.
This is likely secure enough for most threat models.
It really depends on operating system and password manager.
In the context of macOS, given both operating system and 1Password share same user space, using two separate passwords yields little, if any, additional security.
Security researchers have proven scheduling password rotations is generally less secure given human nature (unless password has been compromised).
Entering the rabbit hole…
Password entropy is a measure of password strength.
Say we have two six-sided dices, how many combinations are there?
Calculating number of combinations is done using the following formula.
(number of possibilities per value)^(number of values)
For two six-sided dices, number of combinations equals 6^2 or 36.
Calculating password entropy is done using the following formula.
log2(number of combinations)
For two six-sided dices, entropy equals log2(36) or ~5.17 bits.
The command line utility bc is very useful when calculating entropy.
Statistically, an attacker needs to try 2entropy-1 combinations to deterministically brute-force password.
For two six-sided dices, number of combinations to try equals 25.17-1 or 18.
Now, what is entropy of truly random 8-character password (when using “a-z, A-Z, 0-9 and _-;:!?.@*/#%$” character set)?
Entropy equals ~49.83 bits resulting in having to try 249.83-1 or 500,373,945,961,594 combinations to brute-force password.
Humans are bad at generating truly random data using their mind.
Being aware of this, humans developed hardware random number generators designed to generate truly random data derived from physical phenomenons such as phase drift of ring oscillators.
Given hardware random number generators tend to generate truly random data slowly, generated data is typically used as seed of cryptographically-secure pseudorandom number generators (CSPRNGs).
For example, one can generate truly random 8-character password by running following command.
In order to use the Advanced Encryption Standard (better known as AES) one needs a fixed-length key of 128, 192 or 256 bits.
One can generate a 256-bit key (encoded as hexadecimal string) using
Remembering above key would be hard right? Thankfully, keys can also be derived from passwords using cryptographic hash functions such as SHA-256 (generally not recommended) or key derivation functions such as PBKDF2 (used by 1Password and macOS) or Argon2 (used by KeePassXC).
Using cryptographic hash function is only recommended when key is wrapped in additional layer(s) of encryption. Ever wondered why one can change encryption password instantly or how more than one user (or recovery key) can unlock FileVault or LUKS volumes?.
Using Argon2 (with default settings), hash (which is also 256-bit key) is derived from password in 0.009 seconds.
Let’s run above commands 1000 times each and see how long it takes.
Using Argon2 (with default settings) vs SHA-256 takes 15.76s vs 1.52s.
Most, if not all, key derivation functions have a feature called iterations designed to adjust desired hashrate (configured using
-t in the context of Argon2).
Notice how increasing iterations tenfold (from 100 to 1000) resulted in key derivation taking 10 times longer (2.271 seconds vs 0.231 seconds)?
The slower the hashrate, the longer a password takes to brute force.
By the way, you may be wondering why derived hashes (
3946b19e…) are not identical.
Key derivation functions also have a feature called salt which, when generated randomly (using
openssl rand -base64 32 in above examples), mitigates rainbow table attacks. A rainbow table is a precomputed database of hashes with corresponding passwords.
When using Argon2, one can adjust the time (
-t), memory (
-m) and parallelism (
-p) “cost” of attack to mitigate one’s threat model.
Argon2 improves upon PBKDF2 by being more configurable and resistent to time–memory trade-off (TMTO) attacks.
In the context of Apple T2 Security Chip, a unique ID (UID) is self-generated during manufacturing using built-in hardware random number generator and fused to system on a chip. UID is used to encrypt media key used to encrypt internal SSD (using built-in AES engine).
Ever wondered why enabling FileVault on T2-equipped Macs does not require encrypting data (compared to enabling FileVault on pre-T2 Macs)?
If FileVault isn’t enabled on a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted, but the volume key is protected only by the hardware UID in the Secure Enclave. If FileVault is enabled later—a process that is immediate since the data was already encrypted—an anti-replay mechanism prevents the old key (based on hardware UID only) from being used to decrypt the volume. The volume is then protected by a combination of the user password with the hardware UID as previously described.
This is how iOS, iPadOS and macOS devices are remotely wiped.
Same logic applies when “Erase Data” is enabled on iOS or iPadOS and failed passcode attempts are exhausted.
The media key is located in effaceable storage and designed to be quickly erased on demand; for example, via remote wipe using Find My Mac or when enrolled in a mobile device management (MDM) solution. Effaceable storage accesses the underlying storage technology (for example, NAND) to directly address and erase a small number of blocks at a very low level. Erasing the media key in this manner renders the volume cryptographically inaccessible.
Evaluating one’s threat model is essential to strike the right balance between convenience and security.
For example, an average person likely doesn’t need to use 7-word passphrase (~90.5 bits of entropy) to secure computer but a whistleblower likely does.
One needs to evaluate how much an adversary is willing to spend to breach one’s security while acknowledging that, in the context of passwords and physical security, 5 dollar wrench attacks or rubber-hose cryptanalysis are very effective.
Putting physical security aside, computers are inherently insecure given their design and how one uses them… increasing attack surface to unmanageable levels.
As a result, compartmentatlization is one’s first line of defence. In other words, one should use air-gapped devices (such as security keys or hardware wallets) to compartmentalize sensitive use cases.
No matter how secure one’s passwords are, if keylogger is running on computer, one has been pwned.
Here are a few high value low opportunity cost recommendations that one should always follow.
Hope this research is helpful to others.