I'm playing around with Hydra and an xmpp authentication.
I created a basic xmpp server of my own, reproducing an authentication (server side) from a clear text pcap file. I think I got something wrong in my connections handling (I'm creating one thread per new connection but I close it on error) but nevermind, this is not my point.
I fixed this scalability problem. For those interested, it was due to an optimization from Hydra, not replaying the first, let's call it "Hello request". A regular authentication needs 4 requests or responses from a client, 4 packets from the server too. And this optimization skips the first, going straight to the 2nd, that looks like that in my case :
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1'/>
Stats / Info :
- Conf of the VM : 2 CPU, 2 GB RAM.
- Password location in the wordlist : 795th position out of 60k.
- Single task : ~50 tries / min -> ~17min to find the password.
- 16 tasks : ~820 tries / min -> 1h14min to complete without finding the pw ('cause of the connections handling problem).
New stats (after optimization) :
- Single task : ~90 tries / min -> 9min 13s
- 16 tasks : ~1400+ tries / min -> 33s
The question is: is Hydra splitting the wordlist into 16 equal parts? And how?
One part size is ~3.8k passwords. Is the thread 1 working on the first 3.8k passwords? The thread 2 working on the 3801rst -> 7600 ? and so on till thread 16? So that the last 16 tested passwords would be the 3799th, 7599th and so on?
The other possibility is that the thread 1 for example proceeds every 1%16 (modulo) password from the wordlist, so that the passwords are tested in the same order than if we had only 1 task (/ thread) running.
I can test it myself but if someone already did, please enlighten my darkness.