Why hash and encrypt on the client side?
Whenever you save a password on your server you should hash that password with salt.
This is great but the raw users password hits your servers before you get to hash it. With the recent revelations about the NSA fiber splitting content from the net (and asking for the SSL keys), it does means that this password could be unsecure.
By hashing the password on the client side, your server will never know the raw password and only see the hashed value. This raw password would never be sent on the internet lines so any middle man attacks would never know the true password.
You should still hash the password again on the server side before saving it anywhere in a database.
Read my previous post on how to do this: http://glynrob.com/php/hashing-and-public-key-encryption/
What if you wanted to offer a service where all user data is stored encrypted. Offering the encryption to take place on the client side gives them more security.
They can see that the real data they save is never sent to you, only in encrypted form and the password used to decrypt it is never on your server or shared with anyone.
If the NSA or any agency/hacker asks you to decrypt the data on your service, it would be impossible for you to do so.
If your user forgets his password, then they are out of luck as you can not set a new password for his content to be decrypted.
TNO = Trust NoOne
How to I Hash and Encrypt on the Client side?
Perfect, this is what we need, BUT…
It is not ready. It is still being worked on so we can not use this until it is completed.
So instead I try these 3 libraries:
I recommend Crypto-JS as it is the easiest to use for hashing and encryption
Working example of my code can be found at: http://glynrob.com/examples/client-encryption/
Full code to download is available at: https://github.com/glynrob/client-encryption
As you can see, PolyCrypt is the more complex one to generate and CryptoJS is the easiest.
Also PolyCrypt doesn’t generate the same hash even though all of them are using SHA-256. This wouldn’t be a problem if you always stayed on PolyCrypt but if you ever change libraries then all previous passwords would fail.
I would recommend not using PolyCrypt due to this reason.
My example shows:
Sending this hashed value instead of the users password is now a secure way to validate a user accessing your system.
Due to ruling out PolyCrypt earlier I won’t go into its encryption but it is available on github.
CryptoJS provides the quickest results I have found.
Now sending the encrypted string to the server means that you never know the data that you are storing, and it can only every be decrypted by the password set by the user.
If you know of any better libraries or implementations, feel free to add them below.