Originally, this article was titled “Encryption at Rest is a scam”. The intention was to argue that encryption at rest often instills a false sense of security to buyers, and therefore is scamming them into assuming a product has “military-grade” protocols. However, the title was also admittedly very clickbait; I believe the content of the piece is still a worthy topic, so this is a rewrite against the feedback.

Encryption at rest has become a buzzword. This isn’t to argue that encryption at rest is a bad thing, just like how “in real-time” isn’t a bad thing. It’s rather that, especially in context of database security, encryption-at-rest is a table-stakes, not impressive, feature. In other words, this isn’t a call to not use encryption at rest, just to stop relying on it.

Unfortunately, developers often rely on encryption at rest as a gold standard security measure. It’s become a “Look how secure we are!” advertising bullet to win the hearts and minds of security-minded buyers. If you’ve raised eyebrows at “military-grade encryption” marketing before, you know exactly what I’m talking about.

Encryption at rest protects companies against the least common—and trickiest—attack vector: physical theft of hard drives. And it tends to overshadow more critical security measures like encryption in transit and encryption by proxy.

Before going any further, I want to double-triple-insist that the takeaway here **shouldn’t be that we should disable encryption at rest. It’s that encryption at rest is overrated and over-trusted.

Quick recap—how encryption at rest works

Encryption at rest uses a secret key to reversibly encrypt data stored in a database. More technically, encryption at rest invokes special hardware functions to encrypt data before it is sent to physical hard drives for storage. When that data is retrieved, it’s decrypted first using the same hardware techniques (in reverse).

There are various encryption at rest algorithms, but when companies tout “military-grade security”, they are typically referring to data encrypted using the AES (Advanced Encryption Standard) algorithm. AES uses a provided key to encrypt data, using the same key to decrypt it (also known as symmetric encryption). AES uses a series of shifts and XOR computations to encrypt data so it’s virtually meaningless without the key. AES replaced DES (Data Encryption Standard) after DES was consistently shown to be breakable using a brute-force attack.

AES is very fast since some CPUs (such as x86) have dedicated AES opcodes. This makes encryption at rest introduce minimal overhead. The exact hardware does influence encryption at rest’s exact impact, but the results are generally within an order of magnitude.

How Encryption at rest differs from other popular encryption techniques

Encryption at rest doesn’t compete with encryption in transit. The latter just ensures that data is encrypted while it’s bounced between possibly nefarious Internet nodes to hit a destination. They use wildly different encryption techniques; encryption in transit isn’t symmetric, so the dispatching server doesn’t know the private key.

However, encryption at rest does partially compete with encryption by proxy, where data is encrypted by a trusted intermediary endpoint using hardware-supplied, software-inaccessible keys. But even with encryption by proxy infrastructure, companies will often enable encryption at rest since some data might not be pre-encrypted for identifying or search reasons (such as an entry ID).

Encryption at rest used to be a bigger deal

Before AWS, Google Cloud, and Azure dominated the cloud market, companies would build their own servers (or trust smaller server companies). The possibility of an attacker waltzing into an ordinary data center, yanking a hard drive, and selling client data on illicit markets was a very possible attack.

Nowadays, servers have been consolidated into a few major corporations (e.g., Amazon and Microsoft) with massive physical locations. The hard drives housed in these locations are protected by armed guards, biometric-powered security, and limited access points.

Is infiltrating a data center possible? Sure, anything is possible (Sam Esmail’s Mr. Robot isn’t entirely fiction). It’s also possible that a rogue employee could steal hard drives, potentially eluding weight scanners. The risks are definitely there, and encryption at rest should be enabled because of this (unless data is pre-encrypted). But when we read about cyberattacks, 99.9% of them are not happening through a Tom Cruise-level heist, but rather some hacker in a coffee shop casually phishing a SaaS employee.

That 0.1% does happen though, typically when hard drives are recycled but not properly wiped and destroyed beforehand. Recently, this mistake cost Morgan Stanley $35M last year, when 42 unencrypted, decommissioned servers somehow ended up on the illicit market. But it’s a fairly rare exploit. Most “stolen hard drive” security headlines are actually employee laptops that didn’t have hard drive encryption enabled—this happened to AT&T, Coplin, Lenovo, and Stanford.

Encryption at rest does nothing against phishing

Phishing might be one of the oldest tricks in a hacker’s book, but it’s on the rise. Some might believe that the mass adoption of multi-factor authentication (MFA) has stopped phishing; instead, phishing has just evolved, with real-time phishing proxies like Evilginx or Modlishka being capable of beating most instances of MFA with a fooled employee.

If an employee is phished and an attacker accesses their IAM/AWS credentials, their data is in trouble. It doesn’t matter if the data is encrypted at rest—as goes the name, that data is only encrypted at rest. When the attacker pulls data from the database, it’s automatically decrypted just as it would be for any data request.

Of course, if the data was pre-encrypted through encryption by proxy or database access was sufficiently gated from casual access, then an attack might be stopped. But the point is that most SaaS apps, when bragging about security, need to protect against phishing attacks, and encryption at rest (nor encryption in transit) does nothing to stop them.

What needs to “replace” encryption at rest as a security marketing standard

Instead of using “military-grade AES encryption” as a flagship security tout, companies should brag about:

• Mandating MFA, specifically asking employees to use FIDO U2F hardware keys that combat real-time phishing proxy (RTPP) attacks
• Encrypting data before it reaches databases using proxy endpoints
• Healthy encryption key rotation
• Using JIT access controls to minimize access to cloud accounts
• Using secrets managers to protect and rotate API keys

All of these do far more to protect companies from modern attacks than encryption at rest.

To be super duper clear, encryption at rest should be enabled, but it shouldn’t be depended on

Nothing in this diatribe argues that encryption at rest is creating a net negative, outside of it being represented as a be-all and end-all security measure. When I say encryption at rest is a scam, I’m talking about it from the eyes of the purchaser. And given that it’s their data at risk, this is the standpoint that matters.