1

The problem I want to avoid is "brute force" attacks against a database. So if I add a 50-byte-long cryptographically random salt to my information (which I don't need to retrieve, just its hash) - is it secure enough?

I know the answer is inexact - It depends on if it's a supercomputer, or a PC etc. I want to get a general idea - can a supercomputer go through 10^9 of them in a second? 10^20? Will it take a PC a year to go through all of them? Be vague.

EDIT: The salt will remain in the hashed result only.

ispiro
  • 773
  • 1
  • 7
  • 18
  • Hi @ispiro, welcome to [security.se]. The answers to this question, even if it made sense to answer at all, would by necessity be out of date as soon as they are written... Besides, as the answer below explains, this doesn't really make sense, as I think you may have misunderstood how these mechanisms work. But please hang around, pick up some more details, and maybe we'll be able to help you more with your next question...! – AviD Aug 06 '12 at 17:09

1 Answers1

4

The purpose of a salt is not to make computing the hash slower, it's to prevent rainbow tables from being useful. A single iteration of SHA512 is way too fast to be useful against bruteforcing attacks.

On a decent GPU, you can do ~100M hashes/sec (new link) with SHA512. Multiply this for systems with multiple GPUs. With a slow KDF such as bcrypt, you can tweak the iteration count to be more suitable. You want something around ~0.3s/hash for a good security margin.

Keep in mind that 50 bytes is 400 bits, or a keyspace of 2^400. You're almost guaranteed to find a collision in SHA512 if you manage to compute 2^400 hashes. However, the attacker isn't trying to guess the salt. What you should be worried about is an attacker cracking the hashes when they already know the salt.

The solution is use PBKDF2, bcrypt, or scrypt, and store the salt in plaintext in the database.

Update:

It looks like you're trying to implement your own scheme. Please do not do this. There are two widely accepted rules of cryptography:

  1. Cryptography is hard.
  2. Don't roll your own.

I cannot stress strongly enough how dangerous it is to roll your own schemes, especially when dealing with crypto. Not even the legendary Bruce Schneier would dare write his own cryptosystem without serious peer review and months (if not years) of testing and tweaks.

The advice I've given you with regards to hashing is a standard based on peer review and a huge amount of theoretical and practical testing. Attempting to augment it using extra hashing and other black-magic is a bad idea, and will only increase the attack surface of your application and create a potential security flaw. Stick to the standard.

Community
  • 1
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • a) Thanks. b) "The purpose of a salt is not to make computing the hash slower" - True, but it _is_ to make the number of possibilities larger, and so to _create_ the table (or search for a possibility that will give that hash) - will take longer. 100M/s is slow compared to the 2^400 possibilities in the case I outlined. – ispiro Aug 06 '12 at 14:43
  • 3
    No, that's incorrect. The attacker _already knows_ your salt, because he's breached your database to get the hash. The point of the salt is to make every hash unique, so that a precomputed database cannot be used to look up all hashes and get the plaintext. The reason you should use a large random salt is that it makes the probability of duplicates near zero. – Polynomial Aug 06 '12 at 14:44
  • See edit at the bottom of my question. Thanks for making me realize that wasn't clear. – ispiro Aug 06 '12 at 14:45
  • What do you mean by "the salt will remain in the hash"? If you hash the salt, you cannot retrieve the original salt, so how do you verify that a password is correct? – Polynomial Aug 06 '12 at 14:45
  • It will not be stored anywhere in the database. The password becomes: itself+salt (and saved by user.) – ispiro Aug 06 '12 at 14:50
  • Where are you storing it, then? I sincerely hope that the salt is unique to _each_ user. – Polynomial Aug 06 '12 at 14:51
  • You're making this a lot more complicated than necessary. I suggest you read through the answer I linked ([this one](http://security.stackexchange.com/questions/17421/how-to-store-salt/17435#17435)) and improve your understanding of password hashing and salting schemes before continuing. – Polynomial Aug 06 '12 at 14:53
  • The salt would never be typed in by a person. It's generated randomly and stored in the database with the hash. – Polynomial Aug 06 '12 at 15:21
  • @Polynomial, Your link for "100 M hash per second" is down... – Pacerier Jan 22 '14 at 21:12
  • @Pacerier Fixed. – Polynomial Jan 22 '14 at 21:57