与Zend合作时在数据库中存储加密电子邮件的最佳实践

Question

I'm using Zend Framework with a LAMP stack. The client has requested protection of sensitive data, email included. In this project, emails will be used in two ways: for sending automated messages and for sending newsletters.

Has anyone worked with this? What algorithms are fast, reliable and can be used with a variable encryption key? Where should I store the encryption key? What engine should the database table use?

Answer 1

Ok, these are my 2cent.

For data that needs to be both encrypted and decrypted on the fly, I would suggest symmetric key algorithms, and the first that comes to mind is Blowfish . It is both fast, and relatively safe.

As to the variable keys. Usually there is little to no merit in having a different key for each entry that needs to be both encrypted and decrypted. Thus, I'd recommend using a single key, that is set in config file somewhere.

If you do need to have a key for each of the users/records, I'd recommend not keeping them in the db. Save them to flat-files on the disk.

As to table engine, it should not matter which one you choose, as long as it's not memory based.

---

As to merit - I think there is merit, if the client specifically asks for it. Even if there is technically little reason to create this encryption, this will contribute to the clients feeling of safety. Sure, it could be a false one, but it does help keep the data a bit more safe, and lets the client sleep more soundly. Therefore, if the client asks for it , go for it!

Answer 2

If you really have to do this, the answer Janis Peisenieks gives is a good starting point.

As far as I know, there's no safe way of storing keys in PHP - this means that an attacker who gets a moderate level of control over your system can retrieve the key from a config file, and use that to decrypt the data.

An attacker who wanted to know the email addresses of your users would have several options to retrieve that data - as GordonM writes, if your system sends email to those users, that email is relatively easily to intercept, and whilst the body may be encrypted, to "to address" is not.

Just checking that you will be hashing (not encrypting) passwords (if your system uses these?)