[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050622202521.10405.qmail@web25802.mail.ukl.yahoo.com>
Date: Wed, 22 Jun 2005 21:25:21 +0100 (BST)
From: Duro Soft <duro_soft@...oo.co.uk>
To: john-users@...ts.openwall.com
Subject: Re: Secure Mode for John
Hello,
Thanks for your reply, can you compile the software and send it to me let me see how it works.
Regards,
Durodoluwa
Solar Designer <solar@...nwall.com> wrote:
Hi Jim,
On Tue, Jun 21, 2005 at 04:28:29PM -0400, Jim Brown wrote:
> I've used john in an enterprise environment as a strong
> password compliance tool and I've had these concerns:
>
> 1. The passwords are visibly displayed.
> 2. The .pot file contains password data that can be displayed
> by running john at a later time.
These are valid concerns. So far, the way to address them has been to
run John and have it store john.pot in the most secure location.
You need to realize, though, that an attacker with access to the
password hashes would be able to crack all the same passwords in the
same way, albeit after spending quite some processor time on it too.
Whether or not John would store cracked passwords, you do have the
password hashes stored in files anyway.
> 3. john (and a large wordlist) will run forever.
This is not quite true. With most password files, John will complete
even the largest wordlists in a reasonable time. The thing that will
make it "run forever" as you say is the "incremental mode". Yes, you
will need to interrupt that eventually.
> Ideally, all I want to know is if john can crack a password
> for an account in X time. If it can, the account password
> is held insecure and should be changed.
This is a reasonable policy.
It does, however, have one drawback: for salted hashes, the number of
candidate passwords tried against a given password hash in X time varies
heavily based on how many other password hashes (or rather, salts) are
loaded into John during the same run.
> Because of the above concerns, I've had to build a perl wrapper
> around john that reads john output (removing the password),
> continuously deletes the .pot file, and kills john after some
> variable time period.
>
> I'd be interested in hearing others thoughts on a mode for john
> that addresses the concerns- i.e. a 'safe mode'.
>
> * No passwords would be displayed, or stored at all.
> * Only account names would be output (with optional time-to-crack).
Yes, I had a couple of requests for this before (that's like - just 3
requests, including yours, in 9 years).
Yes, this is a reasonable thing to implement. One difficulty with
implementing it is that it would still be desirable to have password
hashes recorded in john.pot (such that interrupted sessions could be
recovered, fully-cracked split password hashes could be distinguished
from partially-cracked ones, and a list of users with fully-cracked
passwords could be output). This would require a john.pot file format
change to encode no-plaintext differently from empty-plaintext.
> * John dies after a configurable time period.
Yes, this is asked for once in a while and it needs to be implemented.
In fact, ancient versions of John had an option to do just that, but I
had dropped it in a code rewrite for 1.5+. I should re-introduce it.
Thanks,
--
Alexander Peslyak
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
---------------------------------
Yahoo! Messenger NEW - crystal clear PC to PCcalling worldwide with voicemail
Content of type "text/html" skipped
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.
