Unknown round length makes hash uncrackable?

Question

So I am on an engagement and grabbed some hashes but cracking them has come to no avail. I believe I know the hash type (PBKDF2-HMAC-SHA256) but I am not sure what round size they used. This got me thinking doesn't this make it impossible to crack or am I missing something. Because even if say you knew the plain text password and salt (obviously a very contrived scenario) you'd still need to try every round size until you found the one they used.

Is this thinking correct or am I missing something?

EDIT: This is important info looking back and I apologize for the confusions about the rounds being missing. The application returns hashes in two different parts of a JSON object. {...,"Password":"(Base64encoded(27 characters))","PasswordSalt":"(Base64encoded(24 characters))",...}. Which is why the hashes do not include a rounds identifier.

So PBKDF2-HMAC-SHA256 came from how they store passwords in a different part of the application and it was all I could find through OSINT. Looking at the password lengths and playing around with Python passlib it seems the passwords are stored as pbkdf2_sha1. I can make sure I'm right but looping through all the rounds and seeing if any come out to the password that I have. It will still take a while since, as the community has said, 100,000 rounds isn't unheard of and sadly they aren't using the default of 29,000.

EDIT EDIT: Just ran my known password against its hash through all rounds 1-100,000 and didn't get a hit. Seems my intuition about it being Sha1 were wrong. Trying SHA-256 now with the same approach.

EDIT EDIT: Well my hope is quickly depleting. I've tried SHA_1,256,and 512 all from 1 to 100,000 rounds and none of them match my hash. The hash lengths and values seem to match perfectly with the description but experiments are seeming to prove different.

I know this isn't really a programming forum but for completeness here is the code I was using to check my hash against all the generated ones.

import concurrent.futures
global quit
from passlib.hash import pbkdf2_sha512
quit = False

def hasher(round, quit):
    if(not quit):
        hash = pbkdf2_sha512.using(salt=(passlib.utils.binary.ab64_decode('xpN14Zl95QQNOKffgsERSw==')), rounds=round).hash('Password').split('$')[-1]
    if(hash[0:5] == '278Vu'):
        print(round) #found it
        quit = True
    if(round % 5000 == 0):
        print(round) #status update


exec = concurrent.futures.ThreadPoolExecutor(max_workers=4)
print("Execing")
for i in range(1,100001):
    exec.submit(hasher,i, quit)

EDIT EDIT EDIT: Seems the hash identifier tool here https://github.com/psypanda/hashID has labeled them as Peoplesoft passwords. I am not sure if this is a false positive because the application doesn't seem to use peoplesoft anywhere. Also It seems Peoplesoft hashes are not salted and mine returns a salt. There is one post on the matter here, https://hashcat.net/forum/thread-6639.html but it is vague. Any help in this regard?

Answer 1

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. :)