Client and Server side password encryption in Java

Question

I am making a small social network website using Java/JSP. I want to have passwords encrypted and then stored in database. I want to know is it nowadays needed to encrypt passwords client side using javascript (sha1,md5,..) and then send it to server or it is safe enough to ignore client side and just encrypt passwords at server side.

Answer 1

You need to transmit the passwords between the client and server via TLS (SSL). Then, use bcrypt with a cost factor of 16 or more (or PBKDF2 with 64k iterations or more) to hash the password at the server.

Answer 2

If you do not use SSL then there will be security holes with doing client side encryption or hashing in Javascript since a man in the middle attacker could just remove the client side hashing code before passing the page on to the user.

If you do use SSL then there is little to be gained by implementing additional client side security. The only scenario where it would be a benefit is where an attacker can compromise the encryption but not the integrity of the stream (so they can only sniff the data). This seems unlikely, but it is possible.

The additional security to prevent this would require that you first hash the password to match how the server has it hashed (so including the salt), and then hash that with a server provided randomly generated token (that the server also remembers in the session). This ensures that the password cannot be obtained by someone sniffing the connection (provided that the integrity of the stream is not compromised) as well as ensuring that the hashed version cannot be used in a replay attack (random server token prevents its reuse). If you only hash the password by itself client side then there is nothing to prevent an attacker from just using that hashed value to login themselves. Remember, this is in addition to SSL, not in place of it.

Regardless of how the password is transmitted, you should only store a salted hashed version of the password in your database. Ideally using a per user salt (that you store as well), and a secure hash function (SHA-2 for instance instead of SHA-1 or MD5).

Answer 3

The best way to do it is use:

1. SSL
2. Client and Server side encryption.

Option 1 is usually enough, however it can still be sniffed and thus it can be useful to send a hashed/encrypted version. This sent version shouldn't be what you store in the database though, it should have some kind of other entropy.