3
$\begingroup$

Forgive me for my brief knowledge on hash functions as I am not from a computer science background, however I am researching password security for my thesis and have been looking into hashing functions for password security. I understand that a password goes through a hashing function and is stored in a separate database, at which point if the user enters the same password at a later date, that entry is then ran through the same hashing function and checked the output is the same. My question is, if lots of companies are being breached and passwords have been found out using the algorithms, would it be more secure to then use a second hashing function on the already hashed password and store all the password entries 'double hashed'?

$\endgroup$
  • 1
    $\begingroup$ There's probably good material on that on Information Security. AFAIK, best practice nowadays is using robust off-the-shelf (!) methods that re-hash the password with a salt (!) hundreds if not thousands of times. $\endgroup$ – Raphael Jan 8 '17 at 17:40
  • 2
    $\begingroup$ @Raphael How to securely hash passwords?, and you misspelled “hundreds of thousands or more”. $\endgroup$ – Gilles Jan 8 '17 at 23:18
-2
$\begingroup$

Current best practice goes like this: Step 1, the password is combined with a random sequence of characters (the "salt"), which means that even if two users use the same password, the combination salt + password will be unique for each user, and cracking one combination salt + password does not help at all cracking anyone else's password. Step 2, the combination salt + password is hashed using a cryptographic hashing function, but not once, not twice, but a gazillion times so that calculating the hashed password takes a significant amount of time. Step 3, the salt is stored, but the hashed password is not actually stored, but used to encrypt a master password for that user which is required to decrypt that user's information.

The hashed password is not stored, so someone who manages to steal the complete information on the server still cannot access any user's data. To steal one user's data, an attacker has to guess passwords. Turning each password into a hashcode takes significant amounts of time, so cracking just one good (hard to guess) password should be very hard to crack. And that's just one password.

$\endgroup$
  • 2
    $\begingroup$ The hashed password is stored. Otherwise the server would have no way to authenticate the user. Using the password only to derive an encryption key is a very peculiar setup and doesn't really help defend the password (it just adds the equivalent of a handful of iterations to the password test, which is negligible). $\endgroup$ – Gilles Jan 8 '17 at 23:21
  • $\begingroup$ Please give reference to support your "best practice" claim. $\endgroup$ – Raphael Jan 9 '17 at 6:54
  • $\begingroup$ @Gilles: That's fine for authenticating the user, but definitely not fine for protecting the user's confidential data. If the hashed password was stored, the company owning the server could read every user's data (if they wanted to) which among other disadvantages has fatal legal consequences. $\endgroup$ – gnasher729 Jan 9 '17 at 13:21
  • $\begingroup$ @gnasher729 It is rare for a server to store data encrypted with the user's password. That causes the data to be lost if the user forgets their password. While services that are set up this way do exist, it's only a tiny minority compared with the number of services that use a password for authentication. $\endgroup$ – Gilles Jan 9 '17 at 13:38
2
$\begingroup$

Simply hashed passwords are susceptible to brute force or rainbow table attacks. Hashing the passwords again will simply increase the cost of computing an entry in these tables (by one hash), but that is not an appreciable increase in the challenge of cracking them.

Several techniques available in practice including salt ing the password, wherein you prepend the password with a random substring (known as the salt), which you also prepend (in plaintext) to the hash. So, whereas a password "hello" might hash to h("hello"), the salted password would be foo || h("foo" || "hello"). If "foo" is random, then this means that I may need to store all possible salted hashes for a given password in order to crack it.

To complicate the crack-ability of the password hash even further, one may add a pepper, which is a random (but not published) string prepended to password before hashing. Checking a password in this case requires checking all possible peppers with a given password to see if any hash to the stored hash value.

$\endgroup$
  • 1
    $\begingroup$ Hashing the passwords again a large number of times (e.g. in the millions) is useful and is part of password hashing best practice (not necessarily literally iterating a fast hash function, but something along this principle). A password hashing functions must be salted and slow. See How to securely hash passwords? $\endgroup$ – Gilles Jan 9 '17 at 13:40
0
$\begingroup$

Password is not always in a separate database (but that is a good practice). It many just be in another table.

A double (or more) hash is not really more secure. It just takes a brute force attack longer.

Salt a password makes is harder to crack as cannot use a dictionary attack. A brute force attack is required on every password.

Most of these security breaches is not password. They just copy (steal) user data (e.g. credit card number). The breach is the hacker somehow got direct access to the database.

$\endgroup$
0
$\begingroup$

I understand that a password goes through a hashing function

That is correct!

... and is stored in a separate database ...

Implementation dependent but yes definitely could be.

... at which point if the user enters the same password at a later date, that entry is then ran through the same hashing function and checked the output is the same ...

Back in the days of ye'old security this would be true. Modern security requires a more secure method!

The problem with unseasoned hashes

Lets pretend your the administrator of a database with 100 million users.

This is an example of your password database:

database

Jeff and Adam have the same hashed password!

This means there is a very high likely hood they have the same password.

Since Adam's hint is good enough to determine what the actual password is. Jeff is also compromise and so is everyone else who used the same password!

How to prevent this

Salt your hash!

When a user creates their account assign them a randomly generated string called a 'salt'.

Store this salt alongside the password in the database.

You will need a deterministic way to mix the salt with the hash. A simple way is to simple concatenate the salt on the end of the users password.

bool isPasswordValid(string const username, string const userGivenPassword){
    string const hash = magicDataBaseLookupHash(username); //Get hash associated with user
    string const salt = magicDataBaseLoopupSalt(username); //Get salt associated with user
    return myHashFunction(userGivenPassword + salt) == hash; //Test if hash matches
}

Your Original Question

My question is, if lots of companies are being breached and passwords have been found out using the algorithms, would it be more secure to then use a second hashing function on the already hashed password and store all the password entries 'double hashed'?

Yes it is. If done correctly.

As long as the hashes preserve Entropy the password will be more secure as it requires more iterations of hash functions to crack it.

However this comes with a trade-off!

It takes more processing power on your end every time someone tries to log-in.

So it's your decision as an Administrator to determine if you need more security or or less overhead on user login (generally results in a worse user experience).

Just remember your security is only as strong as the weakest hash.

Consider the following pseudo code:

hashOne( hashTwo( hashThree ( ...  hash5million(password)   ... ) ) );

If hashFive (or any of them) always returns "1" then any password will work for any user.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.