Return to Answer

This would usually only be a mild, temporary barrier to cracking.

Leaving off the number of rounds would be a thin layer of obscurity. The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. So that software could simply be reverse-engineered to discover the number of rounds.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

This means that the easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. (Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.)

That being said, there's usually a practical upper limit to the number of rounds - beyond which it would take too long for interactive users to tolerate waiting for their password to be verified. 100,000 rounds would be pretty unusual, but not impossible. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable. So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker.

So if an attack on rounds from 1 to 50,000 didn't yield any results in a day or two, I'd be inclined to think that it's a different hash type - and would probably be trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it.

This would usually only be a mild, temporary barrier to cracking.

Leaving off the number of rounds would be a thin layer of obscurity. The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. So that software could simply be reverse-engineered to discover the number of rounds.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

This means that the easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. (Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.)

That being said, there's usually a practical upper limit to the number of rounds - beyond which it would take too long for interactive users to tolerate waiting for their password to be verified. 100,000 rounds would be pretty unusual, but not impossible. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable. So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker. And since PBKDF2 is a pretty slow hash, if we assume that the defender picked a pretty high number of rounds, this approach might actually make things harder.

So if an attack on rounds from 1 to 50,000, using common wordlists and attacks, didn't yield any results in a day or two ... I'd be inclined to start to think that it might be different hash type - and would probably also trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it. Actually, I'd probably do that anyway why I was waiting for the cracking job to finish. :)

This would usually only be a mild, temporary barrier to cracking.

The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. That software could be reverse-engineered to discover the rounds. Leaving off the number of rounds would be a thin layer of obscurity.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

The easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.

That being said, there's usually a practical upper limit to the number of rounds (beyond which it would take too long for users to tolerate waiting for their password to be verified). 100,000 rounds would be pretty unusual. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable.

  So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker. But if an attack on rounds from 1 to 50,000 didn't yield any results in a day or two, I'd be inclined to think that it's a different hash type - and would probably be trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it.

How confident are you that that is the hash type? No well-known application omits rounds in this way (that I'm aware of). Did the number of rounds accidentally get truncated during collection of the hash? Otherwise, it would be pretty unusual for a developer do this. It would have to be a local/custom application - and a very naive one at that.

This would usually only be a mild, temporary barrier to cracking.

Leaving off the number of rounds would be a thin layer of obscurity. The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. So that software could simply be reverse-engineered to discover the number of rounds.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

This means that the easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. (Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.)

That being said, there's usually a practical upper limit to the number of rounds - beyond which it would take too long for interactive users to tolerate waiting for their password to be verified. 100,000 rounds would be pretty unusual, but not impossible. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable. So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker.

So if an attack on rounds from 1 to 50,000 didn't yield any results in a day or two, I'd be inclined to think that it's a different hash type - and would probably be trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it.

This would only be a mild, temporary barrier to cracking. The only way such a hash would even be useful would be if the application checking the hashes had a hard-coded or algorithmic way to determine the number of rounds. If so, that software could be inspected and/or reverse-engineered and the number of rounds could be extracted and applied - so leaving off the number of rounds wouldn't provide much protection.

Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

The easiest workaround is to simply generate each hash:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software.

How confident are you that that is the hash type? Did the number of rounds accidentally get truncated during collection of the hash? Otherwise, it would be pretty unusual for a developer do this. It would have to be a local/custom application - and a very naive one at that.

No well-known application omits rounds in this way (that I'm aware of).

This would usually only be a mild, temporary barrier to cracking. 

The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. That software could be reverse-engineered to discover the rounds. Leaving off the number of rounds would be a thin layer of obscurity.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

The easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.

That being said, there's usually a practical upper limit to the number of rounds (beyond which it would take too long for users to tolerate waiting for their password to be verified). 100,000 rounds would be pretty unusual. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable.

So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker. But if an attack on rounds from 1 to 50,000 didn't yield any results in a day or two, I'd be inclined to think that it's a different hash type - and would probably be trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it.

How confident are you that that is the hash type? No well-known application omits rounds in this way (that I'm aware of). Did the number of rounds accidentally get truncated during collection of the hash? Otherwise, it would be pretty unusual for a developer do this. It would have to be a local/custom application - and a very naive one at that.