truncating passwords instead of rejecting them

[royce]

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.

[philsmd]

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=rul...ulti-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 ).

[royce]

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].

[philsmd]

You can do it, as mentioned above. With multi rule feature:

If you wish you could also use the "multi rule" feature, see https://hashcat.net/wiki/doku.php?id=rul...ulti-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"

[royce]

Awesome - that's *perfect*! That's exactly what I needed to know.

[royce]

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:

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!

[philsmd]

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.