Date: Thu, 19 Jun 2008 00:12:50 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: interpretation of results On Wed, Jun 18, 2008 at 09:00:01AM +1200, Russell Fulton wrote: > I have been running a bunch of UNIX DES hashes and have one cracked: > > [rful011@...an-desktop .jtr]$ john --show unix.pass > root::14007::56:::: OK. BTW, this is not relevant to your question, but you should run JtR against combined passwd and shadow files (use the included "unshadow" program/symlink), not just against the shadow file. This makes a difference for the "single crack" mode. I understand that you might have run it against the shadow file above in order to not reveal irrelevant info in your posting. ;-) > I don't think the password is null (there is a hash for it) or is > there a distinction between no password and a null one (which makes > sense)? The issue is that some systems, in some cases, will in fact generate hashes of empty strings instead of leaving the passwd or shadow file field empty. This does not make much sense as intended behavior, but it sort of makes sense as a somewhat common peculiarity. The systems might or might not treat such cases equally when authenticating users (e.g., as it relates to possible "permit empty passwords" settings). > It was cracked at the start of the incremental run so it is clearly > something short ? That's right. The "Incremental:All" mode will in fact try zero-length (empty) candidate passwords: # Incremental modes [Incremental:All] File = $JOHN/all.chr MinLen = 0 MaxLen = 8 CharCount = 95 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.