I am trying to understand what information are needed to be sent in a web application . Basically I have a web app running on a web server , a database which has a user table with hashed password and salt , and of course the web client with javascript enabled.
When a user login at the login , the user name and password are entered on the client side. I want to know what information are sent . Does the web client sent the password in plain text ,or does it use javascript to hash the password WITHOUT the salt and sent the hased result ? Or does the client fetch the salt in plain text from the server , and then the client sent the hased password+salt ?
What is the best way to hash , and to hash with salt ?
Is MD5 ok as a hash ? How does hash( password_plain_text + salt ) vs. hash(hash( password_plain_text ) + salt ) , where + is a string concatenation ?
When the browser sends over the data you provided it sends it over in a format which most likely matches the requirements of the RFC(s) for the protocol it is communicating with the server over.
In the case of an HTTP connection, the user name and password are sent in the clear (that is, in plain text) to your webserver.
In the case of an HTTPS connection, everything sent to the HTTPS-enabled server by the client (after the handshake) is encrypted – once it arrives at the server it is decrypted. Whatever software stack you are using on the server side should handle this transparently for you – so you will be dealing with data in the clear again.
In either case, you should always hash passwords that you are storing. The reason is not to keep the password as it goes over the wire (i.e. between the client and the server). The reason is to keep the password safe in your database — the safest way to keep a secret is to not have one to keep.
Hashing on the client side is not safe at all, as it exposes not only your chosen hash method, but also your salting mechanism (and, for a compromised client, the actual salt value.)
As to the best way to hash … choose a decently secure hashing algorithm (one of the SHA family should do the trick nicely) and a dynamic salt (one that is different for each user, such as date of join and every other letter of their email address). If you want to make it more secure, hash the hash a few (thousand) times. This way, even if you should have your entire database stolen, it will take a significant amount of work to expose even a small percentage of your passwords, thus saving people who reuse passwords some serious headaches.