3

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 ?

user670800
  • 1,107
  • 1
  • 11
  • 16

3 Answers3

6

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.

Community
  • 1
  • 1
Sean Vieira
  • 155,703
  • 32
  • 311
  • 293
  • Client side hashing is an extra layer of security (however small) and is safe _if_ you use a different algorithm and salt. Of course using the salt stored on your server would be insecure for client side hashing. – Matt Mar 26 '13 at 17:42
  • And in regards to your example salt, that is okay for a basic hash on the client side, but for server-side hashing a salt should be much longer. Often advised to be as long as the output of the hash (eg. sha512 outputs 512bits or 64 bytes, so your salt should be 64 bytes). If you need to add computational expense, hashing thousands of times increases login time for users. You would be better to use an algorithm like [bcrypt](http://bcrypt.sourceforge.net/) or similar. – Matt Mar 26 '13 at 17:43
3

JavaScript sends whatever you tell it to send. If you aren't explicitly hashing the passwords via JavaScript, then they are being sent in plaintext to the server which is hashing them.

I don't think it would be a great idea to hash on the client side, though, as that would be revealing your salt to anyone who looks at your JavaScript. Also, users without JavaScript enabled won't be able to log in.

Hash on the serverside.

As for the security, it doesn't make a difference. The second solution makes it twice as hard for a bruteforce hacker to find your passwords (as they would have to generate two hashes instead of one), but as long as nobody knows your hashes, you don't have to worry about that.

But if you are really worried about security, hash with SHA256. Google "md5 collisions" to see why MD5 is not the best hashing function to use (it is one of the fastest).

Blender
  • 289,723
  • 53
  • 439
  • 496
3

If you want your connection really secure use SSL. If your data isn't critical hash your password on the server. You can hash it on client but your hashed password and salt might be compromised anyway, so easy password can be bruted.

mpen
  • 272,448
  • 266
  • 850
  • 1,236
bjornd
  • 22,397
  • 4
  • 57
  • 73