Rejecting candidates under X characters while using rules set?

[BeanBagKing]

I have a situation where I know that user stored passwords are at least 15 characters long. However, it's possible that a non-standard user (admin, etc.) or an extremely legacy account (before min limits were put in place) could have created a "user" account with a password less than 15 characters. For political/organizational/layer 8 reasons, I want to make sure I only audit the system for these passwords (that is to say, those of length 1 to 14). This is a fast hash (call it MD4 ) .

Up to 8 characters is easy, I can mask attack with "-i ?a?a?a?a?a?a?a?a" and get everything. Past that and I run into the obvious issue of how long the attack will take.

Option #1 is to get intelligent about my mask attack, ?u?l?l?l?l?l?l?l?d for example. I might miss some things, but it's better than nothing.

Option #2 is to generate a dictionary and cut out everything that is less than 8 characters (I've already found those) or greater than 14 characters (I don't want to crack these!). Works fine with reasonably sized word lists, and combined with the above should find most things.

Option #3 is what I would like to do, use a dictionary and rules list, but reject every candidate in the results that is greater than 14 characters. Basically, what this person is asking for. I completely understand the answer given by Royce, it's not worth the trouble from a time perspective to reject these. However, in my case it's desired for other reasons.

I can pipe candidates through len, as was suggested by Royce, but I'm obviously losing a lot of speed with fast hashes. Reject rules only work on the wordlist itself or with hashcat-legacy.

Are there any other options for me? I understand what I want to do is atypical and I probably won't find anything that will operate at full speed, I'm fine with that. Basically, I just asking what my best option is at this point, or if there's something else I haven't thought of.

[undeath]

Use -O which will reject all candidates longer than 15 characters. Using other mechanisms to reject candidates will likely slow down the attack more than just trying them anyway. Afterwards you can still filter out the ones you didn't intend to crack.

[royce]

Yeah, I see the Layer-8 use case. You need to be able to assure people that you're not cracking passwords that are 15 chars or longer.

There's no way I know of within hashcat itself to guarantee that - other than by using a mode with precise control over the length of the candidate itself (masks rather than rules).

In other words, the problem is that, the way that hashcat is designed, you can't tell which ones are 15 chars until after you've cracked them. Checking candidates for length has too high a speed penalty.

Since you'd (understandably) like to maximize efficiency, -S is out. So the only workaround that I know of - to discard founds that are 15 chars or higher - would be crude, and external to hashcat. I haven't tried it myself, but theoretically, you could disable the potfile, and then use outfiles to send to a named pipe that filtered out all founds that are too large, and only write the shorter ones to disk. Like I said, it would be pretty crude but might work.

[royce]

Hmm, I wonder how hard it would be to modify hashcat to use -O to reject longer than 14 instead of 15.

[BeanBagKing]

Thanks, I appreciate the feedback from both of you. I realize there isn't much of a practical difference between cracking the password, discarding if it's over 14, and then writing to disk. However, it would make people much more comfortable if there wasn't that possibility to begin with.

> In other words, the problem is that, the way that hashcat is designed, you can't tell which ones are 15 chars until after you've cracked them. Checking candidates for length has too high a speed penalty

Pretty much what I figured. While piping through len isn't ideal, I think it's still more than fast enough to find the remaining weak credentials that fall in that space.

[aprizm]

well technically they are encoding the password candidate first so yeah we know the length before its even cracked.

theres a rule that might help you :

Rules used to reject plains
Name Function Description Example Rule Note
Reject less <N Reject plains if their length is greater than N <G *
Reject greater >N Reject plains if their length is less or equal to N >8 *

https://hashcat.net/wiki/doku.php?id=rule_based_attack