Safest storage of secret keys

[Aegis_Kleais]

In the process of developing our intranet, we are storing SSN information as well. Since this is confidential, I want to make sure I take the best practices in safe-guarding it. So how would you go about doing it?

I was thinking I could use GenerateSecretKey() and then use Encrypt with AES, but my problem arises from, "do we store the generated secret key in the database?) Or is it better to use a value in the DB we hold on that individual person for a key?

I understand that if I store it in the DB, then additional security measures include having to close off who gets access to reading data from database tables, and that's understandable, I'm just trying to devise the best COLDFUSION-related practices for storing confidential data.

Cause in the same manner, if someone had access to read CF page code, they could see something like:

<cfset mySSN = Decrypt( strHashedValue, users.key, "AES" ) />

And figure out what was being done (so I have to ensure FILE based security as well, but again, just within the realm of CF, what's the best thing to do?

[Dan_Bracuk]

use cold fusion encrypt to generate the value that you store and cold fusion decrypt when selecting it.

[Aegis_Kleais]

I can use Encrypt( string, key, "AES" ) and Decrypt ( string, key, "AES" ) but what's the best way to store the key? In a database? If I use GenerateSecretKey() how do I know how many characters the key will be at most? And how can I tell how many characters the encrypted value will be?

MD5 Hashing always results in a 32-character long string right? That may be an easier way.

[Dan_Bracuk]

Hashing is a one way street. You can never select an unhashed value.

[Aegis_Kleais]

OK, I may have used wrong wording, sorry. Where/How should I store/create the key?

[Prasanth_Kumar_S]

Hi,
You can encrypt the cfm page using encode utility so that file is readable only by cold fusion.

Prasanth

[Dan_Bracuk]

Cold Fusion encrypting does not have a key. You store the encrypted value and select a decrypted value. Of course, you'll need Cold Fusion to decrypt it.

[Aegis_Kleais]

OK, I'm confused here.

Encrypt requires 2 parameters. The value to encrypt, and a key. The key can be any data I have for that user or I can use GenerateSecretKey() to make a key for me, but either way, a key is required, and I'm looking for how to best store that key.

I tried running Encrypt without a key, and sure enough it erred, saying 2 parameters were required.

[Prasanth_Kumar_S]

Well, I was referring to the cfencode utility. The exe file must be in the bin directory of the CF installation path. You can use this utility to encrypt a single file or you can use cfcompile.bat in the same directory to compile the code to byte code so that the file is readable only by CF.
Prasanth

[Aegis_Kleais]

OK, but this still does not help me.

I want to store data in a database, and I want it ENCRYTPED (so if someone read the database, they'd get the encrypted value) That's easy enough to do, but the CF Encrypt function requires a key, understandably, and if I made a field called "key", it would be simple for the to take that value, and in a couple tries devise that they could run Decrypt ( encryptedValue, key, [optional algo]) and they would get the value.

I guess I didn't explain my problem, but I can't really figure out how to explain it any differently.

[CTek-Media_com]

Here is how I have done this in the past - but there might be better methods with CF8.

Yes you have to have a key. It is vulnerable. It should be stored off the web root in a file (with locked down permissions) or on a separate database preferably on a separate server. I use a file. CFinclude (or otherwise externally reference) the key into your encryption / decryption code. You don't want to hard code the key into your encryption / decryption routines directly because if that code somehow gets exposed in an error message (which shouldn't happen with catch/try but.....) then your key would be exposed.

Make sense?

You are banking on the idea that it is very unlikely, assuming you have good security practices, that a hacker is going to crack your DB AND the file you have the key stored in.

No security is perfect.