Cryptography/Secure Passwords

Passwords
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, 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.

Security
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
"Password handling is simultaneously one of the few Solved Problems of Cryptography, *and* one of the most misunderstood."

- Dan Kaminsky

Any web server that stores user passwords in plain text in some file or database somewhere, is doing it wrong.

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.

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.

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.

passphrase hashing algorithm
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.

Any available hash algorithm is vastly superior to the shameful 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.

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, and can recover any 8-printable-character password from a NTLM hash in at most 5.5 hours.

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

A technique called "key stretching" makes key search attacks more expensive.