15 chars limitation
#31
I'm impressed by you guys. This topic seems to be really important for you. So many discussions now and in the past... I'm currently working on other things. Once I finished them I will look again into longer plaintext support. Maybe up to 31.
#32
It would be just great Smile
#33
(01-11-2013, 02:07 PM)atom Wrote: I'm impressed by you guys. This topic seems to be really important for you. So many discussions now and in the past... I'm currently working on other things. Once I finished them I will look again into longer plaintext support. Maybe up to 31.

Yay ! Big Grin

Thank you for listening to our requests atom. You commnets sound very much like a "Pending - Under Consideration" to me !! Smile

I will add it to the apropiate section in the feature request wiki.

As WPA's speed is not decreased by longer passwords could there be a dynamic range in hashcat-plus per hash type ? WPA at 64 length support as there is no performance hit, but say for a hash that would suffer a hit drop down to 31 ?

Thanks !
#34
Great to hear it, thanks atom!
#35
+1 for allowing (at least as parameter) more than 15 chars long :-) for keys.
Just Name+Date (a common password in WPA, I don't know why) easily reachs that limit. Think about something like "Stallone01012000", a not too long (in time) to test attack. For example with PHPBB dictionary as a basis for names, and 8 digits (DDMMYYYY) for the date (it takes 10 hours with my computer to complete using 2000 to 2015 for year YYYY), I find around 25% of passwords being rejected :-( .
#36
My vote +1 for more than 15 characters when using a dictionary!
#37
Hi, I use http://passwords12.at.ifi.uio.no/files/w...0121203.7z
$ make
./extract --wpa --keymap de wordlist.tree > wpa_keymap_de
$ wc -l wpa_keymap_de
9909781 wpa_keymap_de

$ awk 'length > 15' wpa_keymap_de | wc -l
1002313 (that's 10.11%)
$ awk 'length > 31' wpa_keymap_de | wc -l
1911 (that's only 0.019%)

One can list the >15 chars words using: $ egrep -o '[^ ]{16,}' wpa_keymap_de

So, yeah, especially nowdays the >15 limit is bad -- +1 for more than 15 characters.
#38
If you just want to check the remaining 1002313 you can use hashcat CPU. It supports WPA up to length 64 in latest version.
#39
Sure, but still 31 chars would be good. In fact, 63 chars would be good. (why not, if it doesn't slow down the bruteforcing?) Because otherwise one has still to use other tools :\

Suggestion: You have several tools, maybe you can merge some of them?

I must say only the full range of chars is enough..because even if other tools do not scale so good, at least for me waiting 4h instead of 2 and knowing of having tested to whole list is better than not having tested the other 10-15% of my wordlist's words. (and again, why not removing the limit if it doesn't slow down the bruteforcing?)
-------------
Quote:Input.Mode: Dict (../opencrack_plains.txt)
Index.....: 1/2 (segment), 3145161 (words), 33550340 (bytes)
Recovered.: 0/1 hashes, 0/1 salts
Speed/sec.: 741 plains, 741 words
Progress..: 3145161/3145161 (100.00%)
Running...: 00:01:10:44
Estimated.: --:--:--:--

Input.Mode: Dict (../opencrack_plains.txt)
Index.....: 2/2 (segment), 3426892 (words), 33381465 (bytes)
Recovered.: 0/1 hashes, 0/1 salts
Speed/sec.: 711 plains, 711 words
Progress..: 65732/3426892 (1.92%)
Running...: 00:00:01:32
Estimated.: 00:01:18:47

^CTo restore Session use Parameter -s 3225529
:\ What does "Index.....: 2/2" mean?
#40
(03-10-2013, 01:15 PM)atom Wrote: If you just want to check the remaining 1002313 you can use hashcat CPU. It supports WPA up to length 64 in latest version.
Shouldn't it be up to 63 ?
That's what the standard requires.