How should I derive the key and initialization vector for my AES encrypted database entries?

Question

I've built a CMS system to allow users to create and manage online forms on my client's intranet app.

Of course some of the data handled by the forms may need to be encrypted e.g. if the system is used to build a form that handles salary specifics or whatever. So I'm using the AESManaged class to symmetrically encrypt this sort of data prior to it going into our application db.

All is fine, but now, prior to release, I could do with a steer regarding the shared secret and salt.

My original idea was to make a (dynamic) shared secret by combining the (GUID-based) ID of the Form containing the encrypted field with the (again, GUID-based) id of the Question the field is the answer to:

FormId:QuestionId

My Salt is currently generated the same way, only with the order of Guids reversed ie.

QuestionID:FormID.

I'm new to this stuff so not sure if this a sensible strategy or if I should be doing it some other way?

Answer 1

The salt should be a randomly generated value. Its purpose is to make dictionary/brute force attacks more difficult to execute. Wikipedia has a nice article on cryptographic salts: http://en.wikipedia.org/wiki/Salt_(cryptography)

For the shared secret ideally it would not be a value that was stored unencrypted with the data that it was encrypting (such as your ids). It's generally a best practice that the key be chosen somehow by the end-user or admin so that they could rotate it periodically or if some sort of security breach occurred. This password key could be owned by each user of the CMS or perhaps by an admin account. If you have very serious security requirements you could pursue a third-party Key Management Server.

If the main goal here is more of obfuscation and the CMS will not be subject to some form of security audit then something along the lines of your initial idea would do. It would prevent the casual access of the data but would probably not pass an audit against formal standards that would require a random salt, a way to rotate the keys, and a way for the "owner" of the system to change the password such that you yourself could not access the data.