[<prev] [next>] [day] [month] [year] [list]
Message-ID: <3BE48DD0EC7D3948BC183931D9150C2106D232F5@ii0015exch001u.iprc.lucent.com>
Date: Thu, 20 Jul 2006 18:35:47 +0530
From: "V, Bharath (Bharath)" <bharathv@...ent.com>
To: "'john-users@...ts.openwall.com'" <john-users@...ts.openwall.com>
Subject: RE: Unable to crack passwords
Thanks for your help....
i am able to use JTR successfully
-Bharath
-----Original Message-----
From: Solar Designer [mailto:solar@...nwall.com]
Sent: Wednesday, July 19, 2006 8:36 PM
To: john-users@...ts.openwall.com
Subject: Re: [john-users] Unable to crack passwords
On Wed, Jul 19, 2006 at 08:13:15PM +0530, V, Bharath (Bharath) wrote:
> For our application we have several user logins we want to validate the
> passwords using the JTR tool.
> I have the user names and passwords(in plain text) of all the users in a
> text file, i just wanted to know whether the passwords are crackable thru
> JTR or not.
Oh, that's fine. (Although you could also want to not continue storing
those passwords in plain text.)
> Is there any way i can accomplish this?
Yes:
> Should i have to encrypt the password before giving it as input to the
> JTR tool?
Yes, except that this is called "hashing", not "encryption". You do
need to hash your passwords with one of the hashing methods that JtR
supports. Plain Blowfish is not it - as I have explained, it is a block
cipher that is normally used for encryption, not hashing. bcrypt, with
its crypt_blowfish implementation, found at the URL that I had provided,
is one of the supported hashing method. However, it is a rather good
one (slow and salted), which might make your passwords appear to be
much stronger (harder for JtR to crack) than they would be in a real
attack scenario against your application.
Alternatively, you might choose to not pass your passwords as input to
JtR at all. Instead, you'd have JtR output the candidate passwords that
it would normally try (the "--stdout" option does that). Then you would
use a program of your own (e.g., a Perl script) to compare those
candidate passwords from JtR against all of your known plaintext
passwords.
And there's yet another alternative - enhance JtR to support "cracking"
of plaintext passwords. I can implement this provided that your company
would compensate for my time.
Of course, the point of checking whether passwords are strong when
you're storing them in plain text is moot. I'd need more information on
your application to provide a proper assessment on whether this makes
sense and to recommend a course of action (e.g., enhance the application
in such-and-such ways). Please contact me via private e-mail if you're
interested.
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
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
--
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.
