![]() |
Using hashcat Brain with slow hash and specific password length - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: Using hashcat Brain with slow hash and specific password length (/thread-8884.html) |
Using hashcat Brain with slow hash and specific password length - Toetje - 01-14-2020 I am trying to attack a slow hash which I know has a length of 12 or more characters. Since I want to use a rule based attack I am wondering how I can easily limit the amount of password candidates for cracking combined with the hashcat brain. If I use the example wordlist: Code: 123456789abcd combined with the example ruleset: Code: : My desired output would be: Code: 123456789abcd Thereby skipping: Code: 123456789ab When using an inline filter, it seems to only look at the length of the word before rules are applied: Code: hashcat64.bin -a 0 example.dic -r example.rule -j '>C' --stdout This way I will miss the password 123456781234 while it will try the 11 character password 123456789ab. I can pipe the output from hashcat to hashcat to remedy this: Code: hashcat64.bin -a 0 example.dic -r example.rule —session output --stdout | hashcat64.bin -j '>C' --stdout This works fine (especially because it is a slow hash), however I want to use the hashcat brain which does not accept stdin mode. So this leaves me with 4 undesirable options: -Don’t use hashcat brain -Accept a large set of password candidates are just a waste of computational power since they will never find the correct password -Create a (insanely large) dictionary file from all password candidates generated by the wordlist and rule that are 12 characters or longer and then start the attack. -Create a (insanely large) dictionary file from all password candidates generated by the wordlist and rule that are 11 characters or shorter and feed this file to the hashcat brain with a faster hash, afterwards running the normal attack with brain active. Am I skipping a nice feature of hashcat that I am unaware of and would solve my problem, or is there no better solution than already mentioned above? RE: Using hashcat Brain with slow hash and specific password length - philsmd - 01-14-2020 if you have a minimum required length of 12 and rules that add up to 4 characters, you could just pre-process your dict such that it has at least 12-4 = 8 characters. That's already a huge filter and probably already good enough (to still have maximum speed etc). of course it depends a lot on the hash type and cost factor (you didn't mention it), but since you are using brain I assume something like bcrypt/scrypt with a high cost factor: Code: awk 'length > 7' example.dic > example_filtered.dic the truncate rule of course might produce some "wrong" results, but depending on how many rules you have etc it might be negligible... sometimes users over-think and over-estimated the filters and at the end only much less than e.g. 1% of the password candidates are filtered out etc and that would be negligible RE: Using hashcat Brain with slow hash and specific password length - Toetje - 01-15-2020 Thanks for the suggestions. I didn't mention my hashtype because I didn't think it would be relevant, but just for completeness, it is indeed bcrypt. ![]() My problem is that my custom rules are aimed at increasing the length of the original passwords in different ways so I can use a simple wordlist like the rockyou set and still get interesting passwords. With this combination I can't filter out too many original passwords and the amount of incorrect passwords is a lot higher than 1%: Initial password length 1 = 61% incorrect passwords generated with ruleset. Initial password length 2 = 51% incorrect passwords generated with ruleset. Initial password length 3 = 42% incorrect passwords generated with ruleset. Initial password length 4 = 34% incorrect passwords generated with ruleset. Initial password length 5 = 27% incorrect passwords generated with ruleset. Initial password length 6 = 20% incorrect passwords generated with ruleset. Initial password length 7 = 14% incorrect passwords generated with ruleset. Initial password length 8 = 10% incorrect passwords generated with ruleset. Initial password length 9 = 6% incorrect passwords generated with ruleset. Initial password length 10 = 2% incorrect passwords generated with ruleset. Initial password length 11 = 0,5% incorrect passwords generated with ruleset. Initial password length 12 = 0% incorrect passwords generated with ruleset. Granted, my ruleset is tailored for fast hashes, so I am going to rebuild and optimise it for bcrypt, but my problem stays the same. I could choose to use initial passwords of a length of 9 or larger since the incorrect password loss would be less than 7% which is acceptable for me. Your advise suggests there is no option inside hashcat to solve this problem, so I think I'll stick with my workarounds or try a password length of 9 and higher. Thanks again for the suggestion. RE: Using hashcat Brain with slow hash and specific password length - philsmd - 01-15-2020 in theory we could enable the rule engine used by -j and -k also for --slow-candidates (-S) which is enabled by default in case brain is used. This would also allow reject rules etc (everything that is supported by -j/-k) but allow multiple rules (like with -r). This feature of course is currently not implemented, but might be doable... I think if it is not too confusing for the user we could just make -r act differently and allow "more-rules" (like in -j/-k) with -S, but also several rules (like normally used with -r). You could probably try to request it here: https://github.com/hashcat/hashcat/issues , not gonna lie, this might also be interesting for other users (I just hope it's not too confusing that -r acts differently with brain or -S, but that little inconsistency might be acceptable for the nice feature). RE: Using hashcat Brain with slow hash and specific password length - Toetje - 01-15-2020 Thanks for your response. I opened an Issue at github, but am a total git noob so I hope I did it correct: https://github.com/hashcat/hashcat/issues/2284 |