La respuesta depende de la "velocidad" del hash de destino:
-
Si es un hash rápido (como MD5), Daisetsu es más o menos correcto: no vale la pena preocuparse por eso (aunque puede variar según el ataque y los objetivos);
-
Si se trata de un hash lento (como bcrypt), las GPU no se privarán de las contraseñas de los candidatos, por lo que puede darse el lujo de generar candidatos externamente (sin GPU) sin ralentizar abajo tu ataque.
Una técnica común para este último es combinar la opción --stdout de hashcat con tu ataque para generar tus candidatos, y luego canalizar el hashcat a otra instancia de hashcat (que hace el cracking real).
Para inyectar requisitos de longitud en esa tubería, hashcat-utils len , la utilidad funciona muy eficientemente. Si hay requisitos de complejidad, las utilidades req de hashcat-utils también son muy eficientes.
Entonces, podrías hacer algo como esto para generar candidatos:
$ hashcat rockyou.txt -r rules/best64.rule --stdout
123456
654321
123456
123456
1234560
1234561
1234562
1234563
1234564
1234565
[snip]
... y luego canalice eso a otro hashcat (por ejemplo, suponiendo un requisito de longitud mínima de 8 y máxima de 11):
hashcat rockyou.txt -r rules/best64.rule --stdout | len 8 11 | hashcat -a 3200 targets.hashes
... pero tenga en cuenta que esto es útil solo para hashes más lentos.
Tenga en cuenta que si el hash es lo suficientemente lento, puede usar cualquier cosa (Perl, shell scripts, crunch, etc.) para hacer lo que sea necesario para generar y seleccionar lo que desee. A medida que la velocidad del hash comience a aumentar, querrá hacer una prueba comparativa de su canalización para asegurarse de que no está muriendo de hambre las GPU (por lo general, deberían mostrar el 100% en la salida de estado de hashcat). hashcat y len son muy rápidos, al igual que las otras herramientas en hashcat-utils , por lo general señala a la gente allí.