Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Shared server encryption scheme vulnerabilities?

Status
Not open for further replies.

Spork52

Programmer
Nov 20, 2007
134
US
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.
 
If I am not mistaken it is against the law to store credit card numbers... in fact if I remember more it has to be truncated. I just recall having to recode a site that was doing just that and they were sued or taken to court (they were not specific on what happened) but they paid me a lot of money to fix it.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top