Cryptography/Secure Passwords

PasswordsEdit

A serious cryptographic system should not be based on a hidden algorithm, but rather on a hidden password that is hard to guess (see Kerchoff's Laws). 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.

SecurityEdit

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 handlingEdit

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]

Further readingEdit

  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]
  2. http://plaintextoffenders.com/
  3. http://crypto.stackexchange.com/tags/passwords/info
  4. http://security.stackexchange.com/questions/17979/is-sending-password-to-user-email-secure
  5. http://security.stackexchange.com/tags/passwords/info
  6. "How to securely hash passwords?"
  7. "Does NIST really recommend PBKDF2 for password hashing?"
  8. "Is it safe to use PBKDF2 for hashing?"
  9. http://crypto.stackexchange.com/questions/12795/why-do-i-need-to-add-the-original-salt-to-each-hash-iteration-of-a-password
  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?"
Last modified on 13 January 2014, at 20:56