Modern Data Security for Developers

The drip, drip, drip of data breaches during the last decade now seems to be turning into a steady stream. Almost weekly another well-known company must come to the microphone to tell their customers—who entrusted them with their personal data—that their data has been revealed to the world. This is both embarrassing for the company and potentially dangerous for the consumer.

It doesn’t need to be like this.

One thing you never hear about is somebody’s credit card being stolen as it gets transmitted from a company’s user interface to its servers. That’s because for the last twenty years or so, transport layer security (TLS) has been standard and automatic in web browsers. Website developers don’t need to think about it, and more importantly, you don’t need to think about it. As long as the little lock icon ( 🔒) appears next to the website address, you know your credit card is secure when being transmitted to the server. That is, it gets encrypted in the browser in a way that it can only be decrypted by the server. Even if somebody got hold of the data while it was being communicated to the server, they couldn’t do anything with it because it would essentially be gibberish.

So how does this relate to all of these data breaches? Well, the data described in the previous paragraph is data in motion as it is being transmitted from one place to another, and almost all of that category of data is automatically protected by encryption. The data being leaked in data breaches is data at rest being stored on a file system or in a database, and most of that data is not protected by encryption. Rather, companies have relied on firewalls and other security techniques to keep bad actors from accessing the storage system, which works much of the time, but not all of the time. If, on the other hand, the data being stored was encrypted, it wouldn’t matter if it was leaked to the public—it would essentially be gibberish. You could post it on Twitter, and it would still remain secret!

So why isn’t most stored data encrypted? There are several reasons, but one of the biggest is that there has been no easy and automated way for an application developer to do so. Each developer essentially needs to build encryption into their application’s data flow by hand, using technologies they are not very familiar with. First they need to acquire and manage a key to be used for encryption (often accompanied by an onerous bureaucratic process), and then they actually need to encrypt. And if they manage to do that successfully, they still need to figure out how to later decrypt and process the data securely. In short, it’s too hard, so most developers don’t do it.

This is where Cape Privacy can help.

Cape empowers developers to easily encrypt and store data, and later process it securely. The developer doesn’t need to know anything about cryptography, and they don’t need to manage encryption keys. Encryption can be done on the client side, using the language the developer is already working in (e.g., JavaScript, Python, etc.). The developer can then store the encrypted ciphertext wherever they want to, knowing that it is safe from prying eyes—even if a data breach occurs. When it comes time to process the data, the developer can easily deploy and run their own functions inside of Cape’s secure confidential compute environment, which is the only place the encrypted data can be decrypted for processing. The secure compute environment is called an enclave, and it guarantees the data is being processed by the function the developer wrote, and it protects the data from any outside access while it’s being worked on.

As a common example, let's say your online store wants to solicit and store a customer's credit card information, making repeat purchases more convenient for them. The only sure way to keep that information secure while it is being stored on your servers is to encrypt it the moment it is collected. With Cape, that encryption can easily be done in the user's browser, before any data is transmitted to your server and stored in your database. A few lines of JavaScript code in the web page encrypts the card number before it leaves the browser:

<script type="module">
  import { Cape } from 'https://cdn.skypack.dev/@capeprivacy/cape-sdk';
  const cape = new Cape();

  // Add an event handler to the form submission
  document.querySelector('form').addEventListener('submit', async (event) => {
    event.preventDefault();

    const cardNumber = document.getElementById('cardnumber');
    
    // Encrypt the cardNumber
    const ciphertext = await cape.encrypt(cardNumber.value, { username: 'myusername' });

    // Replace the plaintext cardNumber with the ciphertext
    cardNumber.value = ciphertext;

    // Process the form normally
    document.querySelector('form').submit();
  })
</script>

The data is safe from data breaches while being stored (because it is encrypted), and it is safe from data breaches while being processed in the future (because processing occurs only in a secure enclave). It is both easy and effective.

So if you’re a software developer, do your company a favor: encrypt all sensitive data that you collect and store, and only process that data in a secure container. While your customers may never know that you’ve taken these extra steps to secure their data, your company will never need to be standing at that microphone explaining why millions of customer’s private details were exposed to the world. That’s a job well done!

Check out the Getting Started Docs to try Cape for free. We'd love to hear what you think.

Header image from: blogtrepreneur.com/tech