# How many bits of entropy should a password have to be reasonably future proof (10+ years)?

I’ve seen estimations that the NSA is capable of at least 1 trillion (PGP pass phrase) guesses per second, which would mean a password with 80 bits of entropy would take, on average, over 15,000 years to guess. However, this estimation was from 2015 and almost definitely outdated. How many bits of entropy is secure today, in late 2021? How many bits would be future proof for the next ten or so years?

• See it this way: One more bit and it'll take twice as long. So generally, if you use diceware or any other long passphrase, that isn't like a part of pop culture, you should be fine. Nov 28, 2021 at 10:30
• Use a password manager, let it choose the password for you, and have a really long password (mine are 64 bytes or more). Nov 29, 2021 at 0:50
• Good systems allow you three tries before they lock you out for 15 minutes. That makes it nigh impossible, even with 1 trillion guesses per second. Dec 1, 2021 at 2:37

We currently believe that 128 bits of security should be sufficient for current and future needs. Much of this is due to physical constraints: using the theoretical minimum energy to store 2^128 bits of data would require more energy than is required to boil the world's oceans.

If you're using a password manager, that means that a 20 character truly random password using the 94 non-whitespace ASCII characters, and 22 characters if you're using the Base64 characters. If you're not using a password manager, you probably should be.

If you want to protect against even the most unlikely scenarios, then you can use a password with 256 bits of entropy. I do this on sites where I can, and since I use a password manager, there's no need for me to remember it.

Note, however, that in many cases, there are likely easier attacks than brute force. For example, it may be easier to compromise the site or service in question than conduct a brute force attack on the password. That being said, it's easy to use strong passwords in most cases, so there's little reason not to.

One trillion passwords per second sounds like a good rule of thumb and jibes with the number I found when researching my table of pw cracking times in 2015 (I found an estimated 23 billion per second per node, which is plausible since the NSA could easily have a few dozen nodes).

When calculating this sort of thing, I prefer to assume Moore's Law applies directly to crack efficiency (it doubles every 18mo). There have been 2344 days since the 2015-07-01 (the mid-point of 2015), which accounts for 4.3 periods of 18mo since mid-2015, so 1T pw/s in 2015 becomes 24.3 = 19.4T pw/s. Since pessimism fits here, Let's round that to 20T pw/s (in scientific notation, 2e13).

When calculating crack time for entropy, assume an attacker will get the password in half of the number of tries needed, so an entropy of 80, which refers to 280 passwords, can be cracked in 280pw / 2e13pw/s / 2 / 86400s/d / 365.25d/y = 957.7 years with November 2021 upgrades to the same cluster size.

I've lost the math I used to determine how to account for upgrades every 18mo, but it's easier just to fast-forward ten years: 2e13 × 210/1.5 = 2e15, an increase of two orders of magnitude. 280 / 2e15 / 2 / 86400 / 365.25 = 9.58 years, with an expected crack around 2041.

However, an entropy of 80 is very unwieldy when it comes to human memory. Diceware (7776 entries) would require six words (for entropy 77, add a random alphanumeric to make that 83). Using a standard spelling dictionary (100k entries), you'd need five words (for entropy 83). Using random printable ASCII characters, you'd need twelve (for entropy 78, thirteen yields 85).

At that point, is memorizing six random words or thirteen random characters really feasible for every account you use?

Use authenticators on accounts that allow it. For most systems, that's multi-factor or 2FA. Sometimes, there's a passwordless login that uses a 2FA technology on its own. For most services, cryptographic authentication apps provide sufficient security and we'll see a lot of transition away from passwords in the very near future. Higher-security concerns (like your email, bank, and password manager) will still need secure authentication systems and a password.

Use a password manager with a passcode generator that uses 16+ random characters including a minimum of 1 lower, 1 upper, and 1 special, yielding an entropy of log₂(94¹³×26×26×32) = 99. To get to bk2204's suggested 128 bit entropy, you'd need 21 total characters.

For items you can't put into the password manager (like the password manager's entry code itself), I recommend a 8-ish character passcode put in a random place within a passphrase of 5 dictionary words or 6 Diceware words. Use a generator, humans are very bad at understanding that random ≠ arbitrary ≠ obscure. For example, I just popped open Bitwarden (Diceware) and generated `reversion junkie unknotted opposite litter stamina` as a passphrase and `7!&CPc9T` as a passcode (requiring one upper, one lower, and one special), then I got `3` as a random number from 0-6 (`echo \$((\$RANDOM%7))` in bash), so I can combine those to add the code after the 3rd word: `reversion junkie unknotted 7!&CPc9T opposite litter stamina`. Make a story to remember the words and write the code down on a piece of paper that lives in your wallet.

This has an entropy of log₂(7776⁶×94⁵×26×26×32) = 125.

(Update: Bitwarden uses Diceware, which is unnecessarily limiting. I've added a word to get a more robust entropy value until Bitwarden supports larger dictionaries.)

Don't fully trust your cloud-connected password manager for your most trusted items (PGP key, bank, email, etc)? Generate random 16-char codes and save them as the password, then generate another 5-char code that you write down in your wallet with cryptic clues about what it is. Append that to your password after filling in the login form with your pw manager.

Just be careful not to lock yourself out with a scheme you don't recall, especially with sites like banks that lock you out after a small number of login attempts.

• Wouldr't the entropy of a 16 character password with 1 lower, 1 upper and 1 special be log2(94^16) ~= 104? Not counting the full character set for three characters assumes that the attacker knows in which position these characters are, if they don't know this (which I think it's safe to assume) they'll have to try the full alphabet in all positions. Also, Bitwarden uses the diceware dictionary so it's only 7776 words and not the full 100K of a regular dictionary. May 11 at 12:23
• Location isn't considered in my calculation because it doesn't need to be. 94¹⁶ includes codes like `123456789abcdef0` and `!@#\$%^&*(ABCDEF)` which are not possible given the requirements. It appears you're right about Bitwarden using Diceware. That's unfortunate—there's no reason for such a limitation. I'll adjust my answer in that regard. May 11 at 14:59
• But taking 94¹⁶ and removing all passwords that doesn't include a character from all 4 sets should be 94¹⁶ - 84¹⁶ - 62¹⁶ - 2 * 68¹⁶ right? Which is still 104 bits of entropy May 12 at 13:30
• Calculating it that way would work, but you're missing a lot of permutations; it's a BIG equation: total − invalid = target, so total = 94¹⁶ and invalid = 94¹⁵×26 + 94¹⁵×26 + 94¹⁵×32 + 94¹⁴×26×26 + 94¹⁴×26×32 + 94¹³×26³ + …. I've given you the math for the target, so we can calculate invalid = total − target = 94¹⁶ − 94¹³×26×26×32. This "invalid" space is actually huge; log₂(invalid) = log₂(94¹⁶ − 94¹³×26×26×32) = 104.835. Compare to log₂(total)'s 104.873 and log₂(target)'s 99.611. (If these numbers are confusing, remember that they're exponents). May 12 at 15:15