Storing Passwords Securely

In web applications most important thing is how user passwords are protected. Because of hacking user account databases, you must do something to protect users passwords. The best way to protect user’s passwords is using Salted Password Hashing.

What is Hashing Algorithms.?

Hashing algorithms are one way functions that cannot be reversed, it will turn any length of data to a fixed length known as Fingerprint. If the one bit of input data was changed the output was totally different. There are many hashing algorithms available, the most popular algorithms are,

  • MD5
  • SHA-1
  • SHA-256
  • SHA-512

this is great, because it’s one way function and no one can reverse it, so we can store passwords using these algorithms, but if it’s one way function how we validate users passwords? let me explain,

  1. When user creates a account, their password will be hashed and store on our database.
  2. Once he trying to log into our application we will,
    1. Hashed his input password using same algorithm
    2. Then we comparing stored hash with generated hash from his input
    3. If both hashes are matched, he will authenticated.

But this is not enough to protect users passwords, because there are many ways to get plain text from hash.

 

Possible Attacks against Password hashes

  1. Brute Force and Dictionary Attacks
    • Brute Force Attacks –
      • In this attacks, automated software used to generate large no of consecutive guesses until matched the desired data.
      • Explaining Attack –
        • the automated software will generate large amount of guesses using given chars and length
        • each guess will be hashed using same algorithm and will compare with the target hash
        • if the hashes are matched, the automated software will terminate the processPassword Bruteforce Example
    • Dictionary Attack
      • In this attack, very large word set uses to guess the password.
      • Process is same as bruteforce attack, each word will be hashed and compared with target hash.
      • Password dictionary looks like,
        • abcd
        • abbd
        • abbd
        • ……..
  2. Lookup Tables
    • The general idea is pre-compute the hash of a password dictionary and store them with their corresponding password.
    • Example –
      • E2FC714C4727EE9395F324CD2E7F331F – abcd
      • 5F4DCC3B5AA765D61D8327DEB882CF99 – password
      • A029D0DF84EB5549C641E04A9EF389E5 – mypass
  3. Reverse Lookup Tables
    • First attacker create a lookup table
    • Then attacker will match the hash with compromised hash
    • Example –
      • E2FC714C4727EE9395F324CD2E7F331F – abcd
      • attacker will look for same hash instead of abcd.
    • This will allow attacker to apply a dictionary or brute-force attack to many hashes at the same time.
  4. Rainbow Tables
    • rainbow table is a precomputed table.
    • It’s not lookup table but it looks like it.

Salted Passwords

  • This technique will prevent cracking passwords using Lookup tables, reverse lookup tables and rainbow tables.
  • The concept is,
    • password = E2FC714C4727EE9395F324CD2E7F331F
    • password + erscjgm235esak = E40C2A3D3B63E800AE739BC1509EC1D7 (Salted Hash)
    • password + cngrso4365nfdn = 8208BB9CBB644D71539501A476B7FA72 (Salted Hash)
  • How it will prevent the lookup table attacks,
    • Lookup table attacks effective because of, if two or more users password is same they have same hash.
    • By adding salt to passwords, if users have the same password then hash will be different.
  • Salt is not secret thing, we just use it to randomize the hash
  • If each user’s password is hashed with a different salt, the reverse lookup table attack not effective
  • Common mistakes are
    • Salt Reuse & Short Salt
      • Salt Reuse / Hard coded salt
        • this is useless because if two users have same password, still the password hash is same.
        • this will allow an attacker to use lookup tables, reverse lookup tables and rainbow tables.
        • a unique salt must be used in every time user creates an account
      • Short Salt
        • If the salt is short an attacker can build a lookup table for every possible salt.
        • Think salt is about 2 ascii chars, possible salts are only 95*95=9025, so an attacker can easily build a lookup table for every possible salt.
        • The best practice is use the hash function output length as the salt length.
        • Salt should be at least 32 random bytes

Validating Salted Password

  • Retrieve  user salt and the hash from the database
  • Then hash the user entered password with salt using same hashing algorithm
  • Then compare both hashes, if both are matched password is correct.

Best Practices

  • Use long Salt, at lease 32 bytes
  • Do not reuse Salts or hard code
  • Salt must be unique for each user
  • Salt can be store alongside with the password hash, no need to protect it
  • Salt should be generated by using Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), because CSPRNG is providing a high level of randomness, so same salt  generating possibility is too low.
  • Always hash on the server side
  • Do not use any algorithm that you designed yourself