[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8D99E379-DFD7-43E0-9351-CA6E2D43C6D3@shinnok.com>
Date: Tue, 24 Mar 2015 19:39:08 +0200
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [RFC] Johnny further development proposal
>>
>> Immediate tasks:
>> 1. Upgrade to Qt 5
>
> Debian stable does not have qt5 yet. Could Johnny be compatible with
> both qt4 and qt5?
'
Yes, we can ifdef based on versions where needed, I don't think there are that many places, since Johnny doesn't make that heavy usage of Qt.
Qt 5 has been out for quite a while now and at the moment it's at version is 5.4.1, and Debian Jessie is to be released soon, with included Qt 5 libs.
However, ultimately I'd like to shun Qt4 and just focus on Qt 5, for the added modularity, platform goodness and fixes.
>
>> 2. Fix any outstanding bugs or crashes (crash on exit while john is running,
>> pause not working, etc..)
>> 4. Support for OS X and distribution package (DMG package, should probably
>> include JtR)
>> 5. Ui improvements (hide progress bar when not needed, better sidebar
>> navigation, proper layout constraints so that UI elements look nice, e.g.
>> the button's in the Settings page are a mile long, etc..)
>> 6. Windows support and distribution package either:
>> a) .msi if it makes sense, will have to include JtR since I don't think
>> there is one for it
>> b) just .zip package would do
>> 7. Make proper .deb package for Linux with CONTROL file that specifies:
>> a) ARCH
>> b) Qt dep
>> c) JtR dep
>> d) app description
>> Maybe Kali have done that properly for their package so we could use that
>> as a reference.
>
> I made .deb and .rpm files for 6 most popular distributions in 2012.
>
> Packages are on the wiki.
> http://openwall.info/wiki/john/johnny
>
> It is my fault that CONTROL/spec files are not there (and not in
> repo). Though I've used one binary for all packages (so .rpm was not
> built from "sources") due to incompatibility between qt 4.8 and qt
> 4.6.
We might concentrate on just the platforms we are working on and wait for requests or rely on distribution maintainers for other platforms.
>
>> 8. The progressbar doesn't really say much currently. Percentage of cracked
>> password could just as well be shown as numbers.
>
> I just did
>
> git clone https://github.com/AlekseyCherepanov/johnny.git
> cd johnny
> qmake
> make
> ./johnny
>
> loaded some file with hashes and it shows something like:
>
> 0% (0/2657: 0 cracked, 2657 left) []
>
> Though it is not a status line from john, it is internal statistics
> over full set of hashes loaded into johnny.
>
>> Maybe we should switch the
>> progress bar to showing either:
>> a) how much till cracking completion (if JtR can estimate that, per
>> cracking mode type would be fine too)
>> b) ??
>
> I'd show how much of the hashes were loaded and are under attack now
> (maybe cracked, left from them too).
>
> Current jumbo shows guesses per second too.
I'm somewhat reluctant with using a progress bar for percentage of cracked passwords, especially since cracking passwords is supposed to take quite a while and is usually non-deterministic, a progress bar might not be the best visual indicator for neither speed nor cracked vs. non-cracked ratios. I'll think about it and come up with simpler more obvious indicator.
>
>> 9. Manual plain-text probing for individual hashes
>> 10. Hash type suggestion/guessing for individual hashes
>> 11. Critical JtR integrations
>
> What do you mean by #11?
I guess I meant whatever important JtR CLI options and flags that are missing from the UI functionality. I'll have an answer to that after I do an evaluation. List feedback is welcome of course.
>
>> Things for later:
>> 1. Further JtR integration (need suggestions)
>> 2. JtR pro integration
>
> Mmm, "pro"? Do you mean jumbo? (Though jumbo is not "pro")
Back in the day, there was a JtR Pro based on jumbo I think, is that not relevant anymore? I'll probably have to have this discussion with Alexander directly.
By the way, Aleksey, how do we stand with jumbo support, do we support any, all or something of jumbo's goodness?
>
>> Things for way later:
>> 3. Support multiple cracking sessions, not sure if this can be done now by
>> just running multiple Johnny apps. The best option would be multiple tabs,
>> but if multiple apps would work just as fine I'd be contempt with just that
>> for now.
>> 4. Remote cracking sessions, most people that are going to do heavy usage of
>> JtR like a "pro" are not going to crack on the everyday machine where they
>> run Johnny too, but on remote always on headless power beasts, so a cool
>> feature would be for Johnny to be able to tap(securely) on such remote
>> sessions from a remote PC. This needs to be researched and discussed on the
>> lists before anything can be done. What I think the easiest option would be
>> to be able to use ssh pipes to either direct JtR ttys or some log file(no
>> interactivity for this option). Separate watcher daemon is another more
>> complex alternative.
>> 5. Translation support?
>> 6. Dictionary editing and generation based on interactive rule sets?
>> 7. Post-cracking statistics regarding the frequency of passwords, characters
>> and lengths, would be nice. Provided in the statistics pane.
>
> Interesting.
>
>> Goals to keep in mind for the future:
>> 1. Maintain default operating system UI looks, until otherwise needed.
>> 2. Simplicity over complexity.
>> 3. The UI needs to give people reasons to use it, otherwise they'll just
>> skip it.
>
> #3 is interesting. I don't use Johnny myself. I am not sure about
> goals of Johnny. Should it be easy and limited? Or should it be all in
> tool that does not hide complexity of cracking? Or should we just make
> john easier (things like batch mode aka default behaviour) and easy
> gui? Of course, Johnny should make things easier. But what should be
> made easy earlier?
>
> When could next release occur in your opinion? What features should be
> there?
This is understandable, given that Johnny hasn't really achieved much of what I originally devised. That's why I'm back, I want to get it farther. I'm especially motived, driven by the fact that even if Johnny hasn't really seen much more than a few months of work it still made it into distribution repos and some people still use it.
Now let's get speculative a bit here, so that we can devise goals for the future:
There aren't that many people cracking passwords at their personal desktop's anymore(there was a time when that was popular) and those who still do are most likely to be in need of a GUI. So what I propose for Johnny to be and was trying to do from the beginning is:
1. Have a GUI application that "teaches" users why passwords are insecure. By teaching I mean harness the decades of effort that went into JtR, present them in an easy to use and accessible UI so that it will enable both security geeks(boasting to their bosses, peers) as well as new comers(boasting to their friends, girlfriends and moms) how easy and quick it was to decipher 99% of the latest Web 2.0 service hash dump.
2. I hope I'm not going too far here, not sure how many people would agree, but in order to stay relevant in the future, maybe at least for Johnny, we'll need it to manage distributed cracking sessions running on multiple machines(machine=pcs, servers, nodes, vms, raspberrys, fpgas). Johnny would be the perfect fit for managing multiple JtRs running on different machines. I'm not sure what solutions are there now for doing that with JtR, if any, can anyone help me with that? One first step towards tackling this would be having a GSoC proposal for a daemon/client(either plain C or even python/ruby would be a good choice for this) implementation that manages multiple instances of JtR. Then we can wrap the GUI around that.
We shouldn't be thinking about this for too long or too often, just concentrate on code and functionality for now. For a start, we should concentrate on no.1, we'll arrive to the steps that are need in the planning that we're going to do next. But we do have to think about no. 2 at some point.
Shinnok
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.
