January 30, 2009 at 3:24 am
Hi all,
I'd appreciate any advice here!
A client wants to take payments over the web. They can process payments in their office and so want to have their site users c.card data stored in the database until payments are processed. I'd just like to know the best way of doing this in terms of security.
Usually we use the big online payment players like Protx, World Pay, Pay Pal etc but this isn't an option in this case.
We'll have a 128-bit SSL Certificate running on the site when the payment details are passed to the db but I'm not sure of the best encryption method to use. I was looking at setting up an AES Symmetric Key with separate password on the SQL Server but would it be best to encrypt the data before we pass it over to the db or will the SSL do the job on that?
Cheers for any help you can give.
Some spec info - The DB Server is separate to the website server and firewalled to the max. Only the webserver itself can access the db on the internal network and standard port and the connection is a db_reader/db_writer account.
January 30, 2009 at 4:47 pm
The SSL certificate allows you to have an encrypted connection for your web site. It doesn't encrypt the data to the back-end. So it doesn't enter into your decision.
The question is whether or not to encrypt before the database (which would occur on the web server) or at the database. If you can trust your DBAs, you can encrypt at the database. If you can't, you can encrypt at the web server level. Generally, you're going to be safer to encrypt at the web server level if you're worried about how many people have access to decrypt the data.
A better option would be to use a three tier model. The first tier is the web application. Let it do the encryption. Also get a common or familiar name for the credit card. A lot of sites do this. Pass the familiar name and the encrypted credit card information to the second tier, which is the SQL Server your web server has access to. That SQL Server should have a linked server connection to the third tier. The SQL Server should be able to execute a stored procedure or INSERT into a table on that third tier. A similar operation needs to be available to "delete" (but this will usually just entail marking the card inactive). No more access is needed.
The second tier can store the order information, shipping address, etc. It will also store the common name for the credit card. But it will not store the actual credit card contents, even in encrypted form. Rather, it ships the credit card information and the common name to the third tier, where it is stored.
The third tier should never be directly accessible from the web site. Should an attacker take over your web site, they have it and your second tier. But if your second tier can only write data to the third tier, not retrieve it, which means should an attacker compromise a web site, he or she could get new information, but they could never get stored credit card info.
K. Brian Kelley
@kbriankelley
January 30, 2009 at 4:53 pm
I didn't see the forum, but if you're using SQL Server 2000 (not 2005 or 2008), then encryption HAS to occur at the web server level unless you use a 3rd party tool. SQL Server 2000 has no built-in encryption.
K. Brian Kelley
@kbriankelley
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply