Html Hash password in form before submit trick

Question

Been reading on making logins more secure and i am busy implementing a system for a client and there no option for ssl.

My question here focuses on sending the data from the login form to the server. From what i have read, by just hashing them password in the form , wont help , as the attacker could intercept the same hashed password and submit it.

Only solution being SSL. -> i know

Just trying to make it a bit harder for the attacker with my solution below .

Heres my taught , i'm a learner so go easy on me if you find my solution does not work , i'm looking to learn..

1) You send the password hashed ( so the attacker cant read it )

2) Create a hidden field in the form - the value of this field would be a hash of a combination of the user agent and ip with a salt .

3) when you receive the form you verify and see if the hidden field value matches the server value of the user agent and ip - with php $_SERVER for eg.

Would this slow the attacker down ?

EDIT

Seems like a alot of confusion let me try this again.

You have a login form .

1) the password field once filled in before the the form is submitted, Is hashed using javascript .

2) you create another token on the users pc to submit with the form i.e a hidden field in the form . it does not matter weather the attacker can read its content. The content of this field will be the users agent string and ip which is hashed using a salt key which is stored in a config file for e.g.

3) Once form is received server side, you check the user ip and agent , and hash it using the salt key and check if it matches the one which was submitted.

If a hacker gets the token , password and your email and sends it to the server , it wont match the server generated one , since attacker wont be able to hash it without correct salt key even if he fake the ip and user agent.... i think ..

NEW UPDATES AS PER QUESTIONS

1) the point of the script is to make a hackers life hard . there no guaranteed way , as you say , they can get the password from another site that you use , and in that scenario even if you have ssl it doesn't help. I'm trying to make the login more secure from sniffing without ssl.

Updated solution

1) SERVER SIDE

Generate a dynamic salt key per user basis.

• Have a salt key stored in a config file e.g '4G%67#()!'
• get the user agent string + ip + some unique info -hashed with the salt
• Will return 'd3^7(+33=' for e.g.

This is the salt key you send to the form as per previous steps. so even if the attacker has sees the key he cant use it , as he will need your salt key which is stored on an never leaves the server

Answer 1

Your solution is not going to slow down the attacker. The original problem occurs only when the attacker can sniff the data. In that case he can also configure his network card to read all the messages on the connection, no matter to which IP they were sent.

The attacker can listen to a user, then send a fake submit with the same IP and read the answer which was sent to that IP.

As you already know, using SSL is the only solution that actually works. I guess that if an hacker can sniff your data he can also overcome your tricks easily.

Note that if you're trying to hash the password with php, the hash will be done only after the password will arrive to the server. In that case, it's irrelevant because the HTTP request contains the original password.

UPDATE

It does not matter how you're going to do it, if you assume the attacker can sniff your data and he knows your algorithm, without SSL, you won't be able to stop the attacker nor give him a hard time. If it was possible, people might not pay the extra cash for the SSL.

When investing money and/or time securing your site you should consider if the damage you want to prevent will cost you more than you invest in security, if so, invest the time and money, otherwise, leave it.

Hashing passwords with salt is enough to keep the original password safe, which is far more important than securing the user's account in your site, because, people often use the same password in many sites.

Answer 2

You describe two different stories in your question.

1. The password is hashed client side: If that means that you do not hash it server side again, this scheme is not safe. You hash the password on the server, because otherwise an attacker can login as soon as can read the hashes in the database (Sql-injection). More information about client side hashing you can get from this question.

2. A token is passed to the server: There are two scenarios which come to my mind. 1) A man in the middle has no need to calculate the token, he can just pass the token he gets from the client to the server -> no advantage. 2) If the attacker controls the client he can create those tokens too. He will receive the necessary java-script and because the java-script must be able to read the "salt", he will have access to the salt too -> no advantage.