1

It is not advisable to store email addresses in databases in plain text, so I would like to find out the best algorithm to do this. Options are:

(From the documentation)

  • CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).

  • AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197.

  • BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.

  • DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.

  • DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

Another questions is where should the key be stored? In the database or in the source code? Will it be encrypted or not? If it will be encrypted, then the question raises of how the key that will encrypt the key be stored.

Should it be stored in the source code, will sourceless distribution be good?

Leigh
  • 28,765
  • 10
  • 55
  • 103
n_kips
  • 585
  • 11
  • 20
  • 2
    I'm curious why you think it is inadvisable to store an email address in plaintext. – Jason Dean Jul 21 '11 at 19:01
  • 1
    I agree, make sure you are not just cargo culting the idea that its inadvisable. – Cody Caughlan Jul 21 '11 at 21:06
  • It's for privacy. Should the security be breached, at least they will have to crack another layer before getting the encrypted data. Please read these: http://bit.ly/pkrOG0 http://tgr.ph/nneofZ http://bit.ly/lYdU03 http://bit.ly/nVm3EX – n_kips Jul 22 '11 at 09:07
  • Sorry, but I don't agree that those articles offer any evidence that it is a good idea to encrypt email in the DB. Are you going to encrypt first and last name too? Home address? Zip Code? Phone? Maybe just encrypt everything in your users table. But all you're going to accomplish there is slowing down your application. You could encrypt at the database level. That would help protect data from some compromise without greatly affecting performance. – Jason Dean Aug 05 '11 at 16:18
  • The the main ones that needs to be encrypted are emails and passwords. I sure would not want my email to be publicly disclosed (spam) like http://dazzlepod.com/lulzsec/final/ – n_kips Sep 28 '11 at 22:13

2 Answers2

8

I would use AES. it's the fastest of those listed and the strongest.

As for where to store the key, that is the $64,000 question. You should not put it in the DB (At least not in the same DB as the data it is being used to encipher) or in your source code.

Key management is a beast of a topic. NIST has hundreds of pages of documentation on ways to do it.

http://csrc.nist.gov/groups/ST/toolkit/key_management.html

Key Management involves proper generaton, exchange, storage, rotation, and destruction of keys. You should not use the same key forever (a very common mistake) nor store it improperly.

You should take a look at the NIST guidelines and determine a strategy that works for you and adequately protects your data based on its sensitivity.

Jason Dean
  • 9,585
  • 27
  • 36
0

Use AES or DESEDE - they're strong and in my experience have a lot of wide compatibility should you need to port this information for some reason.

As for the key, this isn't REAL critical data. Typically you would create a compsite key out of a unique piece of information for that data (like the userId) and a private key (salt) such as a constant in the code base:

Somewhere in your global settings / constants : 

 <cfset myCodeBaseKey = "NateIsAwesome">

Then when you're ready to encrypt:

 <cfset myKey = hash(myCodeBaseKey & user.userId, "SHA")>

P.s. it works better if you use that exact salt phrase I hear. :P~

Nate
  • 2,881
  • 1
  • 14
  • 14
  • Down-voted because I think this is terrible advice. Saying that the key is not critical is not only wrong, it is completely opposite of the truth. The key is the most important part (assuming a strong algorithm) in the cryptosystem. And using a non-random, easily deduced key is a terrible idea. – Jason Dean Aug 05 '11 at 16:26
  • The key is a hashed composite of a unique piece of information and a private key - not easily deduced or reversed. also, you misunderstood the statement "this isn't critical data" - that was referring to the fact the data being secured is an email address. – Nate Aug 05 '11 at 16:36
  • "Easily deduced" meaning that if you know how to create one, you know how to create them all. Unique != random. I'm sorry that I misinterpreted what you meant by critical data, I agree that the email address is not critical data, but if someone is going to go to the trouble of encrypting something there is no point in using a weak key over a strong one. – Jason Dean Aug 05 '11 at 17:41