+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Previous versions (https://hashcat.net/forum/forum-29.html)
+--- Forum: Old oclHashcat Support (https://hashcat.net/forum/forum-38.html)
+--- Thread: truncating passwords instead of rejecting them (/thread-3977.html)
truncating passwords instead of rejecting them - royce - 01-14-2015
In this 2011 thread:
http://hashcat.net/forum/thread-698.html
... someone asked about "wordlist clipping" - being able to truncate passwords instead of rejecting them.
The suggestion at the time was to modify all rules to truncate words. Is this still the best answer?
When working large collection of rules, it would be very convenient to not have to maintain separate rule sets for various lengths of password, and keep both truncated and non-truncated rules in sync.
Ideally, it would be great if oclhashcat could recognize the maximum possible word length of the target hash format, and automatically truncate rather than rejecting (unless it results in a duplicate password). This is what JtR does, IIRC.
This would be especially handy for DES crypt.
RE: truncating passwords instead of rejecting them - philsmd - 01-14-2015
see https://hashcat.net/wiki/doku.php?id=rule_based_attack
There is a rule to truncate password candidates:
Truncate @ N 'N Truncate word at position N
If you wish you could also use the "multi rule" feature, see https://hashcat.net/wiki/doku.php?id=rule_based_attack#multi-rules
This allows you to use oclHashcat as follows:
-r my_normal_rule_file.rule -r truncate_at_8.rule
Hence, you don't need to add the "truncation rule" on each line, nor do you need to (quote) "maintain separate rule sets for various lengths"
Truncating instead of rejecting wouldn't make much sense in general (for specific hash types with limit), and keeping track of which (truncated) plains were already checked even less sense (too much memory consumption, not working for plains modified on the GPU by rules etc).
If I am not completely mistaken, whenever the plain was not rejected when loading it, for many hash types who have some limit (maximum password length) the plain will be kind of automatically truncated anyway if it makes it that far (already modified plain, rule etc, loaded on GPU ).
RE: truncating passwords instead of rejecting them - royce - 01-14-2015
For DES crypt, it would be extremely useful to be able to apply existing rulesets that generate passwords longer than eight characters, without modifying them.
DES crypt is a special case because it will ignore all characters after the eight character. Users who do not realize this will have passwords based on longer strings. The password that they are remembering and typing in is actually longer than is allowed. This means that the *psychology* behind why they picked their password can be based on more than 8 characters.
This means that rule sets designed to generate passwords longer than 8 characters can actually have a high rate of success in guessing DES crypt passwords.
For practical/efficiency reasons, I would much prefer telling hashcat to truncate all passwords, rather than modifying every rule in a long list of rules scattered across multiple files to use the 'N syntax. This way, I can use the existing rules for both DES and non-DES passwords without modification.
[Edit: and I forgot to add: agreed that tracking what had been tried would be waaay too much overhead, sorry].
RE: truncating passwords instead of rejecting them - philsmd - 01-14-2015
You can do it, as mentioned above. With multi rule feature:
(01-14-2015, 09:42 PM)philsmd Wrote: If you wish you could also use the "multi rule" feature, see https://hashcat.net/wiki/doku.php?id=rule_based_attack#multi-rules
This allows you to use oclHashcat as follows:
-r my_normal_rule_file.rule -r truncate_at_8.rule
Hence, you don't need to add the "truncation rule" on each line, nor do you need to (quote) "maintain separate rule sets for various lengths"
RE: truncating passwords instead of rejecting them - royce - 01-14-2015
Awesome - that's *perfect*! That's exactly what I needed to know.
RE: truncating passwords instead of rejecting them - royce - 01-14-2015
Hmm, still rejecting 60% of my passwords. I dug around a little more, and found this thread:
http://hashcat.net/forum/thread-3132.html
It turns out that on GPU, using -r to specify a separate truncating rule won't work. This was reported as a bug that has been flagged as a wontfix:
https://hashcat.net/trac/ticket/2
Quoting atom:
Quote:I see what you mean. The problem is that oclHashcat-plus applies the rules on GPU for fast hashes. DEScrypt is a fast hash. But on GPU, there is no way of rejecting a candidate.
What you can do, and I think its a fine solution, is that you use a rule like -j '8 (needs proper escaping on linux). This will truncate all words from your dictionary to length 8 before the are checked by the reject function.
Using -j '8 works for me - no more rejected passwords, so I think that I've found my answer. Thanks!
RE: truncating passwords instead of rejecting them - philsmd - 01-14-2015
there was a different but similar, much more recent problem:
https://hashcat.net/trac/ticket/515
It works here with 1.32 beta which will be released soon, afaik.