I’ve been cracking passwords for a while and use a myriad of tools in a certain order to get the job done. I find that Cain is still my Go-to for allowing me to visualize the process and do some basic sorting (really wish I could search in-app). But I’ve been asking around on twitter some questions like Why is GPU cracking for 50k hashes faster than Rainbow Tables (most say the bottleneck is the HDD read style and speed) and many asked what all of my compalints are so I figured this would be the best place (vice multiple emails)

DISCLAIMER: I have very little crypto knowledge and even less GPU programming knowledge so I only get to complain as a user and not as someone who can actually fix the things I complain about.

1. Lack of LM support. I get that this is a complicated hashing algorithm, but the fact that 90% of companies still have it turned on and cracking any more than a few with Rainbow Tables is impractical unless you have a SSD raid with a GPU based cracker ($$$$$).
2. Lack of dictionary support. Right now the best way to crack passwords is with oclhashcat-plus since it is GPU based and supports rules, multiple hashes (hash files) and directories of hashes. However, it has a very limited list of hashes it supports (No LM, SHA1, etc..) and it doesn’t support dump formats, so you need to strip the file so it just has the hash (this is more of just a bother than a gripe).
   • I say ‘The best way’ because anything that has a key space larger than upper-alpha-numeric-32symbol (LM) is just a bit nuts to try and brute force out of the gate unless your goal is to ‘crack them all’. Me as a pentester, I want to get as many as possible, as quick as possible, so this means dictionaries are the smarter option. (Maybe later I can do the straight brute if I really need / want to)
3. Lack of POT. For some reason every cracking app on the planet, save for JtR, thinks it’s a good idea to crack the same hash multiple times. I wish even Cain would keep a secret store of all the hashes it’s cracked stripped of anything unimportant (need the salt (username) sometimes) and store it in the background so that if it comes across the same hash it can say “oo oo I know this one” and auto populate it even before I start cracking. Why more cracking software writers don’t do this I’ll never know (would make their software seem a ton faster the more it is used)
4. Lack of formatting documentation (#ripshairout). Rare is the time I’ve found a cracking program that shows you how it wants to consume a hash. JtR is the most egregious offenders of this but they all do it. One would think people would try and make it easy for people to use their software (give examples of what shit is supposed to look like at least if you don’t support standard formats)

Those are my biggest gripes that the moment. If I am wrong on any account, let me know, I would love to know of a better way to do things.