Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2017 16:19:50 +0100
From: Patrick Proniewski <p+password@...atpro.net>
To: john-users@...ts.openwall.com
Subject: Re: to Single or not to Single

On 02 févr. 2017, at 16:00, Rich Rumble wrote:

> Yes that would be effective, but the same effect would be to have a
> wordlist, and use -rules=single. I'm not sure if that will save any mem, but the effect
> will be the same.
> ./john hashes.txt -format=dynamic_25 -wordlist=cadidates.txt -rules=single

--rules=single is a waste here, it tries too many things. I'll use it later when I'll have exhausted every candidate that match the hashed password without any transformation.


> Single will try the candidates against all hashes, not just the hash it's
> next to.

not if you specify "SingleRetestGuessed = N" in john.conf like I did. If I understand correctly, of course.


> Any other method I know would require to blindly test thousands candidates
>> on every hash (salted -> slow). And testing ~47 millions candidates
>> (+rules...) on +47 millions salted hashes, on CPU only, is not something
>> you want to do.
>> 
> 
> If you've got any cracks already, creating a charset would be logical to
> do, it'd guess more likely candidates based on the leaned words. If most
> passwords are based off of a few words a mask hybrid makes sense, and I
> believe it's faster than the external mode "known-force".

I'll try more costly/unsure methods later when I'm done with those 10th of millions candidates that work just straight. I can't afford to start long computations on millions hashes when the plain is sitting next to the hash :)


> ./john hashes.txt -format=dynamic_25 -mask=password?a?a
> I think you can do a wordlist/mask like so
> ./john hashes.txt -format=dynamic_25 -wordlist=candidates.txt -mask=?w?a?a
> https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/doc/MASK

I'll probably end up trying that.


> I still find the performance debatable, and I wonder if this is my best
>> option. May be I should split files again (100k lines instead of millions?)
>> to maintain good perf?
>> 
>> 
> John also has GPU support that *might* be good for that hash type (idk),
> not sure about the amount of hashes. ./john --list=formats --format=opencl
> HashCat is an alternative as well if you have a nice GPU.


I'm a bit stuck here, unfortunately: 
I'm running John on a server without GPU, 
I have a Windows PC running hashcat on GPU, but unfortunately hashcat does not seem to have an equivalent for the single mode,
I can't/don't know how to compile John with GPU support on Windows,
I can't boot this PC on Linux to use John with GPU, because that's no ordinary PC, that's a VM with GPU passthrough. Works really great, but since Linux moved away from proprietary AMD drivers, I can't use my GPU into a Linux VM (works like a charm in any other OS using proprietary drivers),
And my GPU is not so nice, it's a Radeon R9 290x (because it works great in passthrough on ESXi, and because it's very quiet).

patpro

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.