Keeping Private Customer Data...Private? 386
"I chose 1024-bit PGP encryption with a long passphrase. I use the Cryptix java package to handle the encryption from a Perl script (the reasons for this are legacy related, but I'm in the position where I can start clean if need be -- a Perl-only solution would be great).
The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)
I have realized for a long time now that if someone gained full access to this machine, they could fairly easily run a brute-force attack on the encrypted data, if they found our secret key on that machine. But when we recently worked on our privacy policy, this potential problem became more important.
What changes could we make to our setup so that we can encrypt/decrypt the credit card information on the same machine that houses the data, while making it as hard as possible to decrypt the credit card data assuming the entire machine was stolen (or cracked)?
We are a very small company. How do "the big boys" handle these things? What is the best book on this particular subject?"
While this setup may work well for credit card numbers, what about setups that will protect other personal information like a customer's address and phone number? Would such information be practical to obfuscate in such a manner?
Why store cc# at all? (Score:3, Insightful)
Websurfing done right! - StumbleUpon [stumbleupon.com]
Re:Why store cc# at all? (Score:2)
Re:Why store cc# at all? (Score:4, Interesting)
Re:Why store cc# at all? (Score:3)
You store the last four digits and ask for the full number at refund time. It's what the big chain stores do...look at a receipt; it'll typically have on it the last four digits of whatever card you used. You have enough information to know which card to accept for the refund, but not enough that a disgruntled/dishonest employee (or the 1337 h4X0r who just 0wn3d j00) can do something bad with it.
Re:Why store cc# at all? (Score:2)
If you need to search database by credit card number... just encrypt with public key and use that agianst the database encrypted card number. Same as checking your password in Unix -- a one way transformation. If you do not want to use that -- use 2 16 bit CRC (with different primes) makes a nice one way "finger print" -- very few matches.
Re:Why store cc# at all? (Score:3, Informative)
It's right there in the article.
Re:Why store cc# at all? (Score:5, Insightful)
At my old company, there was a system which handled new CC number entries. As part of a nightly process, they were moved into a database on a separate machine which was only connected for that window of time. All of this was on top of standard security measures. So the biggest risk was having the "temporary" entries compromised.
Use a two-phase query system. (Score:3, Insightful)
I agree. Mod the parent up.
Use a two-phase query system. The main network generates a request for CC #s, and that request is passed on to the CC number storing machine, using a serial cable with the two receive lines cut. The CC number machine answers the query and writes encrypted results to a re-writeable CD. Twice a day someone puts the CD in a computer connected to the main network and runs a program that checks that the results are reasonable. If they are, that computer puts the results in a shared directory. Then someone runs the program that uses the CC #s.
Maybe this is not the best system that can be designed, but something can be designed so that there is no networking connection between the CC number storing computer and the CC number using computer.
If someone breaks in to the main system, they get a maximum of only the CCs being processed that day.
An important feature of any security system is also to make the system difficult to hack from inside.
Re:Why store cc# at all? (Score:3, Insightful)
One scenario is if you discover a card was false after you charged it. It's a lot cheaper to credit the card before the real owner generates a charge back since there is a signifigant fee (for the reseller) attatched. You can't do this if you don't have the number stored somewhere.
2 basic things can help keep the customers secure though.
1: not storing more info than you have to. On this point there is NO excuse for keeping the CVV2 info yet I see people doing this a LOT.
If they don't have the CVV2 codes the card will be harder to use as more credit card companies demand it's use. Use the code to verify the card then forget what it was. (yes I've seen buisnesses store it in the db)
2: properly secured servers with up to date patches/daemons. If the server isn't secure it won't matter how much you use encryption they can simply grab the data as you process it.
Required to keep records for 7 years (Score:2)
However, does this information need to be stored online? No!
Whenever people talk about credit card security I always snort derisively
Re:Required to keep records for 7 years (Score:2, Insightful)
It's economies of scale here, the threat is higher because the exposure is higher.
lamp.
big companies (Score:4, Interesting)
In fact the sole security rests on the passwords and the physical access to the machine.
But our servers are in a secured building, administered by IBM (you should see what it takes just to be able to enter the computer room, let alone trying to stay 1 minute in front of a console without someone asking you what you are doing there...)
Your own response states the problem ... (Score:2)
In otherwords, people outside of the bank have access to that information.
And all it takes is 30 seconds to dump an SQL output of 10,000 CC#/account info records to a flat file on a 1.4M "service patch disk" and out the door they go.
Re:Your own response states the problem ... (Score:2)
With a BIG FAT log of who logged into the console and database and performed the dump, not to mention paper logs of entry if they do that. To tell the truth, there are many things which we could just "walk away" from...but there would be sufficient trail that would lead right back to us, so it would be suicidal (nothing is really physically preventing me from mugging old ladies on the street, but it's still not the perfect crime).
Well .. we could take this further ... (Score:2)
How about planting a program to run in the middle of the night under user X to dump the file in place Y which you would later get. Every situation would be different. How about places which are ran solely by IBM and where the company is lucky enough to do an ls, let alone trying to administrate a DB2 server? Maybe we tell the company were going to do a backup dump of the DB just to be sure we don't loose anything and swipe from thier.
It could be as simple as taking a used backup tape just laying on top of the machine that some operator carelessly layed there.
The point was not if "you" would get caught, but the point that "others" beside a select few bank personal are granted access to the machine. And just because the "room" is secure, does not mean that what is inside of it is.
Again, the attack was not directed at IBM. IBM could have just been as easily replaces with "Ma and Pa's used Blendor and Computer Repair Shop."
Re:big companies (Score:2, Funny)
I don't think that the National Bank of Canada whom have 3 million client can be considered like a Big Bank !
Anyway who can trust a Bank who need IE to access it's "Secure" Internet banking
I wonder... (Score:3, Informative)
A little obfuscation? (Score:3, Interesting)
Microsoft is going to be pissed ... (Score:4, Funny)
Don't decrypt (Score:2, Interesting)
Why do you need to decrypt the credit card number? Once you've encrypted it and stored it in your database, that should be it. It should never need decrypting (by you, anyway -- your financial partner will have a key for decrypting, and if you can't trust them then you have other problems). No actual person should ever see the unencrypted number, nor have access to that number (too much temptation there).
Of course, the very best thing to do is simply never store the credit card. Granted, your business model may not allow that, but it's still the safest option (crackers can't get what you don't have).
Re:Don't decrypt (Score:2)
I just did a transfer function, GnuPG at 2048.
Each end knows the other's public key and that is it. One way transmission.
And just for that warm fuzzy feeling, we compress and use a secondary cypher just to make it a little harder.
Why store secret key? (Score:5, Informative)
I coded a server component that could decide whether a requester could view an encrypted datum (for example, if the requester authenticated correctly) and decrypt it using a key stored only in memory, that had to be entered by a human being to start the server. The humans who could administer the server memorized the key. A small enough amount of data was stored that changing the key was feasible.
This server was in perl, but the encryption/decryption code was in C; I used blowfish (libblowfish) and also stored the key in a C buffer pointed to by a perl scalar, and used the mlock() system call to prevent the key from being swapped--an alternative might be to use OpenBSD where it is possible to encrypt the swap area.
Anyway, I hope that gives you some ideas. Any form of storing or recording the decryption key reduces to storing the credit card numbers in plaintext, so you should avoid that.
Re:Why store secret key? (Score:2)
Well, if you want to get technical, if they rooted the box, they could still presumably walk through memory (ok, encrypted swap would add another level here).
Re:Why store secret key? (Score:2)
Of course, root can still walk through RAM, but there are ways to fix that. I've lately been trying LIDS [lids.org], which adds a more complex permission model. You can make it so that root is normally pretty limited, requiring a separate maintenance password to do anything dangerous.
better idea (Score:2)
Re:Why store secret key? (Score:2)
Re:Why store secret key? (Score:3)
When I firewalled the server I found a backdoor was already on it.
Anyway, are there any far-less-than-perfect-but-even-a-networking-newbi
Oh, to make matters more interesting the server is NT 4 running SQL 6.5 w/ a blank SA password (which must be blank due to
I'll be happy to R any FMs y'all suggest.
Re:Why store secret key? (Score:2)
Wow. Good thing it doesn't get swapped out, then the "print" from gdb might have taken an extra millisecond
avoid the problem (Score:3, Funny)
On a related tangent, here's another question. Do you guys have any recommendations for a low end credit card purchase system requiring low or zero startup fee, but rather charging a per-transaction fee?
Re:avoid the problem (Score:2, Informative)
Re:avoid the problem (Score:2, Interesting)
Surely, you must be kidding.
Re:avoid the problem (Score:2)
They don't have a customer service phone number.
They don't have a customer service email address.
They don't have any customer service at all, except a web form which gets answered in about 3 days, with an unhelpful answer.
Use c2it [c2it.com] or some other service where your money is FDIC insured, treated according to standard federal banking regulations, you can talk to people if you have a problem, and they don't randomly freeze accounts. Additionally, c2it doesn't seem to have any fees for most transactions, so you don't even have to pay the 1% paypal tax.
Re:avoid the problem (Score:2)
I think not.. they just froze our business' account and the money contained in it because my boss' last name is Cuban... Never mind that he lives in Canada with resident status.
Many of the buisnesses we deal with have similar horror stories of paypal freezing money for months with no explanation. The worst case being $750 000 frozen for 8 months of a large processing company.
Re:avoid the problem (Score:2)
Tell me, what color is sky in your world?
Or Let me ask it like This...
What [paypalwarning.com] Color [aboutpaypal.org] Is [paypalsucks.com] The [zdnet.com] Sky [boycott-paypal.com] In [consumeraffairs.com] Your [com.com] World? [salon.com]
key storage (Score:5, Insightful)
According to VISA rules, the merchant is NOT allowed to store the cardnumber - its the property of VISA.
To get around this, I dont store the card. I store its SHA1 hash signature. This is great because you're guaranteed to get a match on the card's record - but you dont have to store the cardnumber itself. This also enables great negative database checking without liability to the merchant. You've got the sig - thats all you need.
The key storage you're referring to is an old problem. The key is never secure as long as it's in software (software can be cracked, reversed,
analyzed...I dont need to explain this). The only secure way is to store it in hardware somewhere.
Re:key storage (Score:2)
So how do you regenerate the card number from the hash for billing?
Re:key storage (Score:2)
Re:key storage (Score:2, Interesting)
Can you point out the source of this? I'm not trying to argue it, I'd just like to know as this strikes me as somewhat odd.
The convenience/computer stores I've worked at in the past have all had credit card numbers printed right on the receipt, which in turn are stored away in secure filing cabinets, etc.
Re:key storage (Score:2)
Is there real safety? (Score:3, Interesting)
Frankly, I'd prefer to just keep typing in my credit card number, or have the info stored on my computer for my convenience. I don't like the idea of my personal data being permanently stored in a potentially insecure remote location.
So, don't store the key (Score:2, Interesting)
Re:So, don't store the key (Score:2)
Stick this in your boot script after creating an empty
Protect the machine (Score:2)
The bottom line is, if you're in the scenario where the data is stored on a single box and is both encrypted and decrypted on that box, and a key is stored there in some (secure) fashion - no matter what, if the box is rooted, the data will be taken.
The solution is to adequately protect the machine from being rooted in the first place, rather than jump through hoops trying to keep root from being able to get the data.
Start by firewalling the machine well. I would recommend OpenBSD if your traffic volume is slow enough for it to handle (no SMP, so it is kinda limited in that respect if you've got big demands).
Lock down the applications - know every port that's open, what protocol is spoken, what daemon is listening, etc... Do some testing of your own - if you can crash any of the box's services by sending random and/or long string of junk to any of the listening ports, you have a security problem.
Secure co-host. (Score:5, Insightful)
You put it on another box, close all of the ports, and have a simple protocol running over something low-level which you trust like SCP or a PERL socket reader.
Your "co-host" stores the secret key, and does all decryption: the main host passes it a datum to decrypt, the co-host decrypts it, and passes back the cleartext.
The key never leaves the box, and the co-host should erase it's copy of the key and shutdown on any unexpected network activity (like an attempt to log-in). If you're really paranoid, have it also look for patterns in the access and die if anything unexpected show up - or return bogus, flagged test data (i.e. a list of bogus credit card numbers in stead of real ones).
Does that answer your question?
Re:Secure co-host. (Score:3, Insightful)
Not perfect security, but done right unlikely to be the weakest link: a determined hacker will root your web server and simply copy all of the credit card numbers as they are used, by backdooring your e-commerce application.
But at least that's a trickle: you lose numbers to him as they are used, rather than your whole database at once. Read Bruce Schnier's stuff [counterpane.com] about all security being target hardening.....
Re:Secure co-host. (Score:3, Funny)
Worker 1: Holy shit Bob, the web site is down again!
Worker 2: Yeah, every time someone enters a bad card number or tries to log into our security box, we lose thousands of dollars, but at least our customer's data is secure!
Re:Secure co-host. (Score:2, Insightful)
You'll obviously want to keep a copy of the encryption key stored somewhere secure besides the machine. Otherwise an attempted hack will quickly make all of your data useless.
Re:Securing the co-host. (Score:3, Funny)
Go/no-go decisions are signalled on the other link, either with simple sense carrier signalling (wire CD to DTR or whatever) or a very restriced set of allowed responses.
Programming the system is a pain in the ass since you have to use the console, but once set up it should be so simple it'll need no other maintenance than backup tape loading.
Any cracker who can figure out how to break your system when you have no net link is so much smarter than you, you're probably doomed anyway!
Re:Secure co-host. (Score:2, Insightful)
Limited performance (Score:2)
You can limit the amount of data decripted (per day and per user). You can limit each user to certain periods of the day. You can enforce frequent password changes everywhere. You can even enforce a certain unrelated routine to be performed (say, daily or at turn shifts) in the exposed box console by a human operator.
Every one of these features by itself is breakable, and each one represents added costs and worse usability. But depending on what you are protecting you will want these and many more.
Re:Secure co-host. (Score:4, Insightful)
Where's the security in that ?
Let's say I r00ted your front-end machine. Why don't I just look at your script or your binary and see that it sends the request over SCP. Or over a PERL socket reader.
You have added a very tiny amount of obscurity, but nothing that resembles security. Your "oracle" has no way of knowing who's asking, if you built the assumption into the system that "anyone who can ask must be in their good right to know".
Even if it's on a private network on another NIC, this doesn't help one bit. I r00ted your front end machine, remember - if the front end machine can talk to the oracle, so can I, when I'm root on the front end.
You may be able to add a little security resemblence with your "anomaly detection". However, it is quite likely that I am smart enough to just see how valid requests are built, before I try my own requests at the oracle.
Re:Secure co-host. (Score:3, Interesting)
That's an OK idea in a theoretical sense, but not from a practical commerical view point. Most applications have a requirement to fail gracefully, and just having your data handler die kind-of sucks from an administrative point of view.
Instead, perhaps a better solution would be to provide a selective lockout mechanism which would block accesses to certain bits of information (those that were trying to be cracked) or access to/from certain clients (a specific web session in the PHP sense of the word.)
Having your entire app die would be the same as if someone (you, in this case) DOS'ed your site. If I was your client, and that was your solution, I'd be hard pressed not to move my business elsewhere.
-buffy
I'm not sure I understand the question... (Score:2)
The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)
I'm not sure I understand the question. Why is the secret key stored on the machine? Is it stored in cleartext? If it is, that's a problem. The trick here would be to encrypt the secret key on the machine using the billing staff's password (or a hash thereof), and only decrypt the key when the password is entered. If you change the billing folks' password, you can re-encrypt the secret key with the new password. That way, you'd at least have to run a brute-force on the password (which may not be that hard, depending on how you pick passwords). An alternative is to use a more secure mechanism than passwords for authentication--something like a keyring dongle or somesuch, but that makes things more complicated.
Old problem. (Score:5, Informative)
A commonly used solution in high-security environment is to isolate the database machine from the network. I.e no network card. You then connect the database machine to the data processing machine via either a serial cable, parallel cable or similer that doesn't have a network stack on top of the driver.
You then have to create a client/server/queue manager on both ends.
Your security problem is now reduced to the functionality of the client/server that talks over the cable and performs requests on the database.
(Assuming of course that you can control access to the console)
A bit of effort, but it works.
Re:Old problem. (Score:2)
Re:Old problem. (Score:2)
Re:Old problem. (Score:2)
How is that different from just using the network stack ?
Granted, it adds a tiny amount of obscurity. But your apps on the front-end will still be using your comms. library, and if I r00t your front-end, I will still be able to talk to the "secure" machine (using your neatly written comms library).
Fundamentally, you change nothing. You add a tiny layer of obscurity, but that's it.
I have the answer! (Score:2, Funny)
On my Palm Pilot.
Learn from the past (Score:3, Funny)
What the Big Boys do... (Score:5, Insightful)
Re:What the Big Boys do... (Score:5, Insightful)
This is the lesson lost on the Slashdot crowd.
Perfect security is impossible, good enough security is possible. Aim for good enough -- if you aim for perfect you will never achieve it and waste a lot of money trying.
Data Integrity and Security (Score:5, Informative)
Usually your database will either be accessed by your web servers directly, or through an application server. Limit access to your database explicity to these addresses, through both the database configuration, and, if possible, IP-level configuration (like iptables in Linux). For each client connecting to the database (be them web servers or application servers) have then use unique password keys (and users, too, for that matter.)
Finally down at the application layer (we've done network, and server layers so far) you need to be more careful than ever. First, do the obvious, don't store sensitive material (read: credit cards) in plain text ANYWHERE. At list build in some kind of cipher key (crypt, if nothing else) that will encode the data in the database. If possible, you may want to look at more elaborate schemes for storing data in such a fashion. Beware, this is the piece of the puzzle that many will spend a lot of time focusing on, which is good, but not the whole shebang. Also note, any fields that you store encrypted, you will not be able to use easily as an index field.
Another oft forgotten place to focus on, is in the tools that you use for manipulating and storing the data. Everything above is worthless, if you have a careless programmer who writes a utilitiy that doesn't sanatize user input prior to executing an SQL query. A tremendous amount of the hacks you see out there are due to tools like these that are very vulnerable to misuse--since they were designed to have the ability to access your data, your security measures are for naught.
Make sure your programmers understand how the data is being stored both in the database, and the computer (ie. buffers, sanatized user input fields, etc...)
These are by no way complete, just thoughts of things I've had to deal with in the past while facing similar issues. Hope they help.
-buffy
one-way (Score:3, Interesting)
Internal access and usage is a policy issue. There is no way to engineer a usable solution whereby a user cannot write down a credit card number and expiry date and begin using it to buy stuff short of policy, enforcement, and legal action. You'll come up with some real Rube Goldberg schemes if you try, but fundamentally, if you must have human contact with the billing authorizations, you have a policy issue, not something you can ironclad by technology.
You will simply have to ensure that only trusted staff (eg. have a vested interest in the company's success) have enough access to do any damage. Technological solutions to social problems are a very poor fit and a very large time sink.
Sorry. We segregate authorization and billing where I work so that I don't have to jump through these hoops anymore. Small-order authentication is farmed out (and with it, the liability) so that our major customers are charge accounts with whom we deal personally in case of a problem.
Don't store it on the same machine (Score:2)
store it on a totally seperate machine.
Basically, you'd write to the seperate machine over a defined interface such as update_customer(customer id, credit card number) pairs), and read from the machine over a defined interface such as verify_credit(customer id, amount).
this way, "important" information is never leaked, operations and data that you want to be secure are placed on a box that doesn't have to run any extra services that can possibly be cracked.
seperate the worlds. (Score:3, Insightful)
internet -> firewall(1) -> web server -> firewall(2) -> database
So, you have 2 firewalls. One internet facing, and one (idealy a different vendor) from the DMZ to the internal world.
Also, you can set up 2 houses for the data. One (the one that the internet can get access too by proxy) should only cache the recent data. Hourly, or nightly, it should then be put into another server, from which the accounting department can run bills. Then this box (for accounting) should have no allowed connection to the rest of the world, save from the accounting department.
Oh, and the important data should be then purged from the internet proxy accessable database.
Why the requirement to decrypt on the web server? (Score:2)
Re:Why the requirement to decrypt on the web serve (Score:2)
You're right; there should be no reason for the web server to have access to the credit card information once it has been accepted. The web server should absolutely not be the machine in charge of the recurring billing.
The point which has not been stressed enough here is that if the web server has any method of retrieving the credit card information, then it doesn't matter how many layers of encryption, how many layers of firewalls and semi-isolated machines connected through obscure cabling techniques you use, all of the information an intruder needs to access it is sitting right there on the web server.
If an intruder has root access to the web server, (a not-uncommon occurrance these days,) then it won't matter how complicated you've made the protocol for accessing the information; all he has to do is trick the server into getting it for him.
The only 'solution' to this problem is not to give the web server any access. Use write-only media, like public key encryption with no private key, a network connection to a machine which will not give the data back, or use a physical line printer and have someone re-key the data later.
Delegation (Score:5, Insightful)
Perhaps a little security through obscustiy... (Score:2)
Perhaps...
Make a credit-card server that communicates over an odd port - you give it a customer id, customer name, and a pass-phrase and it return the credit card number. The server would only allow one query per minuit or so (depending on need) so gaining access to the entire list would require a customer name list as well as a lot of time.
Ofcourse, if the server detects more than a few bad names or a few bad customer Id's then it locks itself down. If it detects a bunch of sequenctial requests that are customer name sorted or customer ID sorted, then it would lock itself down as well.
Make the server have no other ports available - so any crack would have to be through your 'credit card server' port, or by physical theft.
Oh yeah - make the port only work with IPv6 - that's would filter %80 of the script-kiddies right there.
Security needs to be in place in all levels (Score:5, Interesting)
No one accesses the credit card info directly - we generate reports for billing staff. When credit card info is sent across the net (to process charges), we use secure sockets (as does everyone I'm sure).
The only machine that knows how to decrypt is a weblogic app server with the key, running on Solaris.
The database is on one virtual LAN, the webservers on another, and the app servers on a third.
We have PIX firewalls to keep out intruders, and our boxes are physically locked down in a cage.
In addition, our hardware topology is based on Windows 2000, Linux and Solaris. You would need to take advantage of security flaws in all three OSs in order to be able to traverse our site.
We make sure the passwords are not words or phrases. Numbers, funny characters, and letters.
The holes in our system are:
1) On weblogic, the connection info to the database is out in the open in the connection pools.
2) Billing staff need to be careful with how they handle paper reports. Perhaps we should only show the last 4 digits of the CC number when generating.
3) We refresh our QA environment once in a while. I have to be sure that I wipe credit card info, passwords, and email addresses from the QA database. While it's fairly secure as well, no point in leaving it around.
No system is perfect. So long as they are encrypted, on a machine that has the latest security patches, the machine is in a secure environment, and the passwords are "strong", you can sleep at night. Most of the large credit card thefts have been against systems that violated one or more of those rules.
nCipher and alike (Score:2)
Summerizing (Score:3, Informative)
- Use 'per record' encryption, where the records are encrypted each with a per-record unique key that is hidden from the outside (user-supplied is good, like a password, or if you need to decrypt without customer interaction, on a seperate box inaccessible from 'outside')
- You should have a method of 're-encrypting' records should a key(s) be compromised, to get the data safe as soon as possible after detecting comprimisation of your key(s).
- Dont ever decrypt - if you can get away with it, dont ever decrypt
- Isolation
- DONT ENCRYPT USING A KEY ON THE BOX ON WHICH THE DATA WILL BE STORED, or you might as well call your box a honeypot.
- make sure you use 'proofs' to verify the data, post encryption. Store the proofs on a box other than the data hosting box, so you can detect data comprimisation as soon as possible! (You could run a local data intergrity job nightly to detect mofified or currupted records.)
Everyone knows the worst can happen with computers - but if you did your best (and kept interested parties informed as to your efforts), then you wont/shouldn't be blamed if the worst happens. This is analagous to drunk driving
I can help! (Score:2)
Let someone else worry about it (Score:3, Informative)
From my archives, a pretty good solution (Score:4, Informative)
Following Text authored by Albert Langer not me, posted to ZCommerce mailing list on Fri 09, Jun 2000 . Still very valid:
<clip>
Warning: Following ideas are "off the top of my head". Not verified.
Q. "Where do I store the decryption key so that the cracker who snarfs the database file can't get it (just in memory somewhere?), and yet have the system be able to boot itself, including having the key, without human intervention?"
A. "Using a 'one time' fast key in a client cookie".
Details:
1. Generate single Public/Private key pair off site. (Slow but only done once).
2. Store only the Public key on web server.
3A. Store Private key very securely on internal site with controlled and audited access etc.
3B. Or better still, immediately destroy it. Losing only the functionality marked * below.
(Above are common to several previous responses. Following are new.)
4. Compress each CC card as received to shorter equivalent bit string (eg convert the parts that are card type to enum, remove checksum, convert remaining ascii digits to large binary integer and concatenate with the enum. This makes the cookie below smaller, also removes some redundancy.
5. Use public key to generate and store encrypted copy of compressed CC number on web server. (Fast). Do NOT store or transmit to internal site, except on specific secure request with audit records maintained at web server as well as internal site. Use same precautions as would be used for storing plaintext CC numbers or private keys.
6. Generate XOR of encrypted copy and plaintext on server. (Very Fast).
7. Store the XOR in long term client cookie (expiry no later than CC expiry date, or add expiry).
8. Destroy plaintext of CC AND the XOR on webserver.
9. Steps 4, 5 and 6 MUST be carefully designed to leave no trace of plaintext or XOR on web server, eg in virtual memory paged to disk etc etc.
10. Step 7 MUST be designed so web server cannot store cookie in client unless transmission protected by secure transport (https).
11. Step 7 SHOULD be designed so client cannot transmit cookie to anybody other than the same server and with the same secure transport (possibly impossible and a key flaw).
<clip>
See the link provided above for benefits of this approach, this post is already too long
Virtual Machines (Score:2)
One option used by many companies is to compartmentalize the data that needs to be secured. HP sells VirtualVault [hp.com], or you could brew your own by running a chroot jail [tldp.org], or more completely by running a seperate virtual machine like User Mode Linux [sourceforge.net].
Simple solution ... (Score:2, Interesting)
The database machine receives the CC# and sends it to the black-box. How to do it? When you connect to the black box it automatically sends a public key for communication, the DB machine generates another pair of keys and sends the CC# using the black box public key. The DB machine will receive the encrypted key using the secret key, encrypted with it's own public key (double encryption). Store the key in the DB.
When you need to decrypt a CC# the DB machine sends the encrypted CC# to the black box (again, using public/private keys for secure communications) and receives the plain CC# encrypted in it's public key. The session public/private keys should be generated at runtime.
Setup the black box so it deletes the key on ligin and on ethernet communications with the wrong MAC Address (it should only receive connections from the DB machine).
The black box should be in a safe place, under a different security staff than the DB machine, so you will not loose both, and if someone plugs itself between both of them, they are communicating in a secure way.
credit card number goes in, doesn't come out (Score:2)
Assuming you need to store a credit card number for at least some period of time, the best way to keep it safe is to store it on a machine that will never give it out--except to local users on a separate network. The web server can send the number to this machine, but cannot ask for it back. Your employees and your order-processing code can access the number via the local network.
If you must store the numbers long-term (to enable that "novel and non-obvious" wonder called "one-click shopping"), they still cannot be accessed from the web server. When the user enters his credit card number, the web server tells the credit card database, "Bob's VISA card is 12345". When the user places an order, he selects "VISA card" from a drop-down, and the web server records in the order that Bob wants to pay with his VISA card. But the web server still doesn't have access to the number itself.
You can take this further by placing additional limitations on what someone who cracks the web server can do. For example, the web server doesn't need access to Bob's password, or even a hash of Bob's password. It just needs to verify it. So store the password on another system that will only verify passwords (and has some rate-limit to guard against guessing). Nor is there any reason to blindly trust the web server when it says "Bob wants to pay with his VISA". Have the password verifier return a random token when the password is correct, and only allow the order if the web server supplies a valid token.
You get the idea--put the important data on a system that trusts the web server as little as possible.
Additionally, I've heard people suggest connecting the web server to the credit card database with something less "featureful" (and thus, hard to secure) than a network connection. A serial cable, for example.
USB 'Keys' (Score:2)
When the machine boots up it 'mounts' this key. Decrypts your 'usable' keys. Then it unmounts the key. This key is then used to decrypt the keys that you actually use to get to your information. So if the machine is stole it is useless (difficult to crack). Remember not store the 'usable' keys dycrypted on the hard drive :)
This way you can store the USB key in another location (fire safe sounds like a good idea to me). And it is only needed when you boot up the machine (read: not really inconvienent). I might recommend getting two and storing one off site :)
As far as hackers - well, there has been alot of good comments about that above...
Simple solution (Score:3)
Store the address, name, phone number, visit history, mother's maiden name, shoe size, whatever you want - but don't store the credit card number.
I'm quite happy with entering my credit card information whenever I purchase something. Knowing that this information will not be leaked to the next script kiddie who drops by - you simply cannot trust security at sites with dropping revenues, budget cuts, etc.
Clearly, the number one priority for many business sites today is to keep things running. Security is only a problem if it's broken. And that only happens if you're unlucky... Yearh right...
Am I pessimistic, or are you naiive ?
Offline CC# Store (Score:2, Insightful)
There are a lot of opinions on here... (Score:2, Interesting)
People talking about system security, shutting off services, firewalls and the like are just plain wrong. I hope, very strongly, that no place I've ever entered my credit card information online was designed by these hacks. Unfortunately, as those of us who had our info stolen from egghead two years ago learned, morons are the rule not the exception when it comes to security.
There is only one way to make this secure -- absolutely no network access to that box whatsoever. Not to the database, and not to anything that can talk to the database. Complete electronic and physical isolation. As someone else said, you need a client/server application that communicates over serial, with a very carefully scrutinized protocol that allows credit cards to enter, and not leave.
Thats the *only* way to be secure. None of the other things people are talking about works. If the data is accessable, no security can totally protect it.
example (Score:3, Interesting)
Same can be applied to credit card info. Once encrypted, you should rarely have to decrypt. Think of dealing with it from the standpoint of encrypting user input for comparison and validation against encrypted info in the database. This will save you from having to decrypt at all.
The other argument is "its not secure if its attached to the net". Basically, you should have the info stored on a separate database server with a direct cable link to the application server via a private NIC.
I Know How... (Score:2)
In order to best answer this I'll need to see all your private data. Send it over and I'll look it over and let you know what I think is best.
[Note: the preceeding is a joke and not to be taken seriously. In this day and age of lawsuits, one can't be too careful about gags such as this.]
This problem is the size of a HIPPA (Score:2)
The approach I am considering most is to use an applet to compress and then encrypt the overread file on the client machine before sending it over SSL to be storred in the database. Of course, I don't have to access the actual overread here, just the authentication information and general contact information for the involved parties. We are using AMA certificates as the key system. This takes it completely out of our hands and prevents us from suffering the headaches. Other personal information which is not encrypted is kept in an Oracle database behind two firewalls, both of which only allow SSL/SSH traffic. Threre are two certificates being used: the site certificate for the public side and an OpenSSL certificate for the private side. I use a streaming program which I wrote to make the SSL connection from the frontside server to the backside servlet. Oracle handles the encryption on the Database side.
This provides the following security levels:
A registered physician must access the site an log in via SSL to the external server. Once he has the overread file, he must have a valid AMA certificate to decrypt the overread. Obviously, his certificate must have been one of those used to encrypt the file.
Security protecting the data is pretty straight forward. You must get through both firewalls, which I check daily for security updates. Both firewalls have different passwords.
Another approach (Score:2)
First, all private and highly sensitive information needs to be available 24/7, so moving it off to another secure server is not an option since it may be needed within the next 5 minutes. This includes patient records, prescription history, etc (and even credit card information).
This is basically that 'chicken and the egg' problem. You have encrypted data, but how do you encrypt and keep it secure while the data remains on the server with the passphrase for the private key.
While there is really no way for us to solve the problem, the hope is to make it EXTREMELY difficult for a hacker to break into the boxes and if they DO break into the boxes, to find out before they actually reach confidential data.
Method: A 3 tier architecture. This includes 2-3firewalls depending on how you implement it. Basically, your network will look like this:
{INTERNET}---[FW]---[WWW]---[FW]---[APP]---[FW]
Due to ACLs on the firewalls, Internet users can only access the WWW servers in the Front DMZ. Those WWW servers can only access the APP servers in the second DMZ. Then, those app servers (which use an authentication and authorization technique like netegrity) access the DATABASE servers. However, since the DATABASE servers actually do the authentication, anyone not already authorized can access the data without breaking into the DATABASE servers (which probably sit on the Internal network of your business).
How you protect data: Since in order for an attacker to actually get your data, they would have to crack 3 different servers. First, your web servers, then your application servers and finally your database servers. This makes it EXTREMELY difficult to get data. With firewall restrictions, you can specify only certain protocols and ports are allowed through. This way, the cracker would need to be good enough to break through 3 different communications protocols (this would require hours and hours of studying the protocols). Not only that, but since the protocols are typically encrypted with SSL, they'd have a VERY hard time doing this.
Hopefully, with the right Network IDS system (e.g. snort) and right host IDS (e.g. tripwire) you can find a hacker once they get onto your web server... and most likely by the time they reach your application servers.
Air Firewalls. (Score:2)
If you have a web interface, it could locally store the last four digits of the person's credit card number to display.
Accounts-related data (Changes to credit card number, orders, etc.) are saved to a file, which is public-key encrypted in memory (PGP?).
At midnight every day, you copy the file to a floppy, then carry it to the accounts server. Put the disk in, decrypt, and integrate with the current data.
The accounts server (Which isn't network connected) can then be used to print packing manifests, bills etc. while the web server has 'cut down' data on order status, etc.
Granted, this wouldn't be the most high-tech solution possible, but it would make remote access (at least over the internet) impossible.
Just my $0.02
Michael
Not that difficult: break the problem down (Score:3, Informative)
This problem (while common) is really not that difficult to solve, in your situation. Here's what you have:
Break the problem down, especially the flow of information, sensitive and otherwise, because this is key:
So, after sketching this down, here's what I've come up with:
- You'll want three servers:
- 'Net accessible web server, contained in a firewall's DMZ (demilitarized zone)
- sensitive data DB server (restricted access from DMZ, unrestricted access from 'trusted' source)
- 'trusted' web server (for employees)
- sensitive information flows to DB server via well-defined interface, but not back (see above posts regarding serial cables, restricted ports, etc.)
- auth info (success/failure) and de-sensitized information (last 4 digits, etc.) flows back to the 'Net accessible web server (to support e-comm apps)
- Open communication to trusted server (secure to your hearts content, see posts on policy & social problems above, key point: trusted server should mean trusted server)
- Employees access sensitive information via trusted server either from private internal net or VPN connections.
- Make it impossible for anyone to access your sensitive DB server from the DMZ (this should be easy to). Once you've accomplished this, your information is secure, regardless of what you do on the actual DB server
... sure, you can still encrypt the data in your database (you should) and all that, a few different methods are described above, but in essence, by restricting the flow of information and then segregating the information repositories based on that flow, you've taken care of your problem.
This type of system allows for updating of information in the DB as well, if you want to allow this, you'll want to design some kind of authentication mechanism between the requestor of the update (the user's password would work) and the sensitive DB server. Otherwise, a cracker could, potentially, corrupt your sensitive data (not really a big deal since backups are being kept). If this is the worst that can happen, you're sittin' pretty.Note: while this 'scheme' requires three servers, they don't necessarily need to be distinct (the one in the DMZ needs to be distinct, of course). The others, though - that's up to you, depends on your resources. Check out user-mode-linux if you want to logically distinguish servers on the same hardware. Encrypting the data files used for each user-mode-linux session should suffice to secure each session from the other, should the host become compromised (again, shouldn't be a consideration, this would only be done on a 'trusted' machine).
If anyone's more interested in what I've written down here, feel free to contact me via the contact info associated w/ my Slashdot acct.
Brice
--
WebProjkt
VP, Director of Internet Technology
S/N Ratio (Score:4, Informative)
Good ideas, seperate Database on a seperate machine. One way encryption systems. Big keys to limit brute force. You can do it in house all with Perl, or you can use several off the shelf packages that allow recurring billing via a reference number. However, few shrink wrap packages are Unix friendly. Most tend to be Windows (ugh) based.
If you were to do it yourself combine several forms of security. Place the DB on a seperate physical network. Dual nics in machines that need to talk to the DB. Give the machine an non-routed IP range. An extra firewall isn't a bad idea either.
Don't forget DB User Level security. Seperate logins for everyone. Limit what they can SELECT, UPDATE, INSERT, and DELETE. Most DB's have column level security. For instance you can give an employee rights to INSERT or UPDATE the cc number field, but not select it. If you can use SSL on the DB transport use it. Billing persons shouldn't need to see anything more than the last four digits of the CC num. That can be stored in a seperate field.
You might also want to consider seperating the CC Number DB from billing DB. Using a ref idea. Again, you can never be too secure.
You should also be looking at application security. A couple posts have talked about putting a serial link between the billing app and the credit clearing DB. It's not a bad idea, but it only takes a couple lines inserted into your perl code to start trouble. You should be looking at tripwire systems as well.
Just because you're paranoid doesn't mean they aren't out to get you.
Re:your first problem (Score:3, Funny)
Ah, yes, if you want to increase your security, run a Microsoft OS. And if you want to increase your protection against STD's, use condoms manufactured by Firestone.
Re:The Best Policy (Score:2, Insightful)
Re:The Best Policy (Score:5, Insightful)
There's an implict social contract between the parties when a credit card is used - the contract is that in exchange for providing a good or service to you with nothing in the way of security other than reliance on a banking infrastructure, I will be allowed/required to keep certain private information about you so that I can validate my accounting records of our transaction on demand.
Keeping this kind of info is not being "up to No Good", it's fulfiling my obligations under the social contract.
Re:The Best Policy (Score:2)
Vecna! wrote:
> If you bill a customer's credit card, you are required to keep that credit card information on file so
> that you can reverse the charges and/or provide information on charge traces that may be requested
> by the customer.
In that case, send the credit card information to an old fashion line printer, in a closed room.
Re:The Best Policy (Score:2)
You the business provide a service with nothing in the way of security, and you are allowed/required to keep private information about me?
Sounds like I the customer have a raw deal.
Comment removed (Score:5, Informative)
The above is the best solution (Score:3, Offtopic)
You want accounts and you want them managed separately from billing. Physical security is what should realistically protect the private payment and identification information that relates to those accounts (eg. the substance to their metadata) so that day-to-day manipulations of orders are separate from month-to-month billing updates.
You simply must keep private info private and enforce it via legal and policy measures. No amount of technology will easily prevent misuse of your data. You could, however, experiment with CryptFS or StegFS to make it much more difficult for a physical security breach (eg. stealing the machine) to result in information leakage.
When I went back and reviewed the submitter's question I decided that I had focused on the wrong aspect of his question. One-way encryption (outside-to-inside) is important, and it can be keyed to the same database as customer account identifiers, without divulging useful information on a public interface. However, the primary measures for his company to take are still going to be policy (dissociating private customer data from public/unimportant customer identification data) and legal (physical security, pressing charges when anyone tries to circumvent).
Again, every measure I'm discussing above is something I've had to deal with in my job, and I am merely offering opinions as to what has worked best for us. I design my systems (at least at this point in my career) so that, for the most part, someone could steal them outright without greatly affecting our day-to-day operations.
Re:The Best Policy (Score:2, Offtopic)
It's easy, meaningless, hackneyed non-answers like this that are eroding slashdot.
I ask "What the best way to do X", and the highest modded answer is "You silly boy, don't do X". Well, if "not doing X" were an option, the question would not have been asked.
People need to understand that virtually any question can be inappropriately (and quickly) answered with "do something else", but then that's not a real answer. It's an excuse to vent an opinion (just like this rant).
And really, it's the moderators who are to blame.
The parent (and this post) should be modded as -1 offtopic.
NEITHER ONE ANSWERS THE QUESTION OR OFFERS A REASONABLE ALTERNATIVE. They both preach. Blah.
I've had enough.
Re:Doesn't really answer your question, but... (Score:2)
Re:Testes, testes, 1,2...3? (Score:2)
you should put that in tags to preserve the width though.
Combinations should include "staff training" (Score:2)