When using cloud applications and storing data in the cloud server hosting, you have to trust the company that provides the service, along with all its attendant risks. For some time, this scheme worked without the “side effects”, but that time has passed. A series of break-ins of large and well-protected (at least we think so) services has demonstrated that there is no compelling defense. But that’s only part of the problem.

If we consider the risk in terms of potential “contact patch” – users whose data may be at risk of abduction, it would represent the greatest threat that is not even breaking a particular service, and a compromise of the service provider whose services he uses. After all, not all of the services have their own hardware – many services, in turn, are clients of AWS, Azure, and so on. Maxim about eggs and baskets lucidly explains the riskiness of such an approach.

In fact, the service model, the most popular right now, involves the folding of all the eggs in one basket, then these baskets are added to the other even with more trash. In this case, a large basket is well-preserved and carefully transported, but what if it breaks together with all the eggs? This coarse analogy still conveys the reasons why I believe that security needs to be improved not just by the basket. There’s already done most of what could be done. Now, is it possible to make the shell stronger? And is there such a possibility?

Perhaps you have already guessed what I am referring to – data encryption on the client side. With this approach, the data arrives at the server of service provider which is encrypted and the encryption key is stored on the server. And the key, in turn, is encrypted passphrase which is generated from the user’s password which is not stored on the servers. Thus, to find out what is stored, the cooperation of the user is required. Thus, this not only reduces the risk of loss of sensitive data in the event of a breach – without key attackers catch nothing – but also the service itself separates itself from liability for the stored information is completely shifting it to the users.

The average user will not be able to remember long enough passphrase. Without this, the password recovery methods cannot be implemented.

However, the developers are aware of difficult task ahead of them, and do not try to bite off more than can chew. In particular, the provision of reliable encryption is only a browser – not an easy task that faced most developers. The main focus is on the difficulty of unauthorized access to a remote server and the information that will be stored there, and the protection of transmitted data from being intercepted. Another potential problem could be unification. If it would be a “de facto” standard, then the discovery of vulnerabilities in its protocol will jeopardize everyone who uses it. But the same applies to all open-source libraries that are used in a variety of software products. There is still not a product or platform, but it can be a solution to long-standing issues and will surely attract attention.