Is it safe to include the iteration count in the password hash

Question

A colleague implemented our password-hashing code after a fair amount of research, including taking advice from https://crackstation.net/hashing-security.htm

The resulting password hash includes the salt (which is supposed to be OK, and is necessary to validate the password), and also includes the iteration count, which is high for key stretching.

It's nice that the iteration count is saved in the database, because lower counts can be used in unit tests, and if we change the counts then existing saved password hashes can still be validated. But I wonder if it's safe to include the number, because wouldn't a brute-force attack be easier if the iteration count was known? It seems to me that this would prevent a lot of extra checks against each iteration count tested incrementally.

Answer 1

It is ok to include the iteration count in the resulting hash.

Most important, this allows you to increase the number of iterations when future hardware will become faster. It is necessary to be able to adapt to faster hardware, without loosing older hash values.

It wouldn't help much to hide this number. If it is not known, an attacker would assume a reasonable number, maybe a bit higher. He could not only compare the last iteration with the hash-value, but also every step between. In case of BCrypt with a logarithmic cost parameter, this would be about 3-5 compare operations more (too small numbers are not reasonable), that's not a big deal.

Well known APIs like PHP's password_hash() will include the cost parameter as well.

Edit: Hiding the number of iterations would add a kind of secret to the hashing process, an attacker has to guess this number. There are much better possibilities though to add a server side secret, i tried to explain this in my tutorial about safely storing passwords (have a look at the part about pepper and encrypting the hash-value).