Forum Moderators: phranque
I have a registration form that asks for a user name, password, and email address. When the user enters the requested information and clicks the "Register" button, I do a JavaScript procedure that takes the password and creates a triple MD5 hash of it, and then submits the user name, MD5(MD5(MD5(password))) password hash, and the email address to my server. Note: the actual password is never stored or transmitted.
When the user wants to login, my server generates a login form which includes my server session ID, along with the user name and password input fields. When the user fills in the input fields and clicks "Login", another JavaScript procedure submits the user name and MD5(triple password hash + session ID) to my server, which then compares the previously stored (registration) triple password hash and current session ID with info from the login form submission, i.e. client side MD5(triple password hash + session ID) to server side MD5(triple password hash + session ID). If they match, the login was successful. Note: again, no actual password is stored or transmitted, and the form data is only good for the current session.
I'm not a security expert, but I am interested in knowing the risks I am taking using the above methodology.
Note: the actual password is never stored or transmitted.
Unfortunately in your setup the actual password is transmitted and stored. The "password" which gives access to your site is the 3xMD5() text. This text is clear, i.e. unencrypted sent over the internet and stored in the same unencrypted form. You are right that the user-typed password isn't sent over the net, but that one is not needed to access your site. Any hacker sniffing the data packets can filter out the unencrypted username and MD5 translation. Furthermore, any hacker that gains access to your login-database will find an unencrypted list of usernames and passwords he can use on your site.
The only way to stop password sniffing in your setup would be an SSL connection with a certificate.
The purpose of the 3xMD5 password encryption is to prevent the sniffer from ever being able to discover the user's original password, which users will often use in may places, even though they shouldn't.
The only time the pure 3xMD5 encrypted password is ever sent over the internet is during the registration process. The login process sends MD5(encrypted password + server session ID), which is of no use to a sniffer because it is only good for the current session.
If someone hacked into my server and got the users password hashes it would only compromise my own application security, which has already been compromised by the server hack.
But, I will have to think more about securing the registration process.
Thanks again for your input! If you have any suggestions for a simple way to secure the registration process I would be pleased to hear them.
My registration / login doesn't need to be ultra secure. I only intend to use it for some forum software that I'm developing, but the more security I can simply deliver, the better!
By the way: What happens when javascript is deactivated? The form will then be transmitted to the server with all information in cleartext.
Does HTTPS and SSL prevent you from being hacked?
Does HTTPS and SSL prevent keystroke gathering spy ware / viruses?
A security system is only as secure as its weakest link. I'm not trying to discount your very good suggestion, I'm just being realistic about the relative threats to internet security vis a vis my registration / login procedure.
I probably should look into HTTPS and SSL, but can you tell me if most web hosting companies offer these services, and do they add additional costs to your hosting plan? I don't recall ever going to any forum that uses HTTPS and SSL.
