Credit Card Security

Credit Card Security

Old forum URL: forums.lhotka.net/forums/t/1891.aspx


Bob Matthew posted on Saturday, December 02, 2006

We are going to be using SQL Server 2005’s encryption mechanism to encrypt sensitive information, such as credit card data.  We’re going to be running the remoting portal in a separate process – perhaps even on a different box from the web servers – the app server’s remoting portal will run under credentials that have the ability to decrypt the data in SQL Server before returning it to the web servers.

We want to insure that the actual credit card number is never, never returned back to the client-side code running on the web servers.  This is simple enough – during the DataPortal_Fetch(object criteria) method, we just make sure that the actual card number is either a) never loaded or b) set to string.Empty or some other value.  But, we still need to be able to actually work with the credit card number itself within the context of the server-side app server code.

My question is this: Is there a way to detect that a method, such as DataPortal_Fetch() is being called from the client code so that we can prevent the sensitive information from being returned?  If not, another easy way would be to have another “non-remoting” method to Fetch/Load/Retrieve the data in order to provide it to the another object running on the app server.  But the problem there is that a really good hacker could analyze the client assemblies and then potentially upload his own new assemblies that made a call to our private load method which would then return the sensitive data.

The only other potential solution that I can think of would be to have a method that doesn’t actually return anything – except perhaps a Boolean or something – that performs all the processing necessary on the card, such as submitting it to a payment gateway, etc.

Granted, this whole situation is very hypothetical and one could say that it’s almost academic because maybe a hacker would just give up and move on – but the whole point of these security measures is to protect the data, so why not accomplish that end?

JonM replied on Sunday, December 03, 2006

I'm not sure if you can tell 100% if you are running on the dataportal or not.  I like the idea of executing a routine that simple returns a boolean for success or failure.  In our projects when we have complicated procedures that need to  run that involve several tables and we usually just custom code that routine into a SPROC instead of involving dozens of business objects.  If you are super paranoid about running credit card code in your business objects you have them call a SQL SPROC written .NET using the new SQL CLR.  I would also recommend using an encrypted channel connect to the dataportal (https://).  Lastly, I would recommend signing all of your assemblies to keep hackers from replacing them with a a 'custom' version.

ajj3085 replied on Monday, December 04, 2006

It sounds like you'd want a seperate business object that does the 'server-side' processing that you want.  You avoid any ugly branch code to either load or not load the CC number as well.

I'd think that if you have the CC number in the db, you'd want a command object which would do the charge or whatever you wanted.

HTH
Andy

Copyright (c) Marimer LLC