Slashdot Mirror
Keeping Private Customer Data...Private?
"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?
I think the first question these people should ask themselves is why they are storing their customers cc # at all? If you can avoid doing that, it's by far the most "secure" solution!
Websurfing done right! - StumbleUpon
augment your senses: http://sensebridge.net/
Ive ran across this problem myself several times.
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.
You answered your own question: you don't put the decryption key on the same box.
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?
Hexayurt - open source refugee shelter,
You ARE kidding right??? Data collection is a needed component to all business (e- or otherwise). Welcome to the 19th century. Neil
The two rules for success are:
1) Never tell them everything you know.
Many big groups don't emply the level of security you already have. Most bank 'security' is password protection and physical access protection. When break-ins happen they are not published; banks and credit unions are broken into quite often, and they pay to keep it out of the news. The unfortunate truth is that for big companies, it is cheaper to pay for damage from break-ins than it is to get good security to begin with. With the level of security you already have, look into business insurance. Tell them the precautions you have already taken and ask what would get you a better rate. (You would probably be a good risk for Insurance.) Implement those things, and have the insurer audit you in advance to make sure everything is up to snuff.
//TODO: Think of witty sig statement
Anything put out on the internet should have no important data on it. Period. No connections from the internet (aka untrusted aka hostle) should be allowed to the box with the real data, other than those which are PROVEN to be needed, and secure. So:
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.
Zapman
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.
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.
Accepting a transaction without data you can cross
reference is an open invitation to get raped by
thieves. Merchants ask for addresses because cardnumbers can be generated or stolen. I ask for data because the more data I can cross-reference,
the harder it is for people to rip me off. Phones
can be cross referenced to state, state to zip,
zip to address. The whole purpose is to make it harder and harder for people to rip me off and
get my merchant account suspended.
You cannot try to buy something anonymously
with a credit card and expect people to take your word for it. Thats
unreasonable because it puts the merchant in
danger from VISA. Too much fraud and he cant
sell anymore. You have no right to spit out
personal privacy laws when trying to buy something over the internet with a credit card, because the MERCHANT is the one taking the risk, not you.
If you want anonymity, pay with cash.
If you are worried about storing the credit card numbers, why not just put them in a db on some form of offline storage that is only connected on the day billing occurs. The only way you can really keep something secure for sure is to have it physically inaccessible.
Sure, but when was the last time a Gas Station had 30,000 credit card receipts in that shoe box.
It's economies of scale here, the threat is higher because the exposure is higher.
lamp.
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.