Fair enough. I more meant that after an attacker has achieved RCE, no amount of encryption or other practices can protect sensitive info in your database.

Why does the webserver need access to All of the Datas? Store the data separately, and create use-tokens for webservers to access data once users have authenticated.

The webservers should be treated as if they're potentially compromised, not given arbitrary access to a database...

Encryption can't save you, but other practices can.

Specifically: if you're working with a lot of very sensitive information, you structure your application such that there are multiple layers separating that data from the outside world. In the case of Equifax, that might mean implementing the "credit score check" as an internal service exposed through the public web servers (or whatever).

Exactly. While nothing can completely stop attackers, there are multiple techniques you can layer to slow them down. E.g:

* Credential vaults that allow only-once retrieval on application startup and only keep credentials in memory

* anomaly detectors for request patterns (suspicious payload formats, processing time, CPU/memory usage, etc),

* Honeypot records in sensitive data stores (records you know should never be accessed, if they are you've been breached)

If you're storing information this sensitive you need to be paranoid, because an attacker has a $4B incentive ($30/identity on the black market * 143 million records) to crack your systems.

No you have to use other architectures for defending against that. Equifax sells queries to this data, they also use queries to that data as a trigger to change your credit rating. It seems like you'd want a very tightly audited mechanism for issuing these queries to make sure they are properly billed. Referring to it as a struts issue makes it sound like someone popped a web server, fired up a dub client and started dumping unencrypted tables.

It seems amazing that nothing tripped up some monitoring or something.