[TedDoesntTalk]

> a hacker could still compromise a system that has the key in memory.

Security is about layers. Simply because a hacker “could” do something, does not mean it’s a bad idea. Getting the encryption key when it’s not stored in the database requires the hacker to now have access not to just the database but to another system as well.

[gregmac]

This is an excellent point, but there's nuance to it.

This seems like an acceptable solution for email and a lot of other PII. However, if you were to propose the same thing for passwords, with the same argument, I'd be dead against it -- even beyond the total lack of need for the system to ever have the actual password. I'm not quite sure how to explain this, though.

[TedDoesntTalk]

There’s no reason a company needs to know your password. But they do need to know a way to contact you.

[blantonl]

Invariably some developer would just store the key in a column next to the email address so they could process any transaction directly in the query.

But the hackers would have to know what algorithm was used :) That's a layer, right?

[TedDoesntTalk]

> some developer would just store the key in a column next to the email address

I think that depends on where you work. Process. Code reviews before allowing merge/pull requests can help.