Data Encryption - SQL Server

sist_si

sist_si

sist_si

Associate
Joined
28 Nov 2004
Posts
1,237
Location
Birmingham
Hi guys,
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.
 
I would never even contemplate such a scenario; I'd always use a 3rd party. Bus as you've already mentioned, your client has existing system that they want to use.

I wonder though, does the payment system they use off-line not have an online component or service? You may find their payment handler will offer such a service alongside their existing arrangement.

Assuming not, I'd rely on SSL. We've all got too much riding on it already, so I don't see why you wouldn't trust it in this case.

So if SSL covers us from client to webserver, I would therefore encryt the data explicitly on the webserver before the call to the DB. Although it is very difficult (and thus very unlikely) it is nevertheless possible for someone on the inside to intercept the communication between the webserver and the db server.

Further more, I'd limit all db accounts to EXECUTE permission only, and thus only allow interactions via SProcs. You assign the web server db account permissions to write credit card numbers, and use a different db account at the back-end that is allowed to retrieve the CCard numbers. If anything, the web server will be the first to be cracked, so simple remove it's ability to retrieve the important data.

What we are talking about here is layers upon layers of security. I'm sure some top-secret governmental organisation could still get past much of it, but in general you are trying to make it all but impossible for an external attacker or an internal 'mole' to gain easy access.

It's a lot of responsibility, hence why we farm this responsibility (and risk) off to 3rd-parties, but I know I'm preaching to the converted here... :)
 
i've been playing around with encryption on SQL server and I have something up and running...well, nearly.

Here goes....I'm using a master key on the database with a certificate and symmetrical key.
I have a stored proc called with my website db_reader/writer login which I 'execute as' a db_owner Login I created which in turn is set to 'Deny' connect permission to the database engine in its properties. I'm hoping this stops anyone from the web trying to login with db_owner permissions....I really do hope it does :)
While executing, my stored proc (as the db_owner) I grant control of the certificate and view of the key to my website user, encrypt and insert the data then revoke the certificate and key privilages.

How does that sound?!
I'm just really worried about having to use that db_owner user but I tried and it doesn't seem to let me connect with it as I planned.

Any advice!
 
To be honest, I'm not sure how to advise you. The stakes are high and unless you have experience in this area, you are liable be learning as you go along.

I'd re-iterate my point that the link between your web server and your DB server is arguable vulnerable. Bearing in mind that the web server is the weak spot, I'd a) make sure that the web server only ever as a write capability to the CCard data and that data is encrypted between the web server and the DB server - I assume that the web server is either in a DMZ or outside the local network infrastructure?

I can see the thinking behind your approach, but to be honest, I couldn't begin to predict whether it would be good enough.
 
From a recent USENET post:

"At Amazon.co.uk, credit card information is stored on a computer that
is not connected to the Internet. When credit card information is
received, it is sent to this dedicated computer via a proprietary
one-way interface. The information is not stored in any other place.
Access to the information is restricted and, when accessed, logged."
Click to expand...

The key bit being one-way.

So encrypt all communications to the DB, and only allow writes to that part of the DB.
 
Cool. Cheers cjmUK. I'm in talks with our server host who say they're going to investigate the best ways of doing everything at issue here.

They say the communication between our web and db server is private so no one should be able to access it but we'll see what they find.
 
You must log in or register to reply here.
Back
Top Bottom