First off, I have posted this question in forums on other sites. Is that considered bad for(u)m?
I'm working on a web commerce site that is hosted on shared servers (Windows IIS, ASP, SQL Server, and a shopping cart which uses a cart_id session and database tables to store user info and cart contents as the user shops). My client wants to store credit card numbers, so that they can be retrieved and used to process failed and pending transactions (not all of which have been posted to the payment gateway). I don't want to do this, but I've sketched out a possible encryption scenario to protect the data. I have no doubt it is insecure on shared servers, but would like to know why, and whether it would be secure on a dedicated web server combined with a shared SQL Server. Here it is (assume an SSL connection):
When the user begins a session he is assigned a random symmetric key (RSK) which is stored as an ASP session variable. When the user submits credit card info via a form the CC# is encrypted using the RSK. The RSK itself is encrypted using a public asymmetric key (PAK). Both the encrypted CC# and encrypted RSK are stored in the order record. Now, as the user cycles through the purchase pages, the CC# can be retrieved (so that it doesn't have to filled in over and over again if the user makes a form entry mistake in, say, his email address) because the unencrypted RSK is available in the session variable and can be used to decrypt the stored encrypted CC#. And later, when the store owner wants to retrieve the CC#, he can do so by supplying the private asymmetric key (PSK) to decrypt the stored RSK which can then be used to decrypt the CC# (although I'm not sure how to implement this part in a secure, yet convenient way).
The point of all this is that no keys are stored on the web server (except the PAK which is useless to the hacker). And, even if someone miscreant gets his mitts on an RSK, it is only good for one CC#. Although, if one can be got, then probably many can.
Hope that makes sense. I suspect that the session variable is somehow vulnerable and/or the hosting company's employees would be able to eavesdrop on the traffic and get a hold of the keys.
I'm working on a web commerce site that is hosted on shared servers (Windows IIS, ASP, SQL Server, and a shopping cart which uses a cart_id session and database tables to store user info and cart contents as the user shops). My client wants to store credit card numbers, so that they can be retrieved and used to process failed and pending transactions (not all of which have been posted to the payment gateway). I don't want to do this, but I've sketched out a possible encryption scenario to protect the data. I have no doubt it is insecure on shared servers, but would like to know why, and whether it would be secure on a dedicated web server combined with a shared SQL Server. Here it is (assume an SSL connection):
When the user begins a session he is assigned a random symmetric key (RSK) which is stored as an ASP session variable. When the user submits credit card info via a form the CC# is encrypted using the RSK. The RSK itself is encrypted using a public asymmetric key (PAK). Both the encrypted CC# and encrypted RSK are stored in the order record. Now, as the user cycles through the purchase pages, the CC# can be retrieved (so that it doesn't have to filled in over and over again if the user makes a form entry mistake in, say, his email address) because the unencrypted RSK is available in the session variable and can be used to decrypt the stored encrypted CC#. And later, when the store owner wants to retrieve the CC#, he can do so by supplying the private asymmetric key (PSK) to decrypt the stored RSK which can then be used to decrypt the CC# (although I'm not sure how to implement this part in a secure, yet convenient way).
The point of all this is that no keys are stored on the web server (except the PAK which is useless to the hacker). And, even if someone miscreant gets his mitts on an RSK, it is only good for one CC#. Although, if one can be got, then probably many can.
Hope that makes sense. I suspect that the session variable is somehow vulnerable and/or the hosting company's employees would be able to eavesdrop on the traffic and get a hold of the keys.
