[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 17 Oct 2008 03:27:18 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: LDAP "{CRYPT}" hash encoding (was: OpenLDAP MD5/SMD5 format challenges)
On Mon, Oct 13, 2008 at 01:45:57PM +0200, Simon Marechal wrote:
> I recently had a discussion about this issue. MD5 is just to be
> base64 decoded and hex-encoded for it to be loaded with raw-md5. I suppose
> it should be the same for {CRYPT}. SMD5 might require code to be actually
> written.
It's not the same for "{CRYPT}" - that string is followed by the usual
crypt(3) return value, without having it base64 encoded. This is seen
in RFC 2307 as it relates to the traditional 13-character crypt(3)
hash encodings, but in practice the same convention is also used for
modern crypt(3) hash types and encodings.
Maybe support for the "{CRYPT}" prefix should be added to all "formats"
in JtR that deal with hashes produced by crypt(3) on various systems.
Such support may amount to recognizing and skipping the prefix in
valid() and removing it in split(). That way, if the same hash occurs
both with and without the prefix (perhaps in different input files), it
won't be loaded/cracked for a second time - instead, the old john.pot
entry, if any, will be reported on "--show".
On the other hand, hash encodings with this prefix are normally not
seen in /etc/passwd-like files, so the input file to JtR would need to
be a result of conversion of another file anyway. Stripping off the
prefix may be performed during such conversion.
Alexander
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
