> I disagree with the dishonorable mention as you've only considered the naive case which you can build upon to avoid the issues mentioned. Consider a design wh

> I disagree with the dishonorable mention as you've only considered the naive case which you can build upon to avoid the issues mentioned. Consider a design where everything is AES-256 encrypted in the application and the database just receives an encrypted binary. You can build an in-memory cache for situations where you need to search sensitive information (first name, last name, ssn) by using a tokenizer and using a technology like Erlang term storage. It will be eventually consistent which should be fine for our use case since that type of information does not change that often and the cache recompute can be done asynchronously. https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt... https://blog.filippo.io/the-ecb-penguin/ https://blog.filippo.io/the-ecb-penguin/ There are defensible positions for which ECB mode is acceptable. I wouldn't classify the scenario you described as one of them. > If someone gets unauthorized access to the server you are already screwed since your application can get access to the plain text data in order to serve requests. If someone gets unauthorized access to the webserver, yes, it's game over. If someone gets unauthorized access to the database server, and it's a separate machine from the webserver, then your analysis here isn't applicable. That's the threat model alluded to in the beginning of the article, but if it's not your threat model, then you may reach different conclusions about the best way to protect data. (You may not even use encryption, for example.)