6

I know this is an 'over asked' topic, Bcrypt, however I have a few concerns in regards to it's secureness.

I've been using sha512($password.$salt) and then looked for a better solution and came across Bcrypt.

What concerns me, was when reading about it, it said the number of rounds ($02$) and salt is stored within the hash in 3 seperate 'blocks', like so, $rounds$.$salt.$hash (or least that's how I've interpreted it).

My question is: isn't this insecure? Displaying the number of rounds used, and the salt clearly available. Because the attacker can just go "ok I need 2 rounds, the salt is 123salt and that's the hash", right?

I understand when reading, it's not 'all' about being secure, it's how long it takes to crack the password, and that's the benefit of Bcrypt, it's slow.

Could anyone clarify my misinterpretations / misunderstandings please?

Thanks.

gen_Eric
  • 223,194
  • 41
  • 299
  • 337
RobAtStackOverflow
  • 525
  • 3
  • 16
  • How are you storing the salt right now? – SLaks Aug 02 '12 at 15:48
  • I asked the very same question: http://stackoverflow.com/questions/9420722/improve-password-hashing-with-a-random-salt – Tchoupi Aug 02 '12 at 15:50
  • SLaks, I currently insert the hash into the mysql database - Although I've read Bcrypt already includes a salt, I add another one, like so Bcrpyt($email.$random_salt.$password,14 rounds) and insert the result into the DB. MathieuImbert - I hadn't realised. I did check when the box came up and said 'similar questions' though. – RobAtStackOverflow Aug 02 '12 at 15:53
  • If you're already storing the salt right there, what are you concerned about? – SLaks Aug 02 '12 at 15:54
  • Not quite sure I understand your question, sorry if I've misinterpeted it. I don't actually store my random salt in the database, I include it into the hash. If you mean the salt already being displayed, I can't really do anything about that - That's the Bcrypt 'design'. – RobAtStackOverflow Aug 02 '12 at 15:59

2 Answers2

11

bcrypt is about security by irreducable complexity; not security by obscurity.

The point of a salt is to prevent the attacker from re-using calculations for multiple users.
There is nothing wrong with giving it to an attacker.

Similarly, even if the attacker knows how many rounds you're using, that won't same all that much time (assuming you're using a decently high number of rounds).
The point of using many rounds is not that the attacker won't know how many rounds to use; it's that each rounds forces the attack to take longer.

Community
  • 1
  • 1
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • Oh right ok, I thought the salt was to make the password more secure and it wasn't to be known by the attacker if possible. I guess that makes more sense/clarify's things, thanks. – RobAtStackOverflow Aug 02 '12 at 15:57
  • @Anonymous2011: The salt is to make pre-built lookup tables redundant. An attacker would have to compute the full tables from scratch. – Leigh Aug 02 '12 at 15:58
  • @Anonymous2011: Hiding the salt from the attacker will help (assuming you can do that effectively while maintaining per-user salts), but it's not at all essential. – SLaks Aug 02 '12 at 15:58
  • What you can do is encrypt the result of the bcrypt hash using a key stored only in a separate secure store on a different server. This would make your DB even more useless to attackers. – SLaks Aug 02 '12 at 15:59
  • Leigh; Ah right ok, I guess that does make sense. Slaks; In development at the moment I'm storing the salts together in the users table, and each salt is different per user. In production, I'm thinking about creating another DB just to store the salts (different username/password etc) for extra security. I think that's a bit more complicated than I'm looking to do at the moment, however I won't give it a miss - Thanks for that tip there, didn't think about doing that. – RobAtStackOverflow Aug 02 '12 at 16:07
4

The salt is stored with the hash because a different salt is used for every hash, unlike your previous approach with sha512, where you were using the same salt for every hash.

With this method, a single rainbow table will only be good for a single password, whereas if the same salt was used for every hash, a single rainbow table would be good for all hashes.

The work factor (as you call it: "rounds") needs to be stored too, so that the hash can be correctly verified. Yes you could strip it out, but it's really no harm done.

bcrypt has been designed to be an intensive algorithm. It is expensive to compute a single hash, and impossible to create lookup-tables for hashes with high work factors.

The work factor is designed to be changed as technology advances, so that it will always be difficult to crack bcrypt hashes. But you can only upgrade a hash while in the process of verifying a password.

You may end up with a system where different hashes have different work-load values stored in them, depending on which ones have been upgraded and which have not.

Leigh
  • 12,859
  • 3
  • 39
  • 60
  • That's my fault, I should've clarified I was using random salts with sha512 - However I see your point on using one 'static' salt isn't good. Now I understand how rainbow tables work better and how they work in password cracking, I totally got the wrong end of the stick on them. I can see how Bcrypt is better now. – RobAtStackOverflow Aug 02 '12 at 16:16