Or 8 char salt and append "/" to all words in the dictionary, like oxaners said.
OK, maybe it is pseudo secure crap but untill someone requests it ocHhashcat can't do it. If i do something that's not popular/not implemented in popular password crackers/webpages i'd be safe for now, right? Or maybe is as easy as modifying the source code (if available) of some of those tools ?
Just to make it straight - i'm not going to use this type of hashing in a webapp or nothing.
BTW, i've just tested appending the "/" separator first to the salt and then to the wordlist and i was able to recover the password using hashcat 0.38 in mode 2.
That make me wonder why is the cudaHascat throwing the line lenght exception with the same hash??
OK, maybe it is pseudo secure crap but untill someone requests it ocHhashcat can't do it. If i do something that's not popular/not implemented in popular password crackers/webpages i'd be safe for now, right? Or maybe is as easy as modifying the source code (if available) of some of those tools ?
Just to make it straight - i'm not going to use this type of hashing in a webapp or nothing.
BTW, i've just tested appending the "/" separator first to the salt and then to the wordlist and i was able to recover the password using hashcat 0.38 in mode 2.
That make me wonder why is the cudaHascat throwing the line lenght exception with the same hash??
(04-11-2012, 12:24 AM)undeath Wrote: This is because atom creates custom optimized modules per hash type. If anyone requests md5($salt.$pass) with a 9 char salt (your 8 random chars + "/"), your hashes will be as weak as any other salted md5.
If you really want to make hashes hard to crack, you need to make it slow. Use something like PBKDF2, not cheap self made pseudo secure crap.