I'm with everyone else - if you, with your tiny resources and limited patience, can find any passwords, then the attacker with a few (friends with) PC's with 8 Radeon R290X's each, who decides to spend a month or two on just your password file, and who is much, much more experienced than you, with better wordlists and rulesets, is definitely going to find them.
If you really insist on ranking by weakness, then do attacks in sequence, smallest exhaustive keyspace first. For instance (keyspaces are rough estimates, NOT precision calculations):
- Rules-based exhaustive dictionary attack with the tiny phpbb dictionary of 184389 words and the Best64 ruleset is 1E7
- Markov/brute force exhaustive of 8 character passwords of all digits are 1E8
- Mask attack of the tiny phpbb dictionary of 184389 words with a suffix of all numbers between 0 and 999, both with and without a trailing !, is 3E8
- Rules-based exhaustive dictionary attack with the tiny phpbb dictionary and the excellent d3ead0ne ruleset of 35404 rules is 6E9
- Markov/brute force exhaustive of 8 character passwords of 5 lower case characters but always ending with 123 are 26^5, or 8E9
- Markov/brute force exhaustive of 8 character passwords of 8 lower/numeric characters is 2E12
- Rules-based exhaustive dictionary attack with the InsidePro Full dictionary of 154045162 words and the excellent d3ead0ne ruleset of 35404 rules is 5E12
- ....
- Markov/brute force exhaustive of 8 character passwords of 8 lower/upper/numeric characters is 2E14
- ....
- Rules-based combinator exhaustive attack of the tiny phpbb dictionary of 184389 words crossed with InsidePro Full and then applying the InsidePro Full dictionary of 154045162 words and the excellent d3ead0ne ruleset of 35404 rules is 1E18
- Again, if ANY of these find a password, it's weak.
- There are nearly infinite variants within this, of course, but I find it useful to run the fastest attacks first, so that on per-user salted passwords, the more expensive attacks are used against the fewest possible hashes
- I.e. run a 1E8 attack first, and remove all the hashes that it finds from the list. Then do your 3E8 attack, remove those, and move up, so you don't try a 1E14 attack on a password that could have been removed with orders of magnitude less work.
I was wondering whether JtR is a good solution to test password strength. I'm not interested in actually finding the passwords (I'd rather not in fact)
John the Ripper is a good tool, but it is not always the best tool.
Currently, for many hashes, oclHashcat is the best free tool I'm aware of, and the option to hide found passwords is a combination of
- --disable-potfile
- --outfile-format=NUM
i.e. add to your command line
--outfile-format=1 --disable-potfile
I usually pull in the result file
On the paid side, Elcomsoft has a wide variety of tools available; to cite one example, their Proactive Password Auditor, at least, has an option to hide found passwords.
In either case, budget at least one GPU of whatever type is best for the software you choose.
In any case, learn the various modes - pure Markov mode/brute force for limited character sets (including some keywalking sets), and then very quickly graduate to rules based dictionary attacks. Make dictionaries including common words at your company, phone numbers, addresses, the phone list, etc. and add that to common dictionaries like online Scrabble word lists, phpbb, insidepro, rockyou, crackstation, clearmoon247, or myslowtech.
If you need a dictionary with a clear license, while it's not good for cracking, the English Open Word List license is:
UK Advanced Cryptics Dictionary Licensing Information:
Copyright © J Ross Beresford 1993-1999. All Rights Reserved. The following restriction is placed on the use of this publication: if the UK Advanced Cryptics Dictionary is used in a software package or redistributed in any form, the copyright notice must be prominently displayed and the text of this document must be included verbatim.
There are no other restrictions: I would like to see the list distributed as widely as possible.
