Password security in databases - today still best practice? [duplicate]

Question

Possible Duplicate:
Which password hashing method should I use?

There are a ton of great posts about password security in databases on stack overflow and on other sites and as I am completely new to this I spent quite some hours trying to learn more about it in the last days. However, there are so many different suggestions and best practices that I still got very confused...

Also, there are still many older posts from 2007-2010 etc I as I saw how fast things change I am not sure if this is still common to use it like they suggest. So, I wanted to summarize what I found in the posts and then ask if this method I found was a good practice...

So, this is not a guide, but a summary, I know it is very very basic and if there are mistakes please correct me!

1. Just to mention: you should never store plain text passwords :)
2. You "one-way" hash passwords, so nobody can ever see the plain text. When the user enters the password, you hash it the same way and compare it with the hashed pass in the database.
3. In addition to hash a password, you should salt it. You add the salt to the plain password string and hash the new string. If the plain password is weak, adding the salt makes it longer and stronger.
4. The salt should furthermore be random (I've read that the term "salt" means it is random anyway, otherwise it was called "key"?). This is to prevent rainbow table attacks, because the attacker would need to create one table for each salt which is much more expensive in terms of time etc. Also if two users have the same password you will not recognize it if you use random salts.
5. The salt is not a secret! It is being stored in the database next to the hashed password. However, it may not be the best idea to use a timestamp, the user's e-mail address or anything else connected to the user as a random salt. As a reason it is e.g. mentioned that users tend to use the same passwords on multiple sites/services. So, the salt should be a random string, I've read best would be 64-bit?
6. The next step is to add iteration to the hashing process (1000 or more loops), so the salt is added to the password and they are then hashed over and over, which means only a fraction of a second for the user to wait when logging in, but sums up if you have somewhat 10.000 entries in your DB.
7. It might be a slight benefit, if you add a site key, stored e.g. as a global var in addition to the salt. However, you should always suppose that attackers have access to your file system as well.
8. Hashing algorithms: I found for sure it is not secure anymore to use MD5, SHA1 and other weak methods...

So, there are different opinions on wether to use SHA256, SHA512? Should you use hash_hmac? Some say yes: (http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/) some say using libraries is the only secure way... and then once or twice in a post I've read not to use libraries as bcrypt or bubble fish??

Is it really necessary to use a library or is e.g. a method like this enough:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Many people say don't invent your own algo, so I am a little bit scared just to use anything self-invented.

I can imagine it is hard to predict, but how long can a method used to today be considered as being secure enough?

UPDATE: So, thank you for all your great feedback. There is one main point missing, as I see and many of you said: password security, meaning a strong password is the basic. I think I got the message, thank you again! :)

UPDATE 2: Just for completion, I have found following code on http://www.lateralcode.com/creating-a-random-string-with-php/ that I use to generate a random salt:

function rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= rand_string(20);

Answer 1

General info:

Nice question but all I can say is it totally depends on the usage. If you use it only for a small website, there is a high chance only "script kiddies" will visit you, in that case a simple SHA1 with salt is totally enough today as well. In this case, 5-8-10 years or maybe even more is totally good, script kiddies won't really break into it if they see that they can't break in easily. If your site will be attacked for some reason - monetary site, etc. then you should use the newest available functions. In this case I'd even "risk" to use a non-official but already ported function. Right now there's an SHA3 competition, for websties which'll have high money in it, I'd use one of the 5 competitors of these.

The points I say that are important:

1. use a random salt, perhaps even 20 characters. It makes a lot harder to break passwords, and even if they are breakable, it takes too much time to be worth.
2. use SHA-1, SHA-2 or WHIRLPOOL. With good salt, MD5 is OK as well, but I still suggest these.
3. you can use any great cryptography if users' passwords are trivial. You must make sure they use non-dictionary, long passwords with uppercase, lowercase letters, numbers and symbols else it is easily breakable by brute force. You might consider that they could be forced to change password every year or so.

To the code:

Looping many times could be useful but I don't think 5000 is required. 3 for normal security is good, or 100, maybe 1000 could work, but I think 5000 is just too much. SHA-256 is good, but you could use an algorithm specifically developed for that, see the comments.

Answer 2

You forgot just one little thing:

Password strength.

Just 2 words which overweight whole your brilliant topic.

There are indeed hundreds of topics on Stackoverflow telling you to use this or that hashing algorithm and random salts.
And only very few explaining that with weak password all your eight-item-list protection, all extra secure hmac-chmak-bumblemak hashes with 2048 bytes-long-salt will be broken in a matter seconds.

As for the poor users who can't remember $#%H4df84a$%#R passwords - just make them use not a password but a passphrase.

Is it a good day today, Winkie? Uses different case letters as well as password of recommended complexity but much easier to remember.

Of course the phrase shouldn't be as common as common passwords like "Joe" or "123".
"Good morning", "Oh My God! They Killed Kenny!" phrases should be avoided.
But by adding some personality it would be okay:
Oh My God! They moved Cthulhu! looks quite enough

Another thing to mention is a secure communication between server and browser
Without it, a plain password can be easily "sniffed" out on the any of the routers involved in the communication.

SSH or some implementation of Digest authorization is no less essential.

Answer 3

A general purpose hash function (MD5, SHA1, SHA256) with a good hash might be secure enough for most smaller web sites, given the current computing power. However, Moore's law will ensure that even good passwords will be exposed to brute force attacks in the near future. The issue is that hash functions can be computed much too quickly. The best solution is to use bcrypt or PBKDF2 with a high number of iterations. Bcrypt vs PBKDF2 was discussed at http://security.stackexchange.com.

Some people might think this is overkill for most sites but remember that passwords are reused all the time and that password storage is usually something you will not change until there is an issue.

Recommendations:

1. Use bcrypt or PBKDF2. DO NOT USE SHA3 candidates. They might contain security holes that have not been discovered yet.
2. Use a random salt to help protect against rainbow table attacks.
3. Force users to select a passphrase.

More information

Answer 4

The hash_hmac() function would be a good choice, it can even overcome problems of a weaker hash algorithm. The only problem is, that it is too fast. That means with enough cpu-power (cloud), creation of different rainbow tables becomes possible, that's the reason for iterating. If you need this high security, then you can measure the time your iterations need, and then calculate the number of iterations needed for a given time.

Edit:

Iterating can solve this problem, it should be done in a way, that one can increase the number of iterations later, without making existing hashes invalid. This is necessary to adapt to new future hardware, but requires to store the hashing parameters together with the hash.

The bcrypt hash algorithm was designed to meet this demands, i wrote a small example of how to use bcrypt with PHP 5.3, i tried to comment it, so one can understand what's going on.

Answer 5

Well first of all, you are not inventing an own algorithm. You are using an existing one (sha512).

Secondly, you loop 5000 times, that will not do you any good. Only a couple of times will be sufficient.

Thirdly, if you are storing a password with sha512, and add a good seed, it is really really hard to get the password back. And unless you are with FBI or something, it should be considered safe enough as it will take ages to decrypt 1 password, let alone your entire user database.