I know it's compelling to answer users who ask for more transparency on security. But it's not the best thing to reveal implementation details after hashes were leaked.

That's not how bcrypt works. If you have the hash, you know the number of rounds.

Even if that weren't true --- and it very much is --- you'd still trivially be able to find that number given a single known password.

> you'd still trivially be able to find that number given a single known password.

I understand that it's because the salt is entirely appended in clear to the hash. Isn't it better to have a second static salt implemented in the code, in case only the database would be compromised?

I think those schemes are pretty silly, but as long as you're using a well-tested implementation of a real KDF and not some goofy scheme you hacked up yourself so you could add the second secret nonce, I don't care.

Alright, it's true that it feels silly to add negligible protections when your security here is reduced to the KDF and its implementation.

I honestly wouldn't ask if I thought that bcrypt could be cracked by knowing the number of iterations.

Now there may be other bcrypt attacks out there, but none have been announced, and the usage of bcrypt was announced in the text of the post.

Furthermore, if you have the hash, you have the number of rounds. I just have no desire to see if I can download the data (I don't trust random sites, and frankly I don't want the data).

Security by obscurity is not worth the price you pay for it.