CODEWITHSUNDEEP
javascriptsecuritypostmd5
Azevedo
Azevedo

Reputation: 2189

Client side 100% secure password POST

I came up with this theory to avoid password stealing form POST sniffing. The idea is to concatenate a salt string (randomly generated on php session_start()).

enter image description here

Please, note that the salt_hash is randomly generated on each access... It is NOT calculated in the client side.

Basically the JS code would be added to the HTML:

<script>
var salt_hash='654236426556424655643645462321560356';
</script>

then before POSTing it, I'd calculate...

cryptoPass = md5(md5(password)+salt_hash);
passowrd = ''; // clear user password input
submit POST...;

Then on login.php I'd compare $_POST['cryptoPass'] with md5( MySQL user password stored with md5, plus the salt_hash)

Would it actually work or it's a nonsense theory?

Upvotes: 2

Views: 274

Answers (1)

John
John

Reputation: 3797

First I'll start with a side note, the first rule in security is never try to make and use your own crypto. There are professionals out there that are very good at making cryto algorithms, and people are still able to crack them.

Your scheme does not actually add that much security to the scheme. If an attacker knew that you were calculating hashes with:

cryptoPass = md5(md5(password)+salt_hash);

Then they could just brute force using the same algorithm if they knew the salt value. This adds almost no security because it takes almost the same time to crack:

cryptoPass = md5(password + salt);

both of the cracking algorithms for this are the same. They are the same time complexity. You are just hashing using two different functions.

The best solution here would to just be to use TLS, which is easily implemented.

And the notion of Client side 100% secure Insert Anything is unrealistic. There is no way to secure something 100% unfortunately. If man made it, then with enough time, man can crack it.

Why using hashing + salt on the client side as an encryption mechanism is bad:

Let's say you use RANDOM hashing, just as you have mentioned. The client initiates a login sequence with the server and the server sends it the salt value:

718904732197

The attacker now knows the salt value. Now, the client hashes his/her password using your hashing function:

cryptoPass = md5(md5(password)+salt_hash);

The salt hash is random, but known and so is the algorithm. From this the attacker cracks the hash using a simple brute force algorithm (it would take a matter of seconds to crack a simple 6 digit password). They can also use rainbow table and dictionary attacks against the hash to increase the cracking speed.

The attacker will generate hashes using your known function:

cryptoPass = md5(md5(password)+salt_hash);

and they already know the salt value. They will extract the password from the hash using brute force. Now they have the clear text password and probably the username so they can now login to that user's account.

Maybe this will help you as well:

Is this better than no security? YES

Is hashing + salt better than hashing alone? YES

Is using a random salt value even more secure? YES, to an extent.

All of that aside, the scheme that you are using is not secure by today's standards. An experienced cracker could have your entire algorithm figured out in a couple of hours.

Upvotes: 5

Related Questions