Date: Tue, 5 Jul 2011 21:39:46 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-users@...ts.openwall.com Subject: Re: Charset options Hi Maximilian, some remarks in addition to what JimF already mentioned... Am 05.07.2011 10:40, schrieb Maximilian Melcher: > Hi list, > > I have a small question: Is it possible to modify a charset like > rockyou.chr > to stick to a password policy? E.g. password must be 8 characters long and > must contain at least 1 letter (all upper or lower), 1 digit and 1 special > sign ? > One general reason not to skip passwords which do not match the current password policy is that there might be older hashes which have been created prior to the latest policy changes. Even if it would be a good idea to skip passwords not matching the policy, you can't generate a .chr file which will produce only passwords matching your policy. The reason is that the .chr file contains trigraph, bigraph, and single letter frequency information for each password length and letter position. Even if you build your .chr file from passwords matching your policy, like "secret+1" and "s*cret01", john's incremental mode will very soon generate a password like "secret01" not matching your policy, because for a password of length 8, position 7, '0' is a very likely candidate if the letters at positions 5 an 6 are 'e' and 't'. You might take care of a password policy with the rules you apply in wordlist mode. If your word list just contains words consisting of letters, you can make sure your mangling rules will generate words containing at least one special character and one digit. > 1. I experience a huge performance inpact (~20%). The huge performance impact suggests you are cracking saltless hashes, with a very fast password algorithm. Together with > 2. John still tells me "Warning: mixed-case charset, but the current hash > type is case-insensitive; some candidate passwords may be unnecessarily > tried more than once." this suggests LM, so JimF is probably right. For LM hashes, it would be totally wrong to filter password candidates according to your password policy. Not just due to the performance impact, but because of how LM works. Imagine passwords like !2secret mysecre7$ LM passwords longer than 7 characters can be cut into two halves which can (and will) be cracked separately. That means, for the above-mentioned passwords, john has to try these "words", to crack the first and second halves: !2secre t mysecre 7$ or (upper case) !2SECRE T MYSECRE 7$ The file john.pot will contain these cracked halves, you'll have to use the --show option to see the complete passwords. When cracking LM hashes, john will cut any password candidate to length 7 and convert it to upper case. So, if you filter the input based on your policy, you'll end up with just the first half of the first password being cracked. Even if you don't crack LM passwords, similar problems might occur. You should mention the hash type if you want to get advice matching your problem. Best regards Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.