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. 🙌

Common misconceptions

1. Using 5-word passphrase is less secure than 8-character password.

When truly random, a 5-word passphrase generated using EFF’s Short Wordlist #1 has more entropy than 8-character password, therefore is more secure.

2. Using 8-character password is never secure enough.

It really depends on which key derivation function and secure element is used, if any, to harden password.

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 older Macs that do not have T2 chip, brute-forcing password using hashcat on AWS’ most powerful instance type (currently p4d.24xlarge) costs over $3M USD (at discounted spot pricing).

On recent T2-equipped Macs with FileVault enabled, brute-forcing password is theoretically impossible.

This is likely secure enough for most threat models.

3. One should never use same password to unlock computer and password manager.

It really depends on operating system and password manager.

1Password, for example, encrypts user data using both Secret Key and Master Password while never sending either over the Internet thanks to a Secure Remote Password (SRP) implementation.

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.

4. One should rotate passwords as often as possible.

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

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.

log₂(number of combinations)

For two six-sided dices, entropy equals log₂(36) or ~5.17 bits.

The command line utility bc is very useful when calculating entropy.

$ echo 'l(6^2)/l(2)' | bc -l
5.16992500144231236295

Passwords should be truly random and should contain enough entropy to mitigate bruce-force attacks to the extent of one’s threat model.

Statistically, an attacker needs to try 2^entropy-1 combinations to deterministically brute-force password.

For two six-sided dices, number of combinations to try equals 2^5.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)?

$ echo 'l(75^8)/l(2)' | bc -l
49.83054952396704701806

Entropy equals ~49.83 bits resulting in having to try 2^49.83-1 or 500,373,945,961,594 combinations to brute-force password.

Hardware random number generator (HRNG)

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).

On FreeBSD-based operating systems (including macOS), Fortuna CSPRNG is implemented by kernel and truly random data can be generated using /dev/random.

For example, one can generate truly random 8-character password by running following command.

$ cat /dev/random | LC_ALL=C tr -cd 'a-zA-Z0-9_-;:!?.@\\*/#%$' | head -c 8
*hXg#B!X

Key derivation function (KDF)

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 openssl command.

$ openssl rand -hex 32
ce7df8f96e691ec46e7cd2c7e1bad90f4432a6d6fb6e7a8ce880a841bed4d394

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?.

$ echo "coral barn wing armor acid" | openssl dgst -sha256
e5b3ad893826d624f821b4a1a6fea1fbe3bf8ab5649a69ba880cf7b99a1bd42c

$ echo "coral barn wing armor acid" | argon2 $(openssl rand -base64 32)
Type:		Argon2i
Iterations:	3
Memory:		4096 KiB
Parallelism:	1
Hash:		d45ae284815c65e8101fd64c14b07b241d589ace493aad45845c8ebed3d53b28
Encoded:	$argon2i$v=19$m=4096,t=3,p=1$ZXE3dElZazR6SFJHUWxkR09ra0pucHVqVFdtOTYzR1NMTUFqNGVyYmlMQT0$1FrihIFcZegQH9ZMFLB7JB1Yms5JOq1FhFyOvtPVOyg
0.009 seconds
Verification ok

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.

$ time (for i in {1..1000}; do echo "coral barn wing armor acid" | openssl dgst -sha256 > /dev/null; done)
( for i in {1..1000}; do; echo "coral barn wing armor acid" | openssl dgst  >)  1.52s user 1.96s system 99% cpu 3.485 total

$ salt=$(openssl rand -base64 32); time (for i in {1..1000}; do echo "coral barn wing armor acid" | argon2 $salt > /dev/null; done)
( for i in {1..1000}; do; echo "coral barn wing armor acid" | argon2 $salt > )  15.76s user 3.16s system 94% cpu 20.090 total

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).

$ echo "coral barn wing armor acid" | argon2 $(openssl rand -base64 32) -t 100
Type:		Argon2i
Iterations:	100
Memory:		4096 KiB
Parallelism:	1
Hash:		3c4f8af639f388be91b6b9176d00b15e1b449b4d240ea5fbd66bc6f0c20297e3
Encoded:	$argon2i$v=19$m=4096,t=100,p=1$Y29FYUJQc2ZJeGp5S2lueWQyVndRdnhteTNzS0FITGxaZFlhVTA2M2JzOD0$PE+K9jnziL6RtrkXbQCxXhtEm00kDqX71mvG8MICl+M
0.231 seconds
Verification ok

$ echo "coral barn wing armor acid" | argon2 $(openssl rand -base64 32) -t 1000
Type:		Argon2i
Iterations:	1000
Memory:		4096 KiB
Parallelism:	1
Hash:		3946b19e54c219bc60a81325099a980b64c0a4c1628c6c6f913253ef9a5bee4b
Encoded:	$argon2i$v=19$m=4096,t=1000,p=1$V0dOWklOeGtVbG4zQ2lIcE9naXVPWDBKNmFoQ285YUhOTlN3aHpESUV1MD0$OUaxnlTCGbxgqBMlCZqYC2TApMFijGxvkTJT75pb7ks
2.271 seconds
Verification ok

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 (3c4f8af6… and 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.

Secure element

Secure elements are side-channel resistant systems on a chip (SoC) designed to compartmentalize sensitive data and computing away from the central processing unit (CPU) and, when applicable, memory.

Secure elements often self-generate cryptographic keys fused to system on a chip during manufacturing making them (theoretically) safe from supply chain 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.

Media key is stored outside secure enclave using effaceable storage so it can be quickly (and permanently) destroyed (a process called crypto-shredding).

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.

Threat model

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.

Recommendations

Here are a few high value low opportunity cost recommendations that one should always follow.

• Always generate truly random passwords (vs making them up) such as passphrase generated using dices or cryptographically-secure command line utilities such as passphraseme
• Always enable full disk encryption (and never store recovery key using online services such as iCloud)
• Always enable multi-factor authentication (when possible) and favor FIDO U2F or FIDO2 (to mitigate phishing attacks) unless physical attack (such as targeted theft) is a non-theoretical threat model (and never store TOTP hashes in password manager unless air-gapped)
• Always use password manager to generate long random passwords for online accounts (and never reuse password for more than one account)
• Always compartmentalize sensitive data and computing (for example, using security key to secure one’s PGP private keys or using hardware wallet to secure one’s crypto)
• Always lock screen when away and shutdown device when in transit (especially when going through customs)
• Never schedule password rotations (unless password has been compromised)

Hope this research is helpful to others.

Stay safe!