1

How do those two ways of hashing compare, security-wise ?

bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))

bcrypt(15, "password")

I know that, usually, iterating on one hashing method doesn't make it more secure, but when an attacker finds the plaintext of the first bcrypt, isn't this plaintext another bcrypt hash which he has to bruteforce again, and this as much times as there are iterations?

SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
Magix
  • 113
  • 5

2 Answers2

4

BCrypt was well designed, and there was much thought put into its operation. There is a special setting included called Work Factor intended to add work when the attacker tries to crack the password.

These two solutions take the same amount of time to compute.

bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))

bcrypt(17, "password")

(work factor 16 takes twice as long as 15, and 17 takes four times as long as 15)

There is nothing gain in complicating your code process. Just choose the ideal work factor. I usually suggest adjusting the work factor so that it takes ~100ms to complete (with appropriate brute DoS protection) on your target hardware. (noting that attacker hardware would probably be faster)

If you are looking for ways to improve on this, I would suggest pre-pending Pepper in front of the password. Pepper is simply a random string that is not stored with the hash itself. You can either hard-code the pepper in your application, or save it in a separated text file. (not in the database) I recommend using a pepper with 72-bits of entropy. (12 Base64 characters, or 18 hex characters)

Since BCrypt has a max-length of 55-56 bytes, it may be wise to first run an SHA-256 hash on the Pepper and the Password, to achieve a consistent 32 character hex string, which fits nicely in BCrypt. (otherwise, supposing you used a 12 character pepper, any characters beyond a 43 byte password would be truncated) Thanks @Walfrat.

Community
  • 1
700 Software
  • 13,897
  • 3
  • 53
  • 82
3

The algorithm of BCrypt is already about to loop on his own data, if you want more security increase the load factor (your 15 here).

Furthermore according to this post : Does bcrypt have a maximum password length?, BCrypt has a maximum length of 50~55 bytes and according to this one ( https://stackoverflow.com/questions/5881169/what-column-type-length-should-i-use-for-storing-a-bcrypt-hashed-password-in-a-d ) a Bcrypt hash is 59~60 bytes long. So it just won't work or may end badly depending of implementation.

Community
  • 1
Walfrat
  • 406
  • 2
  • 12
  • Not sure why you mention the size of bcrypt hashes, what does that have to do with the question? – sethmlarson Aug 11 '16 at 13:13
  • 1
    @Oasiscircle, The question is about re-hashing a completed bcrypt hash, so the hash length is on-topic for the question. While it may not be a major issue, truncating 10 characters of hash before re-hashing is certainly not desirable. – 700 Software Aug 11 '16 at 13:18
  • 1
    @GeorgeBailey Ah I see what you're saying now. This problem goes away if you ignore the control characters in the hash and just use the actual hash for input. – sethmlarson Aug 11 '16 at 13:20