[aeronautic]

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.

[swsieber]

It does seem like emails are a good fit for encryption. I can't see wanting to do anything more than simple equality checks.

[thatwebdude]

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?

[eropple]

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.)

[edraferi]

This is an interesting solution, thanks for sharing. This would be a cool feature to build into open source ORMs.

[EGreg]

This is a good idea, but only for fields which can never be used in range based index lookups.