0

Recently i was reading a book regarding a safe way to store a password in the database. The book started with MD5, SHA1, and CRYPT_BLOWFISH. From what i read i understand that the safer way to store passwords is by using CRYPT along with random salt per user(a value that the user inserts in while registrating, like username for example), without storing the salt in the database.

So, lets say that i generate a salt:

$salt = '$2y$11$';
$salt = $salt.md5($username);

As we know a MD5 hash is a 32 character long string. So 7+32 = 39 character string = SALT Something like this: $2y$11$243dc6440dfd91e35a773035da362f4e

Then i generate the hash using crypt():

$hash = crypt($password,$salt);

The crypt hash always results in a 60 character string. The result is: $2y$11$243dc6440dfd91e35a773uY4TBuP14hk.KZq4VvOWV8EhT03Vj8Tu

If a hacker gain access to the database, he/she will see the part $2y$11$ of the 60 character string above.

My question is: Is this info helpful for the hacker (knowing the hashing method and the cost)?

Should I store the hash omitting that part? 243dc6440dfd91e35a773uY4TBuP14hk.KZq4VvOWV8EhT03Vj8Tu

Will this make things worse for the hacker?

Other than these, are there any other suggestions regarding password security AFTER the hacker gains access to the database?

t0mppa
  • 3,983
  • 5
  • 37
  • 48
christostsang
  • 1,701
  • 3
  • 27
  • 46

3 Answers3

1

A salt is used to defend against dictionary attacks and rainbow table attacks becasue the resulting hash is different due to the randomly generated salt which was added to the password.

The salt is saved with the hash so that the hash can be regenerated from the password+salt. So because of this the salt needs to be saved and so what you have done is one possible way of doing this.

The reason this is not helpful to the hacker and won't make things easier is because the whole point of a hashing algorithm is it's resistance to being reversed. Dictionary attacks and rainbow tables work by using known hashes that have been derived from a "word" to a hash. With an added random number in front of the original "word" the hash is completely different and so to create a dictionary or rainbow table with all possible salt values (for a given length salt) would be a huge database and take way too much time for the hacker to crack or even bother attempting.

JacobD
  • 627
  • 6
  • 15
  • If i were to use substr($hash,7) while generating the hash and also while validating the password? – christostsang Mar 06 '14 at 23:49
  • The idea is to never actually store the password onto a storage medium, the password should be processed while it is still in RAM. substr($hash,7) will be fine to obtain the actual hash, which you can then match against a new hash calculated using salt+newpassword. – JacobD Mar 06 '14 at 23:55
1

There is a tutorial i wrote about safely storing passwords, it explains why it is not necessary to hide the hash parameters.

If you hide this parameters you actually add a server side secret (an attacker has to guess the algorithm and the cost factor). There are much better ways to add such a secret though, have a look at the last part of the tutorial about encrypting the hash-value with a server side key.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
  • Very nice tutorial! In contrary to using crypt with a random salt that is not stored in the database (as i explained above), we can create a KEY stored in our server and use this key and the user's password to generate the hash. Is there a particular place in the server that we store such KEYS? Also, i understand that by aquiring this KEY all your passwords are valnurable. Is there a way for the hacker to know that you actually used the server side key method? Because if there is, then he/she will use all his/her power to hack into the server instead. – christostsang Mar 07 '14 at 08:41
  • @christostsang - No don't do that, the encryption should be done on the already hashed password, it is not a replacement! Read the whole tutorial, you should definitvely hash the password with the [password_hash()](http://www.php.net/manual/en/function.password-hash.php) function, afterwards you can encrypt the hash to add the server side secret. Even if an attacker knows the key, he would only see the hashes. – martinstoeckli Mar 07 '14 at 08:45
  • Now i get it! So if you hash the password and encrypt the hash with a KEY and still get hacked then it means that your site is very popular! ! Thanks for the further explanation and tutorial! – christostsang Mar 07 '14 at 09:02
  • @christostsang - Yes, you hash the passwords in case your database with the hashes gets stolen (the passwords are safe even if the hashes are known). With the server side key, an attacker needs additional privileges on the server, because without the key he cannot get the hashes. – martinstoeckli Mar 07 '14 at 09:08
  • "The passwords are vulnerable to SQL-injection attacks." -- this is a bullshit, sorry. – zerkms Mar 13 '14 at 10:13
  • @zerkms - The context of this phrase is, why passwords shall not be stored plaintext in a database. Did you read the whole tutorial? Please read to the end and i'm glad to hear your opinion then. – martinstoeckli Mar 13 '14 at 10:49
  • @martinstoeckli: I have. Passwords are not more or less prone to sql injections than other kind of data. If you process strings properly - they are not "vulnerable", if not - every string is "vulnerable". So my point is - that phrase is just incorrect since it makes false accents and newbies may believe to what you write. – zerkms Mar 13 '14 at 19:23
  • @zerkms - Hmmm - i see your point, english is not my native language and it didn't occur to me that this can be understood differently. I now changed this part to "A successful SQL-injection attack will reveal the plaintext passwords.", i hope this describes the problem better. Thanks for pointing it out. – martinstoeckli Mar 14 '14 at 10:43
0

The system appears to be a 3 part system.

  1. A Salt to prevent Rainbow Table Attacks.
  2. The Salt itself is protected by using some pseudo random data.

  3. The Base Salt and the pseudo random data is mixed and used as the Final Salt.

    • With the 3 parts above you have a system that is resistant to Rainbow Table attacks (1).
    • The System is further resistant to Finding a Rainbow Table for your Salt. (2).
    • So if your system is compromised, an attacker would have to generate a Rainbow Table for each User Account. This is essentially equivalent to cracking that/each users password. (3).

Or so Would the theory go.

SH-
  • 1,642
  • 10
  • 13