|
Message-Id: <91D00B27-FA4A-46E7-A4EC-5602654B9BE6@shinnok.com> Date: Mon, 22 Jun 2015 22:42:41 +0300 From: Shinnok <admin@...nnok.com> To: john-dev@...ts.openwall.com Subject: Re: Johnny test feedback (was: Mathieu's weekly report #7) Frank, Thank you for this really insightful feedback. We are in dire need of *real* feedback like this one. Comments embedded bellow: > On Jun 16, 2015, at 12:34 PM, Frank Dittrich <frank.dittrich@...lbox.org> wrote: > > Mathieu, Shinnok, > > May be you should encourage others to test the latest github version, to > get some feedback prior to the release. I guess you were the only one interested enough to give Johnny master a spin for the time being. There's going to be enough encouragement for people with this first release, doing something more at this point is too late and will delay the actual release. > ... > When I run ./johnny from the command line, I get a warning which is > probably harmless, but might confuse some users: > libpng warning: iCCP: known incorrect sRGB profile > Yeah this is harmless and nothing we can do about. > Then I loaded the password hashes by clicking on the "Open Passwd File" > icon. > I must admit that I find the term "Passwd File" somewhat confusing > (because the file contains hashes, not passwords), but that term matches > john's usage output: > Usage: john [OPTIONS] [PASSWORD-FILES] Yeah it could be confusing for someone not familiar with the history. My assumption is that it all started out with the /etc/passwd files, thus the "password file" terminology. On the other hand, a collection of passwords/phrases in a file aren't usually called that way either, they're usually called a dictionary or word list right? > I like the "Formats" column, indicating that the hashes I collected into > the sample are indeed a mix of varying hash formats. > > What I like less is that pressing the "Start Attack" icon just starts > john without any options, cracking just the descrypt hashes, ignoring > all the other hashes. > May be the user should be forced to pick a hash format. (After all, you > already know that there are many different formats in the file, you > don't need to parse ./john's stderr output...) We only know for the Jumbo case. We need to make it clear what hashes will actually be picked up on for the default attack mode though and it needs to work for both core and jumbo. > > The user has to switch to the console log to see all the warnings. > The console log also shows that john immediately finds the passwords of > two users (5 and 5875; the same hashes, once for descrypt, once for > crypt, using an empty password). > There is no indication that the passwords of two users have been > cracked. The status bar is just showing "0%". > (After I restarted johnny several times, I noticed that it also prints > the number of guessed passwords, so may be I just didn't wait long > enough when I noticed that the number of cracked passwords was not > indicated on the status line.) The cracked passwords are grabbed using john show. The interval for running that show handler is a configurable setting and has a default of 600 seconds. 10 minutes for a default is arguably too long and thus I've changed it to 15 seconds. > > I must admit that I noticed the "Open Last Session" icon only after > starting johnny several times. > That's why, resuming the work seemed to be rather complicated. > When I paused the attack, closed johnny, and restarted johnny, I would > have preferred johnny to load the previously loaded hashes, may be after > automatically parsing the .rec file of the default session. > Instead, I did re-load the hashes manually. I couldn't even pick from a > list of previously used files, but has to navigate through the file system. > Also, the "Resume Attack" icon was not active until I opened the same > "Passwd File" again. > Instead of automatically loading the hashes when restarting johnny, the > "Resume Attack" icon could be active of no password hashes are loaded, > and when pressing it, johnny could automatically load the password > hashes after parsing the .rec file of the default session. > I would prefer getting rid of the "Open Last Session" icon if johnny > would just do "the right thing". But please ask for input of other users. > We are already working on fixing this usability issue. We store attack parameters per session now and have a history of sessions. The last session is loaded automatically now, right Mathieu? Better wording for the actions(Start New Attack vs Resume attack) and tooltips should help in being more obvious in regards to it. > The fact that both "users" used empty passwords doesn't help to indicate > which hashes had been cracked. > May be you need to somehow indicate that the password has been found > even if the password is empty (or consists of a sequence of spaces). Nice find. For now we could make the User column fields for the cracked passwords bold. For the future, we need to indicate non-printable or control chars too in the Password field. Maybe we could encode it to UTF escaped or something if we find no printable chars in a password by default. I'm not that experienced with text encoding... Note: We also need to enable right click copy on the fields in the table view. > > I admit I didn't look at your release schedule, so I don't know what > kind of features you want to implement. > I just wanted to share what I think could cause trouble for users. > Feel free to ignore it or to address it after the first release. Thanks again, it is much valued, 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.