Best algorithm to Encrypting / Decrypting a string & Key storage method

1
votes

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?

2
encryptioncoldfusion
I'm curious why you think it is inadvisable to store an email address in plaintext. – Jason Dean
I agree, make sure you are not just cargo culting the idea that its inadvisable. – Cody Caughlan
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: bit.ly/pkrOG0 tgr.ph/nneofZ bit.ly/lYdU03 bit.ly/nVm3EX – n_kips
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
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 dazzlepod.com/lulzsec/final – n_kips

2 Answers

8
votes

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.

0
votes

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~