| Author |
Topic |
|
Kristen
Test
22859 Posts |
 Posted - 2005-07-19 : 10:35:31
|
What would you suggest for encrypting credit card numbers in a database column (two columns in fact, the CV2 number too)?The application is an ASP website hosted on IIS.SQL Server is likely to be on the same machine, but might be on a separate machine.The ASP machine will be "on the web". (And SQL too if its on the same machine, otherwise the SQL box will be right alongside it - protected from web by firewall, but someone successfully hacking into the Web box would get presumably get enough permissions to talk to the SQL box without too much difficulty?)Assuming that the ASP application makes the encryption it will need to be able to unencrypt too (i.e. the unencryption CANNOT be restricted to another [e.g. back office] machine NOT exposed to the web).Seems to me that an attack on the web machine could a) attack the database and b) the ASP program. If the Credit Card Number is encrypted in the database then stealling that data gets the hacker nowhere, but its not a large jump to then try hacking the ASP code next - where, presumably, the DES [or whatever] Key would be in plain view?Or am I missing the point and there is an obvious and smart way around this?  ThanksKristen |
|
|
Thrasymachus
Constraint Violating Yak Guru
483 Posts |
Posted - 2005-07-19 : 10:48:55
|
| use a secure socket layer (SSL) for the web pages transmitting the sensitive data. this will cover the transmission from the remote client to your machine. on top of that I would store the data in the database using a third party component that impliments public key encrytion. on top of that I would secure your backup with a password and encrypt those. I have not done this but I believe it is possible to store the public key in the registry of the web server.and if they get through all of that (which is possible) we might as well give up on e-commerce until the really smart people deliver quantum computing.Sean RoussyPlease backup all of your databases including master, msdb and model on a regular basis. I am tired of telling people they are screwed. The job you save may be your own.I am available for consulting work. Just email me through the forum. |
 |
|
|
Thrasymachus
Constraint Violating Yak Guru
483 Posts |
Posted - 2005-07-19 : 10:56:57
|
| Or you can create a COM\ActiveX component that handles the encrypt\decrypt and you can stick your public key in there. The component would be compiled and there would be no source code access. The source code for the COM component could be stuck somewhere safe and encrypted with pgp or something. This is what I did a couple of years back. My COM dll accessed the dll with the RSA cypher. Worked out.Sean RoussyPlease backup all of your databases including master, msdb and model on a regular basis. I am tired of telling people they are screwed. The job you save may be your own.I am available for consulting work. Just email me through the forum. |
|
|
|
uberman
Posting Yak Master
159 Posts |
Posted - 2005-07-19 : 11:32:45
|
| Another option...you may be able to get away with storing the CC number encrypted so that only the user can get the number back, in other words, will you need to know what the credit card number is apart from when you are processing a transaction?e.g.encrypt the CC using a user supplied pass phrase, and you dont store that pass phraseto decrypt the user has to then supply the pass phrase again (you would do this as suggested over HTTPS)so you never store the information required to decrypt the CC anywhere.it all depends when you need to access the CC number.Most of the time you only need the CC number if you going to process a transaction, in which case this will work perfectly.So not even YOU can read the CC numbers you have stored. This way a nasty person can walk off with your IIS server, your database server, your com components and even your source code and still not have the information needed to directly decode the encrypted dataof course, if you DO need to be able to read the CC without the direct permission of the user at that point in time, this wont work, but it might be worth giving some thought to what you actually need to store and when you need to read it. |
|
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2005-07-19 : 12:25:12
|
| educate me....what would happen ifYou encounter some poor (nasty) user, who wishes to repudiate his transaction....and won't cooperate by supplying the 'pass-phrase'...for you to prove he/she really did authorise the trans....or a merchant who wishes to do likewise? |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-19 : 12:38:43
|
| Some handy stuff there Sean, thanks.The problem is that in the past we have processed the credit card "there & then". We then "store" the credit card with the middle replaced with "*****" in case we need to confirm the card used subsequently etc.Now a client wants to transmit the "orders" periodically to their Order Processing system (i.e. in their office) and have that do the credit card processing.That's all fine, but I want to secure the credit card details whilst we have them.When we generate a page for the back office users to check the user's order [which is, of course, SSL] or we want to generate an EDI file to send to the Back Office system, we need to unencrypt the card details. THEN we can replace the middle of the number with "****" ...A COM object sounds like a bit f work, but maybe the best approach. We'd need to make the COM object only work on the machine it was installed on to prevent that being useful when stolen too.Not sure that putting any of the keys in the registry is more secure than putting it in the code - instead of the code sayingMyKey = 'FooFoo'it will sayMyKey = GetFromRegistry('BarBar')Kristen |
|
|
|
uberman
Posting Yak Master
159 Posts |
Posted - 2005-07-20 : 04:09:25
|
| >>educate me....what would happen ifnot saying there aren't issues with the technique, just that there are ways to store encrypted information in the database where even the database owner is going to have difficulty/impossibility getting access to it.Which could be a good thing/bad thing but is was worth considering... well, up until the bit about storing the CC numbers and then doing a batch transfer. Oh well. |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-07-20 : 11:38:52
|
| We use two third party products for encryption in the database.1. XP_CRYPT provides extended stored procs that can be called from functions to encrypt and decrypt the data. Ir provides various encryption and hash methods. We use AES encryption because it is fast and strong; AES is accepted by the US Government for top secret doocuments.2. SQL Shield allows you to encrypt the code of functions, procs, and views so that you can hide how you access the encryption keys, or just encrypt your code for any reason you want.Their web site is:http://www.activecrypt.com/products.htmlCODO ERGO SUM |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-20 : 14:11:04
|
| Thanks MVJ. Seems to have the same problem of protecting the key - unless, as you suggest, we also securely encrypt the SProcs etc. (which I'd be keen to do anyway, TBH)Not a cheap solution at, including redistribution, $7,000 or $650 a pop :-(Kristen |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-07-20 : 15:12:42
|
I think that key management is the weakness of most encryption systems. I didn't really spend a huge amount of time designing a system to protect the keys. I tried to reach a good compromise betweeen security and ease of use. For obvious reasons, I will not go into the specifics.The AES encryption that we use appears to be immune to brute force attacks for even short strings like credit card numbers. I ran a test where I encrypted the same credit card number a million different times, and it produced a different ciphertext each time. Because of this, it is important to make sure that you maintain the keys, because you will not be able to decrypt it otherwise. Obviously, lookups on encrypted columns cannot use an index.Another thing to be aware of is that the cipertext will be 2-3 times longer than the plaintext, so if you are encrypting a lot of data, you need to plan for additional storage.quote:
Originally posted by Kristen
Thanks MVJ. Seems to have the same problem of protecting the key - unless, as you suggest, we also securely encrypt the SProcs etc. (which I'd be keen to do anyway, TBH)Not a cheap solution at, including redistribution, $7,000 or $650 a pop :-(Kristen
CODO ERGO SUM |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-21 : 01:51:52
|
| Thanks MVJ. The 2005 stuff looks interesting - permissions on the certificate revoked from the user but granted to the SProc seems like a reasonable plan.Kristen |
|
|
|
|
Encrypting credit card numbers