Actions

Passwords


About this Passwords Page
Support Status stable
Difficulty easy
Maintainer HulaHoop
Support Support

Introduction[edit]


If weak passwords (passphrases) are used, they will be easily discovered by trying every possible character combination in reasonable time through brute-force attacks. This method is very fast for short and/or non-random passwords.

Generating Unbreakable Passwords[edit]

Introduction[edit]

To generate strong passwords that are both easy to remember and have an easily calculatable large entropy, it is advised to use the Diceware package. Instead of generating a random sequence containing alphanumerical and special characters, Diceware selects a sequence of words equiprobably from a list containing several thousand that have been curated for their memorability, length and profanity.

Passphrases long enough should be safe for millions or billions of years, even if the list chosen is known to the attacker. This relies on the fact that the time taken to try all possible combinations would be infeasibly large, even for a well-equipped adversary. [3] [4] This chapter discusses: how to calculate entropy for both pre-quantum and post-quantum strength, estimating the brute force time for passphrases of different length, and key-stretching measures which help to make passphrase length manageable in a post-quantum world.

Diceware Password Strength[edit]

When determining a passphrase length, ideally you want the passphrase to have at least as much entropy as the bit length of the symmetric key that is derived from it. [5] As will be explained later, one can deviate from this rule to have a shorter passphrase while still having a realistically strong protection level.

Entropy per word is calculated by dividing log of number of words in list by log 2. List lengths vary.

EFF list:

log (7776) / log (2) = 12.92 bits

SecureDrop list:

log (6800) / log (2) = 12.73 bits

Total passphrase entropy is:

number of words * entropy per word

There are 32 special characters on a standard U.S. keyboard:

log (32) / log (2) = 5 bits per character

The relationship between entropy and the length of the diceware password is outlined below.

Table: Diceware Password Strength [6]

Word Total Bits of Entropy Estimated Brute-force Time (Classical Computing) [7] Future-proof Safety [8] Post-quantum Secure [9]
Five ~64 ~165 days No No
Six ~78 ~3,505 years Maybe No
Seven ~90 ~27,256 millennia Yes No
Eight ~103 ~15 x age Universe Yes No
Nine ~116 ~119,441 x age Universe Yes No
Ten ~129 ~928,773,415 x age Universe Yes No
Fifteen ~194 ~26,405,295,715,806,668,059,525,829,264 x age Universe Yes Yes
Twenty ~259 ~750,710,162,715,852,378,145,230,792,130,183,941,981,164,925,924 x age Universe Yes Yes

Calculating Brute-force Time[edit]

Moore's Law predicts the doubling of number of on-die transistors every 24 months (two years). Other estimates by the industry put that at 18 months. It is expected that Moore's Law ends by 2025 because of physical constraints of silicon.

1 trillion guesses in 2013 = 2^40 operations.

Lower bound - Doubling every 24 months 2013-2025:

2^46

Upper bound - Every 18 months 2013-2025:

2^48

To gauging strength against adversary capabilities, an example 80-bit passphrase versus an adversary capable of 1 trillion or (2^40 guesses per second):

2^(80-40) = 2^40 seconds

Which is then divided by 31536000 seconds / year to get the number of years.[10][11]

Classical vs Quantum Computing[edit]

Classical Computing Attack[edit]

  • Diceware passphrases of 7 words recommended yielding ~90 bits of entropy against classical computing attacks. [12]
  • Passphrases of 10 words have 128 bits of entropy.

Quantum Computing Attack[edit]

  • Grover’s quantum search algorithm halves the key search space, so all entropy values in the table above are halved on quantum computers. For example the cost of searching the right passphrase of a 2^128 passphrase drops to (very) roughly ~2^64. [13]
  • A 20 word passphrase with 2^256 bit entropy today, yields 128-bit post-quantum protection.
  • Quantum computers do not impact the entropy provided by key-stretching algorithms. See below. [14]

Key-Stretching[edit]

Depending on how it is implemented, key-stretching introduces a major speed-bump for brute-forcing as it forces an adversary to undergo extra steps compared to processing vanilla symmetric master encryption keys. They allow passphrases to be shorter while adding a certain entropy security margin. Note this does not help if bad passwords are chosen.

Passphrases for LUKS FDE are secured using a key-stretching implementation known as a Password-Based Key Derivation Function (PBKDF). The older HMAC-SHA* algorithm is less effective against parallelization by GPUs and ASICs (the same weaknesses suffered by Bitcoin against dedicated mining hardware).

Argon2id is the winner of the Password Hashing Competition and the state-of-the-art hashing algorithm of choice when protecting encryption keys. Its memory-hard properties introduce a large penalty for brute-search on general computers and even more so on GPUs and ASICs.

Choosing Parameters[edit]

This is how to calculate entropy for Argon2id. An example [15] using arbitrary parameters is below:

  • 1 GiB RAM, 50 iterations and 4 threads
  • m=1GiB, t=50, p=4

The "20" comes from the exponent of 2 that gives the number of kilobytes in 1 GiB RAM amount that is used (2^20 = 1048576 in this case). The number of 1 KiB block operations is most important. For 4 GiB, the exponent becomes "22" (2^22 = 4194304).

General Computers "Lower Bound"

20 + (log (50) / log(2)) = ~26 bits

GPUs and ASICs "Upper Bound"

20 + (20 - (log (8*4) / log (2))) + (log (50) / log (2)) = ~41 bits

Subtracting the parallelism (8x within a block and 4x thread-level p=4), because for this sort of attack the parallelism reduces the duration for which the memory has to be occupied.

Comments [15]

Then, I think t=50 is excessive.  It isn't even the equivalent of a one
word longer passphrase, but it takes more time than typing a word would.

Perhaps you should consider t=3.  That will be only "4 bits" less,
giving you something like 22 to 40 bits (depending on attack hardware)
of stretching relative to BLAKE2b.

--SolarDesigner (OpenWall lead and cryptographer who participated in Password Hashing Competition)

Migrating LUKS FDE to Argon2id[edit]

These steps migrate systems which are currently encrypted with LUKS first from a LUKS1 to LUKS2 header, then shift to Argon2id. Removable media migration should be straightforward, however the main running system will require extra pre-boot steps because an open encrypted volume cannot be modified. [16] Take precautions such as backing up your data and make a copy of the required steps since they will be inaccessible during part of the process.

Enumerate all devices to determine partition name:

# ls /dev/

Verify the partition in question is an encrypted one (sda5 typically on default non-customized installs):

# blkid -p /dev/sda5

To see details about the LUKS header and to confirm it was converted in the end:

# cryptsetup luksDump --debug /dev/sda5

Before rebooting, it is advisable to check the ‘algif_skcipher’ kernel module is included in the initramfs image, otherwise it might not be possible to open LUKS2 volumes. [17] To do so, run the following two commands:

# echo algif_skcipher | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u

Now assuming the bootloader is GRUB:

  • Reboot.
  • Press <E> to obtain an emacs-like screen.
  • Append “ break=premount” to the line starting with “linux”.
  • Press Ctrl+X to boot - the edit is transient and will not survive the next reboot (users should land into an initramfs debug shell).

Convert the header to LUKS2:

cryptsetup convert /dev/sda5 --type luks2 --debug

Then convert to Argon2id. Parameters used in this example:

  • 1 GiB RAM.
  • 50 iterations.
  • 4 threads.

cryptsetup luksConvertKey --key-slot 0 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/sda5

Guidelines[edit]


For LUKS FDE where memorization is a burden (assuming EFF list and 26 bit Argon2id lower bound):

  • [post-quantum] 10 words + Argon2id = ~90 bits
  • [post-quantum] 11 words + Argon2id = ~97 bits
  • [post-quantum] 12 words + Argon2id = ~103 bits

For LUKS FDE where memorization is a burden (assuming EFF list and 24 bit Argon2id lower bound for faster logins [configured by 4 GiB, 3 iterations, 4 threads]):

  • [post-quantum] 10 words + Argon2id = ~88 bits
  • [post-quantum] 11 words + Argon2id = ~95 bits
  • [post-quantum] 12 words + Argon2id = ~102 bits

In summary, 12 words is the safest compromise, giving a comfortable security margin at mild cognitive expense.

For any other encrypted media/container that does not implement Argon2id or where memory is not a problem because you can safely store the password on your encrypted computer:

  • [post-quantum] 20 words = 128 bits

Alternatively if memorization is not a problem in the case of non-system media, a shorter alphanumeric string consisting of 43 characters will achieve 128-bit post-quantum strength: [18] [19]

head /dev/random | tr -dc A-Za-z0-9 | head -c 43 ; echo ''

Password Generation[edit]

For all practical purposes using the Linux RNG is sufficient for selecting words in a random fashion. To go one step further, dice can be used to physically choose the Diceware words. [20]

The "diceware" package is available in Debian (and in later Whonix versions by default).

To generate a 12 word passphrase from the EFF's list, run:

diceware -n 12 -w en_eff

Additional Tips[edit]

Follow this additional advice for Diceware passphrases: [21]

  • Diceware passphrases should have spaces between each word, otherwise the strength of the passphrase is materially weakened. For example, a six-word passphrase without spaces “stray clam my aloof micro judo” has the same strength as a five-word passphrase “stray clammy aloof micro judo” with spaces.
  • Only change passphrases if a compromise is suspected.
  • Random character capitalization is not recommended. Although it adds 1 bit per character, it requires regular pressing of the shift key - slowing down typing and increasing the number of keystrokes. Instead, it is better to just make the passphrase longer if additional entropy is required.

Principles for Stronger Passwords[edit]

Users should read Wikipedia: Weak Passwords to learn about better practices for generating strong passwords, and to determine if current passwords are weak. (w). The general principles for stronger passwords are outlined below. [22] The human mind is notoriously bad at coming up with truly random passwords.[23] [24]

Content and Length[edit]

  • Avoid Dictionary-based Passwords: It is unsafe to use passwords that are dependent on dictionary words, keyboard patterns, special letter or number sequences, usernames, phrases from anything read or seen, relative or pet names, biographical information, or persons known to the user.
  • Avoid Short Passwords: Passwords should not be less than 12-14 characters in length; longer passwords are exponentially more difficult to crack than shorter ones. [25]
  • Generate True Password Randomness: Random passwords require the use of specialized tools like Diceware. The human brain is poor at creating passwords which are both easy to memorize and also secure.
  • Online Services vs FDE: Passwords used for online services do not need to be extremely long, since the server rate-limits how many passwords an attacker can attempt. However, passwords used for offline encryption such as full disk encryption should be far stronger, since the threat model is different. An attacker can parallelize brute-forcing the password and is only limited by available system resources. Edward Snowden estimated in 2013 that serious adversaries are capable of one trillion guesses per second. [26]

Poor Habits[edit]

  • Avoid Personal Information: Any information that might be publicly linked to the user or the user's account, or which is known by friends or acquaintances, should never be used for passwords.
  • Avoid SMS-based Two-factor Authentication: Contrary to conventional wisdom, SMS-based 2FA gives away a user's identity, and also makes it easier for third parties to break into an account; for example, by performing sim-cloning or conducting social engineering attacks on the cellular provider. [27]
  • Do not Re-use Passwords: Even slight variations of a password allows the linking of multiple identities back to an individual. Attackers can use these discoveries to make templates which do not completely rely on brute-force attacks.
  • Never Use Online Password Generators: These tools are only useful for satisfying curiosity or additional learning, since it is possible for the server to log the passwords. The only place where passwords should be generated is locally, and ideally by using physical measures (like dice) or via software in a VM disconnected from the Internet.

Storage[edit]

  • Password Managers: Consider using a secure password manager, so hundreds of different passwords can be kept stored in an encrypted password database. Access only requires one master password, which should be cryptographically strong to protect the contents.
  • Physical Records: If passwords are written down, they should be stored securely and not be left in obvious places.

Forum Discussion[edit]

https://forums.whonix.org/t/password-advice-wiki-page-enhancements

See Also[edit]

Footnotes[edit]

  1. https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/
  2. https://www.password-depot.com/know-how/brute-force-attacks.htm
  3. https://en.wikipedia.org/wiki/Diceware
  4. https://en.wikipedia.org/wiki/Password_strength#Random_passwords
  5. https://www.whonix.org/pipermail/whonix-devel/2018-August/001184.html
  6. https://www.rempe.us/diceware/#eff
  7. One trillion guesses per second.
  8. Safe until at least the year 2050.
  9. Assuming Grover's algorithm halves the number of iterations required to brute-force a key. This means doubling the length of symmetric keys to protect against future (hypothetical) quantum attacks.
  10. https://security.stackexchange.com/questions/69374/is-an-80-bit-password-good-enough-for-all-practical-purposes/69378
  11. https://security.stackexchange.com/a/115397
  12. https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/
  13. https://www.whonix.org/pipermail/whonix-devel/2018-August/001184.html
  14. https://www.whonix.org/pipermail/whonix-devel/2018-August/001215.html
  15. 15.0 15.1 https://www.whonix.org/pipermail/whonix-devel/2018-September/001255.html
  16. https://www.saout.de/pipermail/dm-crypt/2018-September/005974.html
  17. See: https://bugs.debian.org/896968 for details.
  18. https://pthree.org/2011/03/07/strong-passwords-need-entropy/
  19. https://unix.stackexchange.com/questions/230673/how-to-generate-a-random-string
  20. http://world.std.com/%7Ereinhold/dicewarefaq.html
  21. http://world.std.com/~reinhold/dicewarefaq.html#
  22. https://en.wikipedia.org/wiki/Password_strength#Guidelines_for_strong_passwords
  23. https://www.schneier.com/blog/archives/2017/05/nsa_brute-force.html#c6753142 "The last time I sat down to work out the statistics from known password lists the initial letter of a password/phrase had less than 4bits of entropy which rapidly dropped to less than 1.5bits by the seventh character, and dropping to a little over 1bit after ten characters. The simple fact is computers are now faster and more adept at password cracking than humans can think up memorable ways to remember strings of information that to humans look random..." --Clive Robinson
  24. https://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase Second reply
  25. https://www.password-depot.com/know-how/brute-force-attacks.htm
  26. https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/
  27. https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/

Random News:

Want to help create awesome, up-to-date screenshots for the Whonix wiki? Help is most welcome!


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)