Secure design or waste of client resources?
I am building a website with an authentication system. When a user registers on the website or logs onto the website the password is hashed via PHP and inserted or compared to the hash in the database.
My question is should I pre-hash the password before it is sent to the server using JavaScript or is it unnecessary and thus a waste of client resources?
I would not call it waste of client resources, just a waste of your time, use SSL as it does exactly that and its fast, along the side with that what is the point of doing it on the client side? more secure you think? if the traffic got intersepted the stuff could be decrypted as this method is not immune to the man in the middle attack, nor a fast and a really secure method is available using javascrips. but then again i could be wrong.
ADIGA wrote: if the traffic got intersepted the stuff could be decrypted Hashes can not be decrypted. As for the initial question, in a very beginner-like manner, yes, it would be more secure… in a way. Would it be a good thing to use? No. Firstly, by doing this, your hashing method of choice is revealed. While this should technically not be an issue as these methods ought to be designed to withstand attacks by people familiar with the method, it is still good not to have it public. Secondly, you shouldn't hash passwords unsalted and if you do use salts, hashing before sending would mean that you send the salt with the page. Not good for pretty much the same reasons as stated in point one, but also because since you do not yet know which user it is since they aren't logged on, you'd have to use the same salt for every user (not optimal). Otherwise you would first have to establish which user wants to log in and then send their personal salt (in which case anyone can find out anyone's salt), also very much not good. Lastly, since you let the user supply just a hash and compare it to a table of hashes, it equates to storing passwords as plaintext since if traffic is intercepted or the table of hashes are revealed, then anyone can bypass the js hashing and just send any hash and log on with it without even having to know what is behind it.
What this breaks down to is that in the case that you want people to be a tiny bit safer against others knowing their plaintext passwords, then it would provide some manner of protection, but only for mitigating consequences of password reuse. What you should do, however, is to not hash them before sending it; use an encrypted method for establishing communication and sending information where public and private keys exist and can be used (such as https); and finally, use a goddamn salt (preferably different for each user) once you hash it server side. Alternatively, use the aforementioned secure connection together with client side hashing (sans salt), but hash the hash itself with salt on the server's end as well.
Summary: don't use your idea, it's pretty stupid.
The Ripper wrote: Just to clear things up my plan was to hash it using one algorithm then hash the hash using a different algorithm server side. This would still be vulnerable to MITM attacks. While it would be hard for the attacker to get the plaintext password, the intercepted hash could just be sent to the server to log in. SSL is the way to go for secure logins.