5

in a project I have, I'm salting passwords with 3 salts at the moment...

  • Static salt - hard-coded into the source-code.
  • Randomly generated salt (using a function designed for generating password salts). This is stored in the MySQL database.
  • A random number that isn't stored.

When checking the hash, I generate 100 different hashes with the static salt, the salt stored in the database, and one of the possible random numbers, if one of them matches the password is correct.

I'm using sha512, by the way.

Is this a secure way to hash passwords?

Thanks!

  • It would probably be better to use a [pepper](http://security.stackexchange.com/questions/41754/what-is-the-purpose-of-a-pepper) than a static salt. –  Sep 13 '14 at 06:00
  • @RickyDemer Isn't that the same thing? – Philipp Sep 13 '14 at 08:47
  • @Philipp: A pepper would ideally remain secret. –  Sep 13 '14 at 08:52

1 Answers1

6

Is this a secure way to hash passwords?

Probably, but a lot of your additional complexity isn't really adding much security value.

The idea of a salt is to ensure there is no method more efficient to recover your passwords than to brute force every single one of them from scratch. Therefore your goal is to ensure no two accounts have the same salt (ie. it is globally unique). If they did then an attacker could basically get two for the price of one by constructing a lookup table while brute forcing the first.

To achieve this you need enough entropy in your salt to ensure the probability of two accounts having the same salt is negligible.

Randomly generated salt (using a function designed for generating password salts). This is stored in the MySQL database.

This is the primary source of entropy in your scheme. You could probably discard the rest without significantly compromising security.

However for this salt to be effective you must ensure:

  • The random value you're using is generated using a RNG suitable for cryptographic applications.
  • There are enough bits in your random value to minimise the probability of a salt collision. OWASP suggests at least 32 bits.

Static salt - hard-coded into the source-code.

This is adding minimal cryptographic value. From a theoretical perspective it's not adding any additional entropy assuming the attacker knows the value, and from a practical perspective DB servers are usually compromised via credentials obtained from a compromised application.

I'm using sha512, by the way.

While this is a cryptographically secure hashing algorithm, it's also a "fast" one which is a problem given that users typically use weak passwords. You should consider using either a slow hashing algorithm (eg. bcrypt) or iterate your hashing process 10k or so times. If it takes a second or so to calculate every hash then even a dictionary attack will take a very long time.

When checking the hash, I generate 100 different hashes with the static salt, the salt stored in the database, and one of the possible random numbers, if one of them matches the password is correct.

The value of this is minimal, you're basically just adding one or two extra characters to the password then brute forcing them every time. This will slow your hashing scheme down which is good, but you'd be better off using the technique above to achieve this.

thexacre
  • 8,444
  • 3
  • 24
  • 35
  • What if I use bcrypt and use my method of salting the password with a random number? – Mitchfizz05 Sep 13 '14 at 04:50
  • um... How would they get enough computing power "to brute force the static salt"? –  Sep 13 '14 at 04:55
  • @RickyDemer well firstly as I mentioned you shouldn't assume a salt is a secret so whether or not they have to brute force it does not really have an impact on whether it is "secure". Secondly, if they did have to brute force it then GPUs can perform hundreds of millions of hashes per second so you'd need quite a bit of entropy to make it secure http://hashcat.net/oclhashcat/. Thirdly, this is a process that only need to be done once regardless of how many accounts there are, so it becomes more economical the more accounts are attacked. – thexacre Sep 13 '14 at 05:17
  • It would be trivial to have almost 128 bits of entropy in the static salt. –  Sep 13 '14 at 05:24
  • @RickyDemer I've removed that line because brute forcing the shared salt is not relevant to the answer given that a salt is not assumed to be a secret any way. – thexacre Sep 13 '14 at 05:43
  • @Mitchfizz05 yes, assuming your unique salts already meet the criteria above. – thexacre Sep 13 '14 at 05:44
  • 1
    @Mitchfizz05: Generating 100 bcrypt hashes would be unnecessarily expensive. Just do it the regular way. – Ry- Sep 13 '14 at 19:10