If it's symmetric, then doesn't an app vulnerability make it possible for you to leak your key? Then the app also contains access credentials to the DB, so vulnerabilities in the app will still lead to real access to the DB, right?
Yes, we're not protecting against the app being attacked, the key being jacked and then the attacker getting access to the db. Rather, we're protecting the database against being accessed directly. That could happen due to an error in configuring network access to the database or another service could be compromised that has access to the same database -- as has happened to many mongo databases over this year.
So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries.
No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive.
And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.
I could see a use case to see which emails are from what TLD.
For instance, all @gmail, all @yahoo, all @aol.
Maybe you want to do the cool "hey we noticed your email on haveibeenpwnd, you should change you password here just in case". In which case, anything other than plain text could prevent that from happening.
Hashing an email in that sense gets much more difficult, no?
If you have enough emails that you can't SELECT * FROM users and do that query in memory, you're probably in a spot where you should not be picking security advice from a blog like this.
(That's not a negative as to this blog, it's really good and I've recommended it to multiple clients already, but that level of acumen should already be assumed at that scale. If you don't have it, this blog post is insufficient.)
