Discussion:
[john-users] failed to break my own created password
Eric Oyen
2018-05-05 05:12:21 UTC
Permalink
Hello folks,

Well, I tried with both Davegrohl and JTR using both a wordlist approach as well as a mask approach. At this point, I consider the password I created (by fat fingering it) to be qualified unbreakable without considerably greater resources than I have here.

To that end, I am now considering a cluster approach using NFS as the primary filesystem and having a number of nodes all running JTR and all taking and putting data into the right files (this way, the load can be split).

Kali Linux has some instructions on this that might prove useful. At this point, what I have here is just not up to the task.

So, thoughts on JTR..

Nice program, has lots of features, but the man page is woefully under documented/incomplete. I am definitely going to continue running the community contributed version as it has support that even the jumbo version in MacPorts doesn't have. Anyway, I will see if I can acquire a number of older machines (something in the range of 8 to 10 years old as they are dirt cheap) and setup a home built beoWolf cluster.

Frankly, I wish I had access to the datacenter for Ebay here in Arizona. a 20,000 node BeoWolf cluster would be just the ticket. :)

anyway, that's the temp end of this project for now. I will return to it when I get a little more time. now I have to get into training for some upcoming bike races (I am trying to get on the USA Paralympic team).

-eric

PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386
Royce Williams
2018-05-05 13:55:45 UTC
Permalink
Post by Eric Oyen
Well, I tried with both Davegrohl and JTR using both a wordlist approach
as well as a mask approach. At this point, I consider the password I
created (by fat fingering it) to be qualified unbreakable without
considerably greater resources than I have here.
If you suspect a typo, a variety of typos can also be simulated. Here's a
crude example of how to generate some rules for mis-key (rather than
transposition) typos:

https://gist.github.com/roycewilliams/9d8e98587cff105b2e05a9f0e8de8371

Royce
Solar Designer
2018-05-05 14:43:17 UTC
Permalink
Post by Royce Williams
If you suspect a typo, a variety of typos can also be simulated. Here's a
crude example of how to generate some rules for mis-key (rather than
https://gist.github.com/roycewilliams/9d8e98587cff105b2e05a9f0e8de8371
To do something different but similar (overstrikes and inserts) with
JtR, put the supposed password in a wordlist file and use --rules=oi.
This ruleset is already included in recent bleeding-jumbo, but in case
of using an older version here it is:

[List.Rules:oi]
o[0-9A-Z][ -~]
i[0-9A-Z][ -~]
o[0-9A-E][ -~] Q M o[0-9A-E][ -~] Q
i[0-9A-E][ -~] i[0-9A-E][ -~]

This does one overstrike/insert up to length 36 and two up to length 14.
With a fast hash like Eric's, this is very quick.

If leetization might have been applied to the original password, then it
may also be passed through --external=Leet or the masks previously
posted in here may be used prior to applying the rules above (with a
separate invocation of JtR).
Post by Royce Williams
unbreakable without considerably greater resources than I have here.
Based on what you tell, this is primarily about adjusting the attacks
you run and to a lesser extent about the resources you have.
Post by Royce Williams
To that end, I am now considering a cluster approach using NFS as the primary filesystem and having a number of nodes all running JTR and all taking and putting data into the right files (this way, the load can be split).
Bad idea, unless you'd do it for fun. With just one hash to crack on
just a few systems, it'll be easier for you to run different attacks or
use the --node option on those nodes manually. And no need for shared
storage. You'll take the one cracked password from whatever system
cracks it.
Post by Royce Williams
the man page is woefully under documented/incomplete.
Like I said, there's no official man page. There's only Debian's. Just
don't use it - use our documentation under doc/ instead - but then it's
probably too detailed.
Post by Royce Williams
I will see if I can acquire a number of older machines
Bad idea, unless you'd do it for fun. A factor of 10 or so difference
in speed is very unlikely to result in your password getting cracked.
In terms of improving your chances, your time is better spent on
adjusting the attacks you run.

Also, if you do want to buy extra hardware anyway, buy some recent GPUs
rather than some old machines. And perhaps you already have some GPUs
you could use, as well.
Post by Royce Williams
(something in the range of 8 to 10 years old as they are dirt cheap)
They're also slow and not worth your time, unless you'd do it for fun.

Alexander
Eric Oyen
2018-05-05 18:34:15 UTC
Permalink
will any of the BitCoin specific GPU modules (hardware) work for this? those are relatively cheap and can be run from a USB hub.

I have a Rasberry pie unit here that I am dedicating to Software Defined Radio (as a air spy server) but with the of a couple of these modules, it can also double as a BitCoin mining node as well as solving for password strength.

btw, I still have JTR running on the mac mini working on that password hash. I set min length to 8 characters and max length to 18 characters and am allowing only the use of 2 symbols (! and .). I am letting it run incrementally on the problem and will leave it alone. Since that is a multicore machine, I have multiple instances running (1 per core) and each one is set for it's own min and max length settings). I will get this, but it is going to take a little longer than I planned on.

I might kill off one of the instances and do a run based on info given in this thread.

thanks for the helpful hints.

-eric


PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386
Post by Solar Designer
Post by Royce Williams
If you suspect a typo, a variety of typos can also be simulated. Here's a
crude example of how to generate some rules for mis-key (rather than
https://gist.github.com/roycewilliams/9d8e98587cff105b2e05a9f0e8de8371
To do something different but similar (overstrikes and inserts) with
JtR, put the supposed password in a wordlist file and use --rules=oi.
This ruleset is already included in recent bleeding-jumbo, but in case
[List.Rules:oi]
o[0-9A-Z][ -~]
i[0-9A-Z][ -~]
o[0-9A-E][ -~] Q M o[0-9A-E][ -~] Q
i[0-9A-E][ -~] i[0-9A-E][ -~]
This does one overstrike/insert up to length 36 and two up to length 14.
With a fast hash like Eric's, this is very quick.
If leetization might have been applied to the original password, then it
may also be passed through --external=Leet or the masks previously
posted in here may be used prior to applying the rules above (with a
separate invocation of JtR).
Post by Royce Williams
unbreakable without considerably greater resources than I have here.
Based on what you tell, this is primarily about adjusting the attacks
you run and to a lesser extent about the resources you have.
Post by Royce Williams
To that end, I am now considering a cluster approach using NFS as the primary filesystem and having a number of nodes all running JTR and all taking and putting data into the right files (this way, the load can be split).
Bad idea, unless you'd do it for fun. With just one hash to crack on
just a few systems, it'll be easier for you to run different attacks or
use the --node option on those nodes manually. And no need for shared
storage. You'll take the one cracked password from whatever system
cracks it.
Post by Royce Williams
the man page is woefully under documented/incomplete.
Like I said, there's no official man page. There's only Debian's. Just
don't use it - use our documentation under doc/ instead - but then it's
probably too detailed.
Post by Royce Williams
I will see if I can acquire a number of older machines
Bad idea, unless you'd do it for fun. A factor of 10 or so difference
in speed is very unlikely to result in your password getting cracked.
In terms of improving your chances, your time is better spent on
adjusting the attacks you run.
Also, if you do want to buy extra hardware anyway, buy some recent GPUs
rather than some old machines. And perhaps you already have some GPUs
you could use, as well.
Post by Royce Williams
(something in the range of 8 to 10 years old as they are dirt cheap)
They're also slow and not worth your time, unless you'd do it for fun.
Alexander
Solar Designer
2018-05-05 18:38:44 UTC
Permalink
Post by Eric Oyen
will any of the BitCoin specific GPU modules (hardware) work for this? those are relatively cheap and can be run from a USB hub.
No, they are not GPUs and they won't work for this.

Alexander
Eric Oyen
2018-05-05 18:51:22 UTC
Permalink
nuts!

well, as marvin the martian stated: "well, back to the old drawing board!" :)

-eric

PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386
Post by Solar Designer
Post by Eric Oyen
will any of the BitCoin specific GPU modules (hardware) work for this? those are relatively cheap and can be run from a USB hub.
No, they are not GPUs and they won't work for this.
Alexander
Loading...