Let’s encrypt it all

It’s almost impossible to get customers or investment without having encryption in place for both your product on the internet and where you store your data. Note that encryption can be a very deep rabbit hole, so what’s discussed here is only at a high level.

And similar to a core tenant of privacy, the best way to protect sensitive information is to not store it in the first place.

The first thing customers will see is your website. Every browser out there will show warnings if your site isn’t being served over HTTPS, which is when your website is encrypted over the internet to prevent malicious changes or eavesdropping.

Over the years, HTTPS has used a few different encryption protocols to help keep the connection secure, with TLS 1.2 being the current minimum standard. To make it fun, there’s even a long list of cipher suites within TLS that can improve the connection security. And to make it even more fun, TLS 1.3 is out in the wild, but it might be a while before it becomes the recommended minimum baseline.

Basics to get started?

You must use HTTPS with at least TLS 1.2 to encrypt your web service over the internet. For bonus points, it’s highly recommended to use what’s known as modern or recommended ciphers within TLS 1.2.

Put your website’s URL into the SSL Labs testing tool to find out more details. They do a deep dive into your domain to see if it aligns with HTTPS best practices and provide recommendations to help boost your score.

What’s next?

The world is slowly moving towards TLS 1.3, but based on the time it took to enforce TLS 1.2, this may be some years to come. In the meantime, you might as well get ahead of the curve with TLS 1.3 as most providers support it already.

The next best thing is to start digging into the browser headers that complement TLS. There’s a laundry list of them to go through with advantages and disadvantages for each of them. Put your website’s URL into the Security Headers tool to find out more details and learn about which headers are recommended. Take your time with these since some may be too restrictive for your product and break functionality. The site layout and results output are very similar to the earlier mentioned SSL Labs tool.

What does Kinde do?

We’ve set up all our public-facing web services with limited ciphers on TLS 1.2 and also support TLS 1.3. The team has also tackled all of the security headers that make sense with our web application so far. Our goal is to keep at least an A grade on the SSL Labs test and the Security Headers test.

Storing your data safely is critical. This section will focus on two high-level concepts, encryption at rest and field-level encryption. Our example will use a database service since that’s usually where the most sensitive data is being stored. And note that these are huge oversimplifications.

The default is usually to enable encryption on the server or database storage, which is usually called encryption at rest or full disk encryption. On the OWASP Cryptographic Storage Cheat Sheet, we’re looking at filesystem and hardware level encryption. If an attacker steals the physical or virtual disks, then they won’t be able to decrypt them without the keys. The main benefit is ease of implementation since the encryption is usually transparent to the database service and also allows the database to query and index the data easily. And to be blunt, doing this makes it easy to tick the box that says you encrypt your data in a security survey. The drawback here is that this won’t prevent an attacker from viewing the data if they can connect to a running system through stolen credentials or poor network access controls.

The next layer is encrypting the data before it gets written to disk, generally known as file or field encryption. This requires the attacker to have access to the decryption keys even if they connect to a running database instance. Much more difficult to steal the information, even if they have a copy of the database. The drawback though is that your application needs to handle most of the encryption work since the data is being scrambled before it gets stored. It may also break your ability to search the data quickly without some magic since the fields need to be decrypted first.

Basics to get started?

Enable encryption at rest on your database instances and everywhere that supports it. Most cloud providers make this a fairly trivial task and will help you manage the keys.

What’s next?

Begin by investigating whether you can encrypt the most sensitive data types before writing them to the database. This will likely be done on a case-by-case basis. Some data needs to be easily searchable, which means encrypting it could be prohibitive. A common example is the storage of credit card numbers, which must be encrypted at the field level. You probably don’t need to search for specific credit card numbers like you would search for a person’s name.

What does Kinde do?

Our database instances are all encrypted at rest using AWS KMS. The data we’re storing currently needs to be quickly searchable, which means we’re not using any form of field-level encryption. Looking into the future though, we’ve already planned out how we can utilize field-level encryption for future data types that may contain sensitive information.