0

How to implement an algorithm for storing and comparing hashes in 2048bits for passwords with random salt for each password with PHP?

EDIT 1:

I guess I was not clear enough in my question. What I mean is that I will not make my encryption algorithm. But how could store a password and salt. Being the random salt for each password. Well, it would not be sensible to store the salt along with the password in the database.

EDIT 2:

That would be a good approach?

1) user enters their password,
2) system generates a hash of the password,
3) system generates a password for this salt (I use time ()?)

Being the random salt, how and where could store the salt to the password? Please, I would not want to store the salt along with the password, because I think this is not so sure.

So after the stored password and the salt of the same when the user logs in, I get the password hashes stored along with the salt and compare it to the hash of the password supplied with the salt saved.

Where to save the salt? This would be a good approach to do this?

Maykonn
  • 2,738
  • 6
  • 33
  • 51
  • I was about to suggest the same – Dale Nov 28 '12 at 10:59
  • 1
    I can't help but ask - *WHY ON EARTH* would you use 2048 bits for a password? What algorithm do you use for this? If you're thinking of building your own - don't! Peer-reviewed algorithms are a much safer bet. Every company who has tried custom crypto will agree with this - as they all got broken in through their "custom" crypto. – Sébastien Renauld Nov 28 '12 at 11:00
  • I guess I was not clear enough in my question. What I mean is that I will not make my encryption algorithm. But how could store a password and salt. Being the random salt for each password. Well, it would not be sensible to store the salt along with the password in the database. – Maykonn Nov 28 '12 at 11:04
  • that's a big hash...are you sure you are not mixing up encryption keys with hashes? – kittycat Nov 28 '12 at 11:05
  • 2
    The fact that there's peer reviewed solutions doesn't make the question less interesting from a theory point-of-view. Except for not using ready-made solutions, another common pitfall is using ready-made solutions without understanding the theory behind them. – Carl Ekerot Nov 28 '12 at 11:05
  • It really is great. But I read somewhere about it. What would be the best approach, since only md5 without salt is not as safe when your users create passwords like "pass1234"? An MD5 of this would be easily found on Rainbow Tables. – Maykonn Nov 28 '12 at 11:08
  • 1
    Have a look at the [crypt-function](http://php.net/manual/en/function.crypt.php) using `CRYPT_BLOWFISH`. The link I posted has good examples. Bcrypt has become somewhat of a de-facto standard, so give it a shot. Just avoid the `$2x$` and `$2y$` modes of the algorithm if you want to be extra secure ;) – Carl Ekerot Nov 28 '12 at 11:24
  • *"Well, it would not be sensible to store the salt along with the password in the database."* - It is perfectly sensible. Why would you think it's not? – deceze Nov 28 '12 at 11:27
  • Because if my database is compromised and someone has access to this data, it will have the salt for each password with each password. And that is not correct. Well I think I just would not make sense to use a salt and give it to brute force along with the password. Because it would be correct? – Maykonn Nov 28 '12 at 11:33
  • Use the aforelinked PHPASS library or https://github.com/ircmaxell/password_compat, both of which worry about the salt internally *and save it as part of the hash value*, in plain sight. Both libraries are good, tested, approved, secure. Stop worrying about something which you honestly do not understand. – deceze Nov 28 '12 at 11:59
  • A **salt** is not meant to be secret, just store it in the database. A secret can improve security in some circumstances, but that is the job of the **pepper**. Don't mix up this two. If you want to read more about [salt and pepper](http://www.martinstoeckli.ch/hash/en/index.php), then have a look at this tutorial. – martinstoeckli Nov 28 '12 at 12:07

1 Answers1

5

"Well, it would not be sensible to store the salt along with the password in the database."

"Because if my database is compromised and someone has access to this data, it will have the salt for each password with each password. And that is not correct. Well I think I just would not make sense to use a salt and give it to brute force along with the password. Because it would be correct?"

These core assumptions are wrong. The point of a salt is to add a unique element to each password so two identical passwords won't hash to the same hash value. The salt is not secret. I repeat: the salt is not secret. The secret is the password, the salt just adds the uniqueness. An attacker will have to brute-force a password by trying every possible combination of characters and comparing the result to the hash value. If he also knows the salt, he will still have to do exactly that.

If the attacker successfully brute-forced the password "foobar" without salt, he has brute-forced every password "foobar". If you add a unique salt and the attacker successfully brute-forced the password "foobar" + salt, he has only brute-forced that one password. He'll have to attack every other password "foobar" separately, since they all hash to a different value, thanks to the unique salt.

That is the point of a salt. Yes, it would be even better if you could keep the salt secret as well, since then the attacker would have to essentially brute-force a value many times longer. But that's infeasible, since you need access to the salt to confirm the password as well. If you need to have access to the hash and salt, then an attacker who has access to the hash likely also has the same access to the salt. It also does not detract from the security if the attacker has access to the salt.

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • 1
    Someone who understands crypto! Don't forget the other huge advantage of salting - it makes generating rainbow tables infeasible. – lynks Nov 28 '12 at 11:49
  • @lynks Well, that's essentially what my second paragraph states. :) – deceze Nov 28 '12 at 11:50
  • Totally agree, if you really want to add a secret to the hashing, then you better use a pepper additionally to the salt, but don't mix up salt and pepper, because they have a different purpose. – martinstoeckli Nov 28 '12 at 12:01
  • Then the salt can be known by anyone? It will only serve to ensure that passwords are not repeated? Difficult, yet the work of the attacker, because he could find a password but would have to repeat the work for all the others, because there is no repeat passwords in the database. I understood correctly? – Maykonn Nov 28 '12 at 12:13
  • 1
    @MayW. - I think you understood, if you do not add a unique salt per password, an attacker can build one single rainbow-table and get all passwords. If you add a unique salt per password, he would have to build one rainbow-table for each password. Building a rainbow-table per password doesn't make sense, you can just brute-force until you find a match and then stop. – martinstoeckli Nov 28 '12 at 12:17