NTLM vs WPA/WPA2 cracking

[philsmd]

by stdin/pipe mode I meant this:

Code:

hashcat --stdout -r rules/rockyou-30000.rule test3.txt | hashcat64.bin -m 2500 test.hccapx

and undeath is of course correct, there are edge cases that are kind of allowed (and can't really be easily detected/enforced). So he basically already told you how to bypass the limitation, by just using a -j "^a^a^a^a^a^a^a^a" rule and striping it off with -r (a rule file containing a [[[[[[[[ rule, note that you can apply multiple -r rule1.rule -r rule2.rule rules files and all the rules from all the files will be combined into concatenated rules)

I see that you are trying to convince me that minimum password length checks are useless/annoying... but in general you won't want to have a password in your outfile/potfile that doesn't respect the password policy and this length filter is most of the times doing a good job that we don't output any wrong passwords that do not respect the min/max password length... of course it can be annoying in some special cases but in most of the cases it makes sense.... (the only problem is that the kernels currently have no way to just skip passwords aka there is no reject rules implemented on the GPU rule engine and therefore the filtering is done "too early" if we use rules)

[undeath]

As I said, an option to skip the check would be nice. Because as you have just demostrated the filter is very crude/imperfect and it can easily cause valid candidates to be skipped. And it does not prevent any "policy" from being violated because the check is not done on the candidates but the input word only.

[magnum]

I agree with undeath, except I would push it further: This should not only be an option, but it should be the very default as soon as GPU-side rules are active. Perhaps accompanied by some warning, if you must. The current behavior is tragicomical IMHO and the reasons you give for keeping it doesn't really make any sense.

Like this: "but in general you won't want to have a password in your outfile/potfile that doesn't respect the password policy". What the heck do you even mean by that!? The only thing that will actually end up in a outfile/potfile is obviously correct passwords (that may have been assembled by a short word and a rule that made it longer).

Just my opinion.

[royce]

With the upcoming -S / --slow-candidates option, it may be that a better approach for this could be possible.

[undeath]

@royce: but that "better approach" would only include -S I suppose. Given that WPA, on faster hardware, will be throttled by this it's hardly a proper solution.

[royce]

Fair. I'm a little over my head here, but it does sound as though the length enforcement is happening in the wrong place for slow hashes.

[atom]

The -S will be fast enough for WPA, but maybe not for md5crypt.

[john2014]

I posted this yesterday (https://hashcat.net/forum/thread-7815.html) and was told that my "observation" is due to the minimum 8 char WPA limitation.
I am reading now this thread in disbelief!

First, to make things clear so that nobody misunderstands me, my HUGE respect and THANK YOU goes to atom and all the developers for this project.
Having said that, why are you still discussing this? Just make a new mode (like "2502") in which input minimum of less than 8 characters is allowed. Let us bear the cost of getting in the pot file wrong results. But if just 1 correct password is found then I dont mind the wrong result (s). You cant imagine how many times I have come across WPA passwords that are short and consist of silly word combinations.
Hashcat, as-is right now, fails to find any of them!! Do you realize that the filter cuts anything less than 8 chars?
Do you realize that combining 2 wordlists with acceptable words would result in minimum 16 characters?
I mean, come on!
And having to perform all shorts of workarounds for just a simple thing?
Passcape's product finds my test hash in milliseconds; hashcat fails miserably for something which is silly!
Please please please, rethink about it and give us a solution!

[magnum]

There wont be any false positives, I have no idea where you got that from. So a new mode isn't called for. Hopefully that new -S option will solve the problem.

[john2014]

Excuse my ignorance but what does the upcoming "-S" option stand for?
I googled and found this:

"Add new option --slow-candidates which allows hashcat to generate passwords on-host"

What exactly will it do?