Bcrypt security

Question

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.

Answer 1

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.

Answer 2

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.