Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 May 2012 20:53:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Additions to JtR rules, arbitrary characters

On 05/20/2012 08:16 PM, Frank Dittrich wrote:
> I also noticed that appending a newline character cracked several
> raw-md5 hashes from
> https://www.korelogic.com/InfoSecSouthwest2012_Ripe_Hashes.html
> (...)
> Cracking these hashes with such an external mode or with a rule $\x10
> and your patched rpp.c works.
> However, john.pot will also contain these newline characters.
> This results in john --show reporting wrong cracked passwords, unique
> removing "duplicate" empty lines, and so on.
> 
> I'm not sure how much effort should be spent supporting such faked hashes.
> Can/should we try to add new options/values to john --show and/or unique?
> Or is this just not worth the effort, because these passwords will never
> be needed to crack real password hashes?

We could use literal '\n' and '\r' for a couple of such offenders. But
then we'd have to use '\\' for an actual '\' and this could break things.

FWIW, I have sometimes wanted another field in john.pot, a hex of the
plaintext like this:

$NT$3dbde697d71690a769204beb12283678:123:313233

I think some other crackers has this. If we had this in place, we could
print '?' (or something else) for linefeeds or otherwise unprintable
characters. But this would break lots of things so it would have to be
optional.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ