Is Client Side Encryption a Security Risk?

User Security Risk

If you are sending sensitive data over the internet, then it is important that you know that the data is encrypted, because it is quite trivial for malicious web users to ‘sniff’ data that is being sent over the web – especially if you are using a wireless connection, or going through an unknown proxy server.

Server-side encryption is useful for a lot of things, such as saved passwords, but the problem with server side encryption is that a)the data travels to the server in an unencrypted form, and the server then processes that data and stores it. You, as a user, have no idea what the code running on the server does. The code could, in theory, save an unencrypted version of the data – or send it to a malicious third party – before writing the encrypted version to the database.

Client side encryption prevents that by encrypting the information that the user submits BEFORE it is sent to the server. This means that there is less risk of the data being intercepted and read on the way to the server and that the server can’t see the raw form of the data either.

When it is well-written, client side encryption is a nice additional layer of security – however, it is not perfect, and implementations can be flaky at times. Given that there are alternative options – such as sending data over HTTPS (so that the packets are encrypted on the way to the server anyway), the benefits of client-side encryption are questionable. It is harder to implement, and most web users don’t really understand what it is, so even if you tout it as a part of your privacy and security policy, it won’t really do much for public perception.

Remember, also, that client side encryption for passwords is not fool proof. If you hash a password on the client side, then the hash becomes, for the purposes of the server, the password – so a hacker who wants to access a user’s data could bypass the website and send a direct request with the hash (or a collection of hashes in a brute force attack) to get access to the user’s account.

It may save users from a scenario where they keep re-using passwords from site to site and your site gets breached (Since the attacker would know the hash, but not the underlying password), but that’s a small and hard to sell benefit.

The best solution is to use as much security as possible. Individual layers can be breached, but if you have multiple layers of security that will deter casual attackers and script kiddies. If you are unlucky enough to attract the attention of a determined attacker, then nothing will save you if the attacker is truly skilled and has the time to devote to breaking through your security measures. Even big platforms such as WordPress and Magento, which have armies of developers devoted to them, occasionally get breached.

Client-side encryption is not a replacement for server side encryption and it was never intended to be. However, as an extra layer – used in conjunction with HTTPS and server side encryption, it is something that is worth considering. Together, they will serve to protect your user’s data, and make it that little bit harder for an attacker to access your customer’s details. They will also serve to limit the amount of damage that is done in the event that your server is breached, and you end up with a potential PR disaster for your IT team to deal with.