gmane.comp.security.openwall.john.user

existing collaboration tools suitable for MJohn

Aleksey Cherepanov — 2012-05-21T16:09:44

I looked through output of 'apt-cache search collaboration' and found
that project management systems for distributed development could suit
our needs well. Often they are web applications with ability to post
articles, comment on them, attach files, some systems allow voting,
supports different frontends and provide flexible search with filters.

So I'd like to investigate request-tracker. Request-tracker attracted
my attention because while it is a full featured site engine with cms
it is implemented in perl, supports web, email, and command-line
interfaces. Other systems of that class are similar but are not
implemented in perl and often lack support for multiple uis.

Also I think publishing software and cmss are more suitable for MJohn
than others. But it seems for me that they would need more
configuration and code. Though I did not look on them precisely yet.
Maybe I miss something.

Regards,
Aleksey Cherepanov

Re: Finding words on which passwords are based

Simon Marechal — 2012-05-21T13:27:44

I believe it is a much better idea to work with their SQL dumps !

Re: Finding words on which passwords are based

Aleksey Cherepanov — 2012-05-21T12:53:44

Looking through packages for collaborative software found:
libwww-wikipedia-perl - perl module that provides an automated interface to Wikipedia

I think it could help for that task when/if we will do it.

Regards,
Aleksey Cherepanov

PHDays Hash Runner challenge

hashrunner — 2012-05-21T09:36:57

Hi!


"Hash Runner" online hash cracking challenge will take place during international security conference "Positive Hack Days 2012" (http://phdays.com/program/contests/#6332).


Any Internet user can participate: teams/individuals can register from May, 25 to the end of the challenge (http://phdays.com/personal/?register=yes). Challenge will start on May, 30, 05:00 GMT (09:00 MSK) and will last until the end of conference: May, 31, evening (exact time will be announced later).


Several thousand hashes of different types will be available: NTLM (cost:20), LM (20), DES (120), Oracle (20), SHA1 (20), SSHA1 (60), MD5 (10), md5($pass,$salt) (60), Blowfish(Openbsd) (500), SHA256 (60), GOST3411 (160), md5(phpBB3) (350), md5(wordpress) (350), MySQL5 (20), MSSQL2005 (20) and DCC2 (200). Passwords and rules used to generate hashes are categorized into number of groups to reflect their complexity. Each group has its own modifier formula and ratio which will significantly influence final hash cost. Only base hash cos

bash completion for john and unique

Frank Dittrich — 2012-05-21T08:24:51

Hi all,

I created a bash completion script for John the Ripper which supports
bash completion for john (official releases and jumbo versions) and
unique (here, bash completion only makes sense for the jumbo version,
and is limited to listing possible options mentioned in the usage output).

The attached file john.bash_completion contains some fixes for
--wordlist= completion and --restore=/--status= completion, compared to
the version in magnum's current git repository on github.

Once included in the jumbo version, this file will probably be located
in the src directory.

I'd like to get some feedback from you so that I can change the
completion logic or fix bugs before the next jumbo version is released.

To just test bash completion for john, you can download the attached
file somewhere and source it like this, if you are in the directory
where you downloaded the file:

. john.bash_completion

(It is a dot, followed by a space, followed by the file name.)

If you want to use the bash completion for john

Re: Performance Considerations of stdin

Solar Designer — 2012-05-20T15:07:09

Usually yes, but this doesn't tell you if things are overall slower
(likely) or faster (theoretically possible) than JtR alone (with its
built-in generation of candidate passwords).  Additionally, you keep
another CPU core at least partially in use by your word generation
program; you could instead use that CPU core by another instance or
thread of JtR to compute more hashes per second total.

In general, piping candidate passwords into JtR is usually wasteful when
you crack fast and saltless hashes (or when the salt count is low).
For slow and/or salted hashes, it is OK performance-wise (although you
don't achieve any speed increase in this way).

Usually, --stdin and --pipe are used not to increase the speed (which
they usually don't), but to provide a candidate passwords stream that
would be impossible or more difficult to generate with JtR itself.  For
example, when you already have a program that generates your desired
candidate passwords, you may use it along with --stdin quicker than
reimplement the

Re: SHA1-Gen / Dynamic_25 Hashes

Solar Designer — 2012-05-20T11:36:36

These two both work for me:

user:$SHA1p$user$45f106ef4d5161e7aa38cf6c666607f25748b6ca
user:$dynamic_25$45f106ef4d5161e7aa38cf6c666607f25748b6ca$user

There's no need to specify any fancy options - everything is correctly
autodetected with this kind of lines in the input file.  Of course,
you should only use one of these formats, not both at once.  dynamic_25
is expected to be faster.  The "generic SHA-1" format pre-dates JimF's
introduction of SHA-1 support into his "dynamic" format.

As to what was wrong with your attempts:

With $SHA1s$, the salt is suffixed to the password, but in your case
it's a prefix - so we use $SHA1p$ (where the "p" stands for prefix).

With dynamic subformats, the salt is specified after the hash.

Alexander

Re: SHA1-Gen / Dynamic_25 Hashes

Stephen John Smoogen — 2012-05-19T20:45:38

That does not look like long enough to be sha1. I would


Try it the following:

$SHA1s$abac710fda8befcb4b8f3e96fb27a54f271b70a4$xxx

SHA1-Gen / Dynamic_25 Hashes

NeonFlash — 2012-05-19T15:20:06

I am not clear what is going wrong here. Trying to crack hashes that have the SMF Forum format:

sha1(strtolower($user),$pass) and this matches, sha1($salt,$pass)

The username is the salt in this case. Ofcourse, I have converted the usernames to lowercase. I have tried both SHA1-gen and Dynamic_25 subformat, but it does not work for me. I do not get any error message, the hashing process shows no cracked hashes.

Please note: I know the passwords already and they are present in the wordlist I am using.

Using JTR verison: 1.7.9-jumbo-5

Here are the command line syntaxes. "xxx" is the username or salt in this case.


Case 1:


john --format=sha1-gen --field-separator-char=" " -w:wordlist.txt hashes.txt

The hashes are stored in the following format:

xxx $SHA1s$xxx$abac710fda8befcb4b8f3e96fb27a54f271b70a4

Case 2:

john --format=sha1-gen w-:wordlist.txt hashes.txt

Hashes are stored in the format:

$SHA1s$xxx$abac710fda8befcb4b8f3e96fb27a54f271b70a4

Case 3:


john --subformat=dynamic_25 --field-separator-c

Re: Performance Considerations of stdin

Frank Dittrich — 2012-05-19T06:07:48

The main reason that this setup works better willprobably be that the
generation program and john use different CPUs.

Frank

RE: Performance Considerations of stdin

Brad Tilley — 2012-05-18T21:37:13


Thanks Jim, I appreciate your response. I only use Linux and BSD systems,
so I'm not too concerned about Windows.




Do you think it's safe to say that so long as the word generation program
keeps JTR at 100% CPU utilization that it's fast enough? I'm not sure
whether that's a good metric to go by or not.


<snip>

Re: Performance Considerations of stdin

Brad Tilley — 2012-05-18T21:24:31

Thanks Bartosz. I've never heard of that program, but it seems interesting
and certainly fast enough. I suppose so long as the word generation
software is going as fast as or faster than JTR, then everything will be
OK performance-wise. I can just imagine cases where doing certain complex
word mangling might be the bottleneck.

Brad

RE: Performance Considerations of stdin

jfoug — 2012-05-18T20:08:01

--pipe and --stdin on winblows both suck. It is the underlying OS level
implementation of pipes under windows. They are very slow. They have tiny
pipe_buffer, and input and output get into lock-step-syncronization between
them. The pipe_buffer is only 1k (or 4k??)   Even if you create a pipe in
code, using _popen(), or _pipe() or even CreatePipe() and set larger buffers
(64k is max), you still end up going through the pipe code in the kernel or
command processor.

I have thought of making some specialty code for the windows build only,
that was like the pipe (bulk reads), but used a couple of large blocks of
shared memory.  I am pretty sure I could get the speeds back up to the
incremental rate, but it would be such unique code, that it may not be super
useful to many, thus I have not taken the time to do it.

I just wish the 'standard' pipe worked efficiently under windows, for moving
large amounts of data between applications, but it does not.

Jim.

Re: Performance Considerations of stdin

magnum — 2012-05-18T19:34:17

Correction: Both Jim and I meant the --mem-file-size option. So you've
better use -mem and not -memory.

Also, it turns out this zero shortcut is actually documented in doc/OPTIONS.

magnum

Re: Performance Considerations of stdin

magnum — 2012-05-18T19:29:19

Just for the record, you could as well use the (poorly documented)
-memory=0 for this. It will buffer the whole file no matter how large it is.

magnum

Re: Performance Considerations of stdin

magnum — 2012-05-18T19:19:17

Isn't this Windows problem mitigated a little (or a lot) if using --pipe
instead of --stdin? If not, I suppose we could make it to.

magnum

RE: Performance Considerations of stdin

jfoug — 2012-05-18T18:31:35

Depends upon the OS.  If it is winblows, then the performance is horrible.
I get about 30% or so performance for fast hashes, vs a dictionary read into
memory, with rules run on the dictionary.  Windows has a TINY pipe_buffer.
I have found no way to speed this up (and I have tried).

However, for many other OS's, may likely be a performance boost by using
-stdin mode, IF doing some complex work, since you can do much more complex
things a lot more efficiently in a native language (like C, or even perl),
much faster than john's rules.  

I have done this for things like a super elite builder, which can do all
sorts of permutations, such as full permutation of letter case, case, full
permutation of all elite possibilities (such as mississippi -> m1ssissippi,
miss1ssippi, m1ss1ssippi, ... m!ssiss1pp|, etc).  Doing this in john, with
rules, or other extern stuff 'could' be done, but that is beyond my
capabilities, and I think you would either have to write a lot of rules that
either reject a lot of input words,

Re: Performance Considerations of stdin

pierzi — 2012-05-18T17:37:26

Hello Brad

I've been using jtr in stdin mode with maskprocessor from hashcat tools,
which seems to be one the fastest word generator...
to be honest i didn't saw any performance difference between stdin and
incremental mode.

Best regards
Bartosz

2012/5/18 Brad Tilley <brad-3FTg57TTyomakBO8gow8eQ< at >public.gmane.org>

Performance Considerations of stdin

Brad Tilley — 2012-05-18T17:25:38

Hello John Users,

What, if any, performance considerations are there when passing word
candidates to JTR via stdin? I plan on doing some tests to see first-hand,
but before doing so I wanted to ask here in case others have had some
experience with this.

Basically, I'm wondering if a word generation program that passed words
into JTR via stdin would perform better than when JTR is doing both word
mangling and hash generation, hash testing, etc all by itself.

ehco -n word | john --sdtin

Has anyone had experience performance testing something such as this?

Thanks for any advice,

Brad

UI for MJohn

Aleksey Cherepanov — 2012-05-17T19:10:13

I'd like to talk about users's interactions during collaborative
cracking and respective user interface.

During the contest we used mailing list and irc channel for
everything: to talk about attacks, to track attacks in run, to
coordinate.

Also there were some team members that was able to talk directly being
at defcon. They did meetings and talks out of the list and channel. I
think that does not need any special user interface: like with mailing
list and private talks one should write down conclusions with reasons
possibly and make them public (available to other members).

It seems that there are two kinds of talks: general coordination and
talks related to certain attack. The latter could be grouped to or
even fill attack's description. I think there should be a separate
place for each attack and related talks. Also attack status should be
shown there. In case of rare status changes they could be posted as
messages but when they are frequent it would be more appropriate to
show only last status, only c

Re: using all available hardware

Aleksey Cherepanov — 2012-05-15T20:07:01

It seems that we need separate action: prepare for attack. So user can
download all stuff without starting attack.

Also there could be a script that computes (or ask the server for)
optimal behaviour and then show. And for automated mode there should
be a daemon that knows about attacks in run on that machine and could
run command according to information about optimal behaviour.

By the way I realized that enough information about progress could be
captured using --status. So I do not need a full wrapper. That makes
things easier (or it seems to me to be so).

Regards,
Aleksey Cherepanov