4 ideas about securing user data in web applications
by WWPass, on Tue 21 November 2017
In the modern world, more and more applications move to the cloud, or to be more specific,to somebody else's servers. Common solutionnowdays is to make an application a web service, accessible from any modern browser. This solution has its upsides and downsides. One of the downsides is that the way your data is read, modified and stored is not under your direct control. Problems with data security, accessibility, integrity or unauthorized access may lead to huge losses for the data owner, either financial,reputational or emotional. The web service provider usually cares about the data up to the price users pay for the service, plus some reputational costs, but that's still less than the value the users have to pay when their data is lost or compromised. This can be mitigated in various ways.
#1 Back up your data
Backing up your data is always a good idea, especially if you make sure that this data can be restored from the backup. This requires some cooperation from a web service, but most services usually allow you to download your data in an open format. And if you are developing such service, provide users a way to back up their data.
#2 Restrict unauthorized data with encryption
But preventing unauthorized access is different. The data has to be stored somewhere at the web service provider, or at some other service provider, if they outsource data storage. It has to be parsed and processed by the server software, then sent over the internet to authorized clients and then parsed, processed and displayed by the browser. And when the user enters new data it has to go all the way back. For anyone who would like to steal the data, this is a pretty big attack surface. The usual answer to this is data encryption. And the actual user can do little about it. This is where the web service developers have to do it well.
#3 Secure your encryption keys, too
But just encrypting the data is not enough. It's essential to keep the encryption keys safe. The data is no more secure than the keys used to encrypt it. Data in transit between different computers is usually secured by Transport layer security (TLS) protocol. TLS uses some clever cryptography to exchange one-time (session) keys between communicating parties. The connection between the user's browser and web service is secured by HTTPS, which is just the regular HTTP done over TLS. The most important thing for the user there is to make absolutely sure that the connection is secure (a green padlock is displayed near the website address, for example) and the domain name is not misspelled. Even this may be not enough, but there's little the user can do about other vulnerabilities.
Software security is hard. The second problem is where to store the encryption key. The web service should be accessible from any browser. Storing keys on the server or along with the user's data negates almost all the benefits from client-side encryption. The only thing that is consistent between different sessions is the user’s credentials for authentication. Deriving a strong encryption key from the user's credentials can be hard, depending on the nature of those credentials. Weak passwords are a good example. It's possible for a server to limit the number of authentication attempts, block suspicious activity or require authentication from other factors when someone tries to guess the password for authentication. But if someone tries to decrypt the data, the number and frequency of password guesses is limited only by available computing power.
#4 Take extra care against errors along the way
TLS takes care when it comes to data in transit. Stored data can and usually should be encrypted as well, especially if it's stored outside of the server that's using it. To use the data, the server has to have a key to decrypt it. And if the server is sufficiently compromised, the key would be compromised as well. To solve this, one can encrypt the data at client side and have the server deal with an encrypted data.
While the idea is sound, actually implementing it securely is rather hard. First of all, some of the data is needed at the server side. The essence of the service requires that the server has access to at least some of the data. This makes both frontend and backend security much harder to implement, because the data becomes fragmented and has to be carefully processed each time it enters and leaves the client side. In addition to increased costs to develop the system, this process introduces complexity and significant room for error.
Therefore, service providers must consider each stopping point along the way of data transfer and storage for true security. While encryption is often the answer, you must also secure the encryption keys in a way that won’t be easily exploitable by attempts to crack the encryption.
Want to know more about keeping encryption keys secure for your users? Contact email@example.com.