La risposta dipende dalla "velocità" dell'hash target:
-
Se è un hash veloce (come MD5), Daisetsu è approssimativamente corretto - che non vale la pena di preoccuparsene (anche se può variare in base a attacchi e obiettivi);
-
Se è un hash lento (come bcrypt), le GPU non saranno affamate di password candidate, quindi avrai il lusso di generare candidati all'esterno (fuori GPU) senza rallentare giù il tuo attacco.
Una tecnica comune per quest'ultimo consiste nel combinare l'opzione --stdout di hashcat con il tuo attacco per generare i tuoi candidati, quindi convogliare hashcat in un'altra istanza di hashcat (che fa il crack effettivo).
Per iniettare requisiti di lunghezza in quella pipeline, l'utility hashcat-utils len funziona proprio così in modo efficiente. Se ci sono dei requisiti di complessità, anche le utility req di hashcat-utils sono molto efficienti.
Quindi potresti fare qualcosa di simile per generare i candidati:
$ hashcat rockyou.txt -r rules/best64.rule --stdout
123456
654321
123456
123456
1234560
1234561
1234562
1234563
1234564
1234565
[snip]
... e poi collegarlo a un altro hashcat (ad esempio, assumendo un requisito di lunghezza minima di 8 e massimo di 11):
hashcat rockyou.txt -r rules/best64.rule --stdout | len 8 11 | hashcat -a 3200 targets.hashes
... ma tieni presente che questo è utile solo per gli hash più lenti.
Nota che se l'hash è abbastanza lento, puoi usare qualsiasi cosa (Perl, script di shell, crunch, ecc.) per fare qualsiasi cosa voglia generare e setacciare. Man mano che la velocità dell'hash inizia ad aumentare, ti consigliamo di eseguire il benchmarking della tua pipeline per assicurarti di non affamare le GPU (in genere dovrebbero mostrare il 100% nell'output dello stato di hashcat). hashcat e len sono molto veloci, così come gli altri strumenti in hashcat-utils , quindi di solito indirizzare le persone lì.