Cryptography/Secure Passwords

From Wikibooks, open books for an open world
Jump to: navigation, search


A serious cryptographic system should not be based on a hidden algorithm, but rather on a hidden password that is hard to guess (see Kerckhoffs's law in the Basic Design Principles section). Passwords today are very important because access to a very large number of portals on the Internet, or even your email account, is restricted to those who can produce the correct password. This usually involves humans in choosing, remembering, and using passwords. All three aspects are commonly weaknesses: humans are notoriously bad at choosing hard-to-break passwords,[1] do not easily remember strong passwords, and are sloppy and too trusting in their use of passwords when they remember them. It is nearly overwhelmingly tempting to base passwords on already known items. As well, we can remember simple (e.g. short), or familiar (e.g. telephone number) pretty well, but stronger passwords are more than most of us can reliably remember; this leads to insecurity as easy methods of password recovery, or even password bypass, are required. These are universally insecure. Finally, humans are too easily prey to phishing fraud scams, to shoulder surfing, to helping out a friend who has forgotten their own password, etc.


But passwords must protect access and messages against more than just human attackers. There are many machine-based ways of attacking cryptographic algorithms and cryptosystems, so passwords should also be hard to attack automatically. To prevent one important class of automatic attack, the brute force search, passwords must be difficult for the bad guys to guess. be both long (single character passwords are easily guessed, obviously) and, ideally, random -- that is, without pattern of any kind. A long enough password will require so much machine time as to be impractical for an attacker. A password without pattern will offer no shortcut to brute force search. These considerations suggest several properties passwords should possess:

  • sufficient length to preclude brute force search (common recommendations as of 2010 are at least 8 characters, and more when any class of character is not allowed (e.g. if lower case is not permitted, or non alphanumeric characters are not permitted, ..., a longer password is required); more length is required if the password should remain unbreakable into the future (when computers will be faster and brute force searches more effective)
  • no names (pets, friends, relatives, ...), no words findable in any dictionary, no phrases found in any quotation book
  • no personally connected numbers or information (telephone numbers, addresses, birthdays)

Password handling[edit]

Password handling is simultaneously one of the few Solved Problems of Cryptography, *and* one of the most misunderstood.

Any web server that stores user passwords in some file or database somewhere, is doing it wrong.[2][3][4][5]

Passwords are usually not stored in cleartext, for obvious reasons, but instead in digest form. To authenticate a user, the password presented by the user is salted, hashed, and compared with the stored hash.[6]

PBKDF2 was originally designed to "generating a cryptographic key from a password", but it turns out to be good for generating password digests for safe storage for authentication purposes.[7][8]

In 2013, because only 3 algorithms are available for generating password digests for safe storage for authentication purposes -- PBKDF2, bcrypt, and scrypt -- In 2013, the Password Hashing Competition (PHC) was announced. [9][10][11][12]

passphrase hashing algorithm[edit]

The main difference between a password hashing algorithm and other cryptographic hash algorithms is that a password hashing algorithm should make it difficult for attackers who have massively parallel GPUs and FPGAs to recover a passphrase -- even if the passphrase is relatively weak -- from the stored password digest. The most common way of doing this is to design the algorithm so the amount of time it takes for such an attacker to recover a weak passphrase should be much longer than the amount of time it takes for an authorized server, when given the correct passphrase, to verify that it is in fact correct.

The password verification utility passwd uses a secret password and non-secret salt to generate password hash digests using the crypt (C) library, which in turn uses many password hashing algorithms.

Often a single shadow password file stores password hash digests generated by several different hash algorithms. The particular hash algorithm used can be identified by a unique code prefix in the resulting hashtext, following a pseudo-standard called Modular Crypt Format.[13][14][15]

Any available hash algorithm is vastly superior to the shameful[16] practice of simply storing passwords in plain text; or storing "encrypting" passwords that can be quickly decrypted to recover the original password.

Unfortunately, practically all available hash algorithms were not originally designed for password hashing.

While one iterations of SHA-2 and SHA-3 are more than adequate for calculating a file verification digest, a message authentication code, or a digital signature when applied to long files, they are too easy to crack when applied to short passwords even when iterated a dozen times. Practically all available hash algorithms as of 2013 are either

(a) already known to be relatively easy to crack (recover a weak password) using GPU-based brute-force password cracking tools, or (b) are too new or haven't been studied enough to know whether it's easy to crack or not.[17]

For example, systems have been built that can recover a valid password from any Windows XP LM hash or 6-printable-character password in at most 6 minutes,[18][19] and can recover any 8-printable-character password from a NTLM hash in at most 5.5 hours.[18]

For example, systems have been built that can run through a dictionary of possible words and common "leet speak" substitutions[19] in order to recover the password that produced some given MD5 hash at a rate of 180 Ghashes/second,[20] or produced some given DEC crypt() digest at a rate of 73 Mhashes/second.[21]

Further reading[edit]

  1. Burr, Dodson, Polk. "Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology" section A.2.2 "Min Entropy Estimates": "Experience suggests that a significant share of users will choose passwords that are very easily guessed ("password" may be the most commonly selected password, where it is allowed)." [1]
  6. "How to securely hash passwords?"
  7. "Does NIST really recommend PBKDF2 for password hashing?"
  8. "Is it safe to use PBKDF2 for hashing?"
  10. "Increase the security of an already stored password hash". quote: "a new open competition for password hashing algorithms has been launched, using the model of the previous AES, eSTREAM and SHA-3 competitions. Submissions are due for the end of January 2014."
  11. "Password Hashing Competition"
  12. "Are there more modern password hashing methods than bcrypt and scrypt?"
  13. Simson Garfinkel, Alan Schwartz, Gene Spafford. "Practical Unix & Internet Security". 2003. section " crypt16( ), DES Extended, and Modular Crypt Format". "The Modular Crypt Format (MCF) specifies an extensible scheme for formatting encrypted passwords. MCF is one of the most popular formats for encrypted passwords"
  14. "Modular Crypt Format: or, a side note about a standard that isn’t".
  15. "Binary Modular Crypt Format"
  16. "Plain Text Offenders"
  17. Dennis Fisher. "Cryptographers aim to find new password hashing algorithm". 2013.
  18. a b Paul Roberts. "Update: New 25 GPU Monster Devours Passwords In Seconds". 2012.
  19. a b Dan Goodin "Anatomy of a hack: even your 'complicated' password is easy to crack". 2013.
  20. Jeremi M. Gosney. "Password Cracking HPC". 2012.
  21. "John the Ripper benchmarks".