Date: Wed, 22 Jun 2005 22:11:12 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Secure Mode for John 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 <solar at openwall.com> 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
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.