Best way to store a key for Rijndael cipher 1

[BenRussell]

I am using the Rijndael cipher (utilizing CBC) to encrypt credit card numbers to store on a server (in the future).

However, I was wondering what the best way is to store the key for the encryption/decryption. I thought of simply storing it as plaintext in a MySQL database where my web application can then get it from the database and apply the cipher. Is this the best way?

- Ben

 

[lullysing]

Are you actually serious ?

I hope the server with the MySQL database does not get taken over, for all your customer's sake.

on the minimum, never put CC data or the key to access them on the same server as one serving internet accessible services, that's just asking for trouble.

_____________________________
when someone asks for your username and password, and much *clickely clickely* is happening in the background, know enough that you should be worried.

 

[BenRussell]

Thanks for the advice. What advice would you suggest for this task?

- Ben

 

[theoxyde]

It would help to know what the CC# is being stored for (e.g., customer convenience or future reference). Who needs access to that information will determine the kind of strategy you will need.

 

[BenRussell]

For instance, I know that eBay stores credit card numbers for recurring/automatic billing of their sellers. I would be using the credit card numbers for this same purpose: recurring billling but not necessarily in the same amount each month.

- Ben

 

[theoxyde]

Well, if you are going to encrypt the CC#'s, then you will want to store the keys on a different db server from the data. There isn't a perfect solution to storing encryption keys, because it has the same problem as storing unencrypted data.

At some point in the line you must have a storage location that you can consider to be "trusted". That doesn't mean that it has to be perfectly secure (no such thing), but reasonably secure. That is where the keys need to be stored. Why not just store the CC#'s there to begin with? Because, like I said, there isn't any perfectly secure system. If someone manages to walk out of the building with the "trusted" system (or its hard drives), they have a large collection of keys, but no locks to try them in. How you create that "trusted" system is up to you, but don't let anything have the ability to talk to its database without going through your application (TCP channel, .NET Remoting, web service, whatever).

Our key servers, for example, are isolated from the rest of the network via a firewall dedicated to that application. The database is accessed via a very small .NET remoting application proxy, and that port is the only thing the firewall allows through. Users are authenticated through digital certificates. At one client location, I have an application service that actively re-encrypts data randomly. It runs fairly constantly at off-peak hours and effectively re-encrypts everything in the 1.5 TB database every other day (more imporant data is re-encrypted more frequently). So, an information thief would need to comprimise both the key server and the other database servers within a very short time to get anything valuable at all. The certificates used to authenticate users aren't stored at all, but are derived from the user-supplied credentials.

That is probably overkill for most applications, but it may give you some ideas for where to begin. Or, as my lead programmer often tells me when reading my diagrams, "I still don't know where to begin, but now I know where to give up."