[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130102224843.GA25507@16s.us>
Date: Wed, 2 Jan 2013 17:48:43 -0500
From: Brad Tilley <rbt@....us>
To: john-users@...ts.openwall.com
Subject: Re: Multiple formats accepting the same raw hashes
> So, at the end of a long mail, finally a few questions:
>
> How important is it for you that john mentions which supported hash
> algorithms might be used to crack a given set of hashes, instead of
> silently using the first hash format which supported raw hashes of a
> particular fixed length?
I think this depends on the experience and understanding of end-users. Ideally, end-users should know what type of hashes they are trying to crack and they would not mix different types of hashes together in the same file. Is that too much to ask? In my mind, the only logical reason for putting different hashes into the same file is because they are from the same client or are somehow related. The better approach to maintaining that relationship would be to have a folder named, "ClientX" and a separate hash file for Active Directory, LDAP, SHA512Crypt, etc. stored within that folder.
When one looks at a raw MD5 hash or a raw MD4 hash or a NTLM hash, there is nothing to distinguish them from each other. They are all 128 bits (16 bytes).32 bytes hex encoded. The end user would need to provide some context about the hashes in order to successfully crack them, and I think the --format option that JtR currently provides allows for that.
Here is my opinion and answer to this question:
1. Silently use the first hash format that matches - incorrect
2. Use the first match, and also mention all the other formats that match - incorrect
3. When there are multiple matching formats, JtR should stop and ask the user to specify one - correct
Now, should the end-user opt for --format=raw_md5 and the hashes are 160 bits, then we have the issue of the user being wrong, not JtR being wrong because it assumed that the hash was X when in fact it was Y. Programs should be wrong less often than users. If the program does not know exactly what the input is, don't guess or pick the first match and be wrong, stop and ask the user. If the user selects the wrong format (160 bit MD5 hashes) then JtR should stop and explain that MD5 hashes have 128 bits, the hashes specified have 160, please try another format.
Helping the user can only go so far. They can always shoot themselves in the foot (--format=nt on a bunch of raw_md5 hashes), and there's nothing JtR can do to prevent them from doing that.
Just my personal opinion.
Brad
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.
