Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: Custom password separator in md5($salt.$pass)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi.

First of all i'd like to say hello to everybody on this forum as i just got registered.
Second: thanks for such a powerful tool, i'm amazed by it's speed and possibilities Smile
Third: it made me think on the way to protect my hashes and salts from being cracked with this tool.

My question is if can i still use hashcat to crack a password if a random 8 char salt and password variables in php md5() function are separed by a custom character? To make it clearer take a look at this piece of code:

$chars = array_merge(range("a", "z"), range('A', 'Z'), range(0, 9));
shuffle($chars);
$randomChars = array_slice($chars, 0, 8);
$salt = join("", $randomChars);
const SEPARATOR = "/";
$password = "password"
$hash = md5($salt.$separator.$password);

It looks like osCommerce hasher but it's different. The result will be a 32 char hash and a 8 char salt. I need to keep the salt toghether with hash in my db for password comparision in future user login. The example result hashConfusedalt will be like this:
835288cd206223ad81eb78d4dc225823:aVTwl0NR for password "password" and "aVTwl0NR" random 8 char sat.

I've checked all hashcat's algorithms and none worked. Will it eliminate the possibility of crack my password with standard cracking tools available?

Anybody able to crack this password?

I hope i explained myself good enough despite my english.
Any attack on md5($salt.$pass) that prepends ?s should crack this if I understand your algorithm correctly. Essentially you are just prepending "/" to everyone's passwords, then calculating the md5($salt.$pass). If an attacker knows this is the algorithm (they would probably see the pattern after a few results with "/" prepended), they could just prepend the "/" to every string in their dictionary (as long as the password is in their dictionary already as a whole or only needs mangling/appending), or append it to the salt.

I'm not coming up with the same hash as you for this though, your example should end up being md5( VTw10NR/password ) which I calculate to be 75f10ef81001f0f1e1f90008a69bd409, so maybe I'm missing something?
Thank you for your reply and for checking this Smile
I've mistyped the salt. i was copying it manually from my linux box. Sorry for that.
Check again my edited post with updated data.
Any attack you say? At least hashcat is throwing the line lenght exception because of custom salt lenght that don't match other known hashing methods.
Correct me if iÄ…Ä…m wrong.


(04-10-2012, 10:18 PM)oxaners Wrote: [ -> ]Any attack on md5($salt.$pass) that prepends ?s should crack this if I understand your algorithm correctly. Essentially you are just prepending "/" to everyone's passwords, then calculating the md5($salt.$pass). If an attacker knows this is the algorithm (they would probably see the pattern after a few results with "/" prepended), they could just prepend the "/" to every string in their dictionary (as long as the password is in their dictionary already as a whole or only needs mangling/appending).

I'm not coming up with the same hash as you for this though, your example should end up being md5( VTw10NR/password ) which I calculate to be 75f10ef81001f0f1e1f90008a69bd409, so maybe I'm missing something?
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.
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??

(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.
As you already realized, cracking this is no problem at all. I think "security through obfuscation" applies here. Never do this, when there is a better way of solving your problem!

The reason for cpu to work with your hash is the one I already mentioned. The GPU versions have optimized kernels for every PSA. A CPU is much easier to handle and doesn't need these optimizations (or doesn't profit that much, because it's slower).
I think all undeath is saying is that there are plenty of other better solutions to your problem on the market in other crypto systems. A very important aspect of security is to not roll your own crypto system, rather to use some pre-vetted system to solve your problem, else you will be giving yourself a false sense of security.

All you are doing is slightly slowing down attack speed by using an obfuscation technique first (which will be discovered quickly) and a non-standard salting format (which some crackers may not like at first). The problem is that these can both be overcome rather easily, even with GPU hashcat, albeit maybe at a slower attack rate. (at worst, the attacker will make custom dictionaries/rule files that prepend the salt and separator, then use standard md5($pass) to attack it with no length exceptions)

The real solution to slowing down attack rate would be to simply use a hashing algorithm that is very costly in system resources. Don't try to hide your crypto system from the attacker, rather flaunt a good one in front of them while they get frustrated and give up because the attack speed makes the fruit hang too high Smile
Very well said & Wise Too. Wink