Date: Wed, 19 Apr 2006 16:18:53 +0200 From: "Erastus, Licky" <erastuslr@...ecom.na> To: <john-users@...ts.openwall.com> Subject: RE: specify individual salt to run Can you send me the software Regards LICKY RICHARD ERASTUS DATA/TELEMATICS Tel: (+26461) 2012989 Cell: (+264811) 281015 Fax: (+26461) 258510 Email: erastuslr@...ecom.na Mobile Email: 264811281015@...mobile.com.na Website: www.telecom.na "Why compare yourself with others? No one in the entire world can do a better job of being you than you." -----Original Message----- From: Solar Designer [mailto:solar@...nwall.com] Sent: Wednesday, April 19, 2006 3:54 PM To: john-users@...ts.openwall.com Subject: Re: [john-users] specify individual salt to run On Wed, Apr 19, 2006 at 12:13:45PM +0000, -. -PhanTom-. - wrote: > Was wondering if you would consider adding another command to jtr to let users > specify which salt to run? > So that one could run only the hashes that has a specific salt? > e.g > john --salt2:et ... This had been considered before. There are some good reasons to not implement it: 1. In order to know what salts there are and which ones you want (or don't want) to crack, you have to review the input password files and/or john.pot manually. If you do that, it should not be hard for you to pass your files through grep or the like, eliminating the need for this option to John. 2. The ASCII representation of salts is different for each hash type. Would the documentation need to be complicated with instructions on how to specify salts - e.g., whether to include or omit the "$1$" before FreeBSD-style MD5-based crypt(3) salts? 3. I like to keep the list of command-line options reasonably short. There's also a subtle reason in favor of implementing this: With some hash types, there are multiple ASCII representations which correspond to the same salt value. If you include all hashes with the traditional crypt(3) salt represented as "et", you likely also want to include whatever other hashes might happen to have the same salt value (since they can be processed at no additional cost), even if it is not encoded as "et" (those other encodings are invalid, but nevertheless they are sometimes seen in practice). John can implement logic like that, whereas grep won't do it. On the other hand, someone might be surprised by this effect and even find it undesirable. -- 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.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ