New MongoDB field-level encryption can help prevent data breaches

MongoDB has released a new version today featuring field-level encryption (FLE), a new mechanism that protects sensitive information stored in a database even if attackers compromise the database itself or the server it runs on.

MongoDB 4.2’s FLE implementation does not involve storing keys or performing any encryption and decryption operations on the server. Instead, these operations are performed by the MongoDB client library, also known as the driver, which is used by applications.

From the server’s perspective, the ciphertext — encrypted data — sent by the client is just another type of data to store in a field. This means that even if the server is compromised, or if the database is left exposed to the internet with weak or default administrative credentials, attackers won’t be able to steal any sensitive information that has been encrypted. However, FLE will not prevent data destruction attacks that are possible if attackers gain administrative access to a database.

In the past, hackers have compromised tens of thousands of publicly exposed MongoDB and other types of data stores. Some of those attacks led to serious data leaks, while others were used for ransomware-style attacks. MongoDB and other types of databases are also constantly targeted by brute-force password guessing attacks, also known as credential stuffing.

Change the MongoDB driver, not the application code

On the client side, the new FLE is transparent to the application, because it’s handled by the MongoDB driver, not the actual application code. This means that in many cases application code does not even have to be changed for the new feature to be used, Kenneth White, product security lead at MongoDB, tells CSO. Developers only need to update the driver.

Some changes have also been introduced on the server to warn the client applications if they’re trying to write plaintext data into fields marked for encrypted data, but ultimately the clients are authoritative. To benefit from this advisory feature, it’s best for users to update both the MongoDB client library and the server.

In many ways, FLE works like end-to-end encryption, where the two endpoints are different applications that need to store and work with sensitive customer data. The implementation actually uses authenticated encryption to prevent certain cryptographic attacks.

“We’ve built in some defenses for things like intentional manipulation or corruption of the data, like with pre-message or padding oracle attacks,” White says. “We’ve used modern algorithms that are resistant to such manipulation attempts.”

Regulatory compliance benefits

FLE also helps companies comply with regulatory requirements, like the General Data Protection Regulation (GDPR) and the right to be forgotten in the European Union. Once the keys associated with a customer are destroyed, the data on the server and in all applications is rendered useless.

The new feature also allows companies better control over who has access to sensitive information. For example, in most cases, server and database administrators have unrestricted access to databases and that can represent a privacy or security risk. Even if organizations have policies in place that ban IT infrastructure teams from looking at sensitive customer data, there are usually no technical mechanisms in place to prevent it. FLE can help enforce such segregation of duties, letting administrators manage database clusters and the server infrastructure without having the keys to decrypt the data.

The new FLE feature is targeted at industries like healthcare or finance that have regulatory requirements to protect certain types of customer records. However, as a core privacy feature it can be useful to any company, White says.

It’s also worth noting that because the encryption is handled on the client side, there is no additional performance impact on the server. Furthermore, the keys can be stored separately, in an external key manager.

MongoDB’s field-level-encryption workflow

Here is how MongoDB explained the FLE encryption workflow:

1. Upon receiving the query, the MongoDB driver analyzes the query to determine if any encrypted fields are involved in the filter.
2. The driver requests the fields’ encryption keys from the external key manager.
3. The key manager returns the keys to the driver, which then encrypts the sensitive fields.
4. The driver submits the query to the MongoDB server with the encrypted fields rendered as ciphertext.
5. MongoDB returns the encrypted results of the query to the driver.
6. The query results are decrypted by the keys held by the driver and returned to the client.