15 chars limitation
Hello, I would like to ask you, why is lenght of passwords limited to maximum of 15 characters and could this limitation be removed in newer releases ?
There is plenty of discussion about this on this forum, just use search please. There is currently no plan to change this. But never say never Smile
Oh, I'm sorry that I didn't it before. Well, I have to tell you, it make sens to support longer passwords on combinator and hybrid attacks. When I'm using those attacks, I'm getting a lot of rejected plain texts (some times over 75%) and when I'm looking at not found hashes from big databases, they contain probably over 90% (that's milions of hashes) of those longer passwords which could be cracked with dictionary based attacks.
I doubt its that high, otherwise I would have added it already Smile I guess its the opposite, nearly nothing.
(01-04-2013, 05:22 PM)atom Wrote: There is plenty of discussion about this on this forum, just use search please. There is currently no plan to change this. But never say never Smile

Hi atom

There is indeed plenty of discussion about longer password support in hashcat-plus. I remember it was a popular request when you held the vote for new features.

Speaking purly from a selfish viewpoint this is my number 1 request for hashcat-plus now. It would allow me to ditch "other" cracking programs and work 100% with hashcat-plus.

I believe everyday users are becoming more security aware, probably partly thanks to hashcat-plus. I have noticed more people I talk to about passwords, who are not normally interested in computer security, tell me they use longer passphrases now instead of the old fashioned passwords. Considering the simplilist of passprases "this is my password" would defeat hashcat-plus I do hope you will understand our egerness for longer password support.

I apriciate hashcat-plus is free software and we are all extremly grateful for what you have given us. I enjoy watching hashcat-plus develop and I hope it will continue to remain number 1. For this reason I fear that hashcat-plus will fall behind the new user trend of substituting passwords with passphrases.

I honestly believe we are at the turning point for passwords, some companies salt their users passwords now with either a number or the name of the companey or department. This method of prefixing totally defeats hashcat-plus as it very quicky runs out of keyspace, taking us back to the dark days of before hashcat-plus ! Sad

I remember you once told me that the change to longer password support would be a very difficult one. I don't for a minute pretend to understand the complexities of the change but I hope it is the sort of challenge programmers like yourself enjoy fixing.

Can I please add the longer password support to the feature request page, in the "Under Consideration" section ?

Not to beat a dead horse but I would certainly second the request, I have been running into this limit as well.
A few words to add to this limitation.

I had faced many times the not logical using expensive top
cards, running hours of attacks, getting lots of results, yes, but,
then... why just try a run of th the remanining list with hashcat ?
I do it very often and the results of passwords with 16 and much larger
lenght is surprising good, but show how much a heavy investiment
in GPU can be parcially killed in their return for the investiment due
to that limitation.
Just a comment, not a critic.

Just an example: run hashcat with -a 1 against some large hash files,
play a little with rules, and you will be surprised by the number of
recovered passwords.
it would be less of an issue if combinator in hashcat behaved like combinator.bin or combinator in oclHashcat-plus. but, it would be even nicer if the a0 and a1 kernels just supported longer lengths.

also, there's this:

epixoip@token:~/wordlists$ awk 'length > 15' * | wc -l

epixoip@token:~/unsorted_wordlists$ awk 'length > 15' * | wc -l
It would be really useful for -a1. However this limit was set to increase the speed iirc. Since most passwords are lenght 6-8 its better to have a fast oclhashcat with limits than a slow one without limits.
there's always a tradeoff, and a small loss of speed is an acceptable tradeoff to make something more flexible and more powerful. speed isn't everything.