0

I know that PHP 5.5's new hashing function doesn't have to use a user-specified salt, but would it increase security? I've been doing a bit of reading and from what I understand, the hashing function uses a random salt each time which it can retrieve from the hash value when it comes time to verify a hash. But would there be any advantage at all to generating your own salts and using them? Any detriment?

Chris
  • 282
  • 5
  • 19
  • Generating a salt on your own won't do any good. What you can do is, to encrypt the hash with a server-side key, this can be an advantage in certain situations. Have a look at the end of my [tutorial](http://www.martinstoeckli.ch/hash/en/index.php) if you are interested. – martinstoeckli Oct 06 '15 at 15:19

2 Answers2

2

I know that PHP 5.5's new hashing function doesn't have to use a user-specified salt, but would it increase security?

Assuming you are talking about password_hash, then no. It has all the salt you need built-in and there would be no advantage to adding any more.

No detriment either, except that more code = more complexity = more likelihood of bugs.

bobince
  • 528,062
  • 107
  • 651
  • 834
  • I'd like to add that the ability to specify your own salt has been deprecated in PHP 7, because we found no single case where this might be useful, but a lot of cases where people managed to break things spectacularly using it. – NikiC Oct 05 '15 at 15:16
  • @NikiC - Good to hear, i think this is a very wise decision. – martinstoeckli Oct 06 '15 at 15:12
0

Seems you've got a few misunderstandings here.

Once the hash is generated, the whole idea is that it is completely one way. That means, from the message digest of a secure hashing algorithm, there is no way to know what the salt was. I've seen people store the salt in another column, for example.

Salts are designed to create entropy in your message digest set. And to prevent attacks using Rainbow tables. The salt adds an element of randomness to the message digest, beyond what the algorithm and the original value can do.

The detriment to trying to be clever and using your own hash is the realisation that you're probably not as clever as the security experts who wrote the APIs available to you. Seriously, when it comes to security, you can't leverage it against your mind. The human brain is prone to faults; it's why we work in teams. And a team of experts made random hash generators for you. Seriously, use them.

christopher
  • 26,815
  • 5
  • 55
  • 89
  • I should be a little more specific. How does the PHP 5.5 function verify passwords if it uses a random salt on each hash? – Chris Oct 05 '15 at 13:15
  • Of course you have to know the salt to do the verification, it is stored plaintext within the hash-value. – martinstoeckli Oct 06 '15 at 15:14
  • @martinstoeckli So the hash just has the plain-text salt in it? So maybe it wasn't a coincidence I once saw the word "spam" in my hash lol. If someone got access to your database, couldn't they then take the hash, put it into their own page and try to brute force it using password_hash? – Chris Oct 06 '15 at 15:51
  • @Chris - Yes the salt is part of the hash-value, have a look at this [answer](http://stackoverflow.com/a/25403833/575765). And yes again, they could brute-force this password, but this is not what the salt protects from, its purpose is to prevent the attacker from building one single rainbow-table and finding matches for all passwords at once. Instead (s)he must build a rainbow-table for every salt/password separately, what makes those tables unpracticable. – martinstoeckli Oct 06 '15 at 15:56
  • @martinstoeckli - Interesting. Thank you. – Chris Oct 06 '15 at 15:59