34

I've been reading a lot of questions about security and hash functions on this site and others. I am not an expert, just a curious mind and in my understanding the more iterations used to hash a password, the better and you are supposed to get one output equals one input (modulo collision with broken functions). In this regard, the output won't be the same if the iterations number varies.

But what I don't get is how a hacker who tries to find the plain knows how many iterations were used. Because he has to know it or did I miss something?

Improve this question
3
  • 12
    Not really a direct answer, but ideal security architecture works even when the attacker has full access to all implementation details (including hashing round counts). So the assumption that the attacker knows how many rounds were used is not necessarily because it's common, but rather that it's always good to make WORST CASE assumptions when it comes to security.
    – loneboat
    Commented Aug 28, 2015 at 16:09
  • 5
    Security is more like chess than it is poker.
    – corsiKa
    Commented Aug 28, 2015 at 16:18
  • In short, a hacker knows the number of iterations because it's not a secret (given access to the hash itself).
    – Kenny Evitt
    Commented Aug 28, 2015 at 18:09

4 Answers 4

Reset to default
39

Number of rounds is often stored with the password and hash. For example, using bcrypt:

$2a$10$oEuthjiY8HJp/NaBCJg.bu76Nt4eY4jG/S3sChJhZjqsCvhRXGztm

The 10 indicates the work factor, effectively adding 10 bits of entropy in terms of hashing time to brute force. 2^10 = 1024 rounds.

It is stored with the hash in case of the need to up the work factor due to Moore's law.

If your system had a secret work factor that is the same for all accounts, this could be used as an additional security measure, much like a pepper. In fact in the case of an attacker being able to set their own password and view the hash, you would need to combine it with a pepper otherwise they would be able to determine the number of iterations in play from viewing the resulting hash. However, it is more complex to up this in future than it is when storing with each separate password, as you'll need to instead store an indicator of which iteration configuration version was used for each password. You could though have a secret work factor that is added to the value stored with the hash.

Veracrypt has recently added a PIM (Personal Iteration Multiplier) feature that can be used as an additional secret to protect your encrypted data.

Improve this answer
14
  • 29
    You couldn't keep a common secret work factor secret against an attacker who creates an account for himself before he steals your password database, anyway. Since he knows his own password, he can just start hashing it it and see how long it takes until the hash matches the one from the database.
    – hmakholm left over Monica
    Commented Aug 28, 2015 at 11:56
  • 8
    @silverpenguin, no, the salt must be different even if the password is the same, otherwise attackers can see that e.g. two passwords are the same as each other. It's common to include the userID in the hash or salt though.
    – Ben
    Commented Aug 28, 2015 at 13:56
  • 9
    @silverpenguin, that's not what salt is for. Salt doesn't have to be secret it just has to be different for each hash, it's there specifically to solve the problem that the same plaintext generates the same hash, which opens the door for rainbow table/precompute attacks or discovery of passwords which are coincidentally the same as each other. Your example the plaintext (i.e. the password) is already being hashed anyway so adding it to the hash a second time does nothing to defeat either. Salt is supposed to do both. See explanation here: en.wikipedia.org/wiki/Salt_%28cryptography%29
    – Ben
    Commented Aug 28, 2015 at 16:07
  • 2
    "However, it is more difficult to up this in future than it is when storing with each separate password" - not really. I mean you want to update everybody to the higher iteration count immediately anyhow and not just whenever they change their password, so you will want to do it in one go anyhow. In the end that's just taking the hashed password and applying the hashing algorithm a few more rounds, storing the iteration count is not really useful there, but then as long as the user can create their own account also doesn't cost you anything.
    – Voo
    Commented Aug 28, 2015 at 19:51
  • 2
    @Voo that's assuming such a thing is possible. If your password hash is really just N repetitions of some simpler hash then maybe it is, but e.g. for bcrypt it's not. The work factor controls how much hashing is done to generate a key for a final encryption step, and then the key is thrown away. You can't just "add rounds" to a bcrypt hash, you need to recompute it from the password itself.
    – hobbs
    Commented Aug 29, 2015 at 2:56
14

How does a hacker know how many times a password was hashed? The same way you do.

The goal of hashing a password is to make it impossible (in practice very difficult) to determine the password, even with full access to all the data.

The other requirement for hashing is that the server must be able to determine if an entered password is correct. This means that at some point during the login process, the server must have access to the complete formula for hashing a password.

The purpose of varying the number of hashes is primarily to slow down brute force attacks and increase the search space for rainbow tables, and this works without any secrecy. That's why the number of rounds is typically stored right in the database with the hash, as in SilverlightFox's answer.

There are solutions that store the number of rounds separately and attempt to keep it secret, and that may add an extra layer of protection. But when evaluating the hashing system we have to assume that the attacker knows everything we know.

After all, if there were a place to store the number of rounds that was guaranteed not to be compromised, we could just store the passwords there and not bother with hashing at all.

Improve this answer
7

The number of iterations and the salt are stored in the same database, usually in the same field as the password hash itself. Because the site needs to know those things just as much as a potential attacker does, and so they have to be easily available. For example, bcrypt hashed passwords contain the (log base 2 of the) number of iterations separated by $ signs from the rest of the hash.

Improve this answer
3

While the currently accepted answer is correct and the number of iterations is usually stored where the hashes themselves are, even if this was not the case:

  1. By Kerckhoff's principle, you should assume the attacker can find out. In practice they could find out for example by creating their own login with a known password or timing a login attempt.

  2. Even if the number of iterations was an unknown, it would only add a constant factor to the time required by the attacker to check them all, at least with common password hashing functions such as PBKDF2, where you can derive the 1000-iteration hash from the 999-iteration hash with a single iteration. The attacker would only have to compare the intermediary values to the password hash.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .