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?
If work for a big bank in Canada (about 3 million clients), and you would be surprised to know that out databases are NOT encrypted in any way...
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...)
create a new column called, say, PASSWORD, in the database, and throw some random junk in there, and hope the cracker wastes all their time trying to crack *that* ;)
It's 10 PM. Do you know if you're un-American?
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).
I find it disturbing how companies seem to be rushing into Passport like systems that keep a large number of credit card #s and other sensitive data in a central repository, when no such system has ever shown to be reliable enough to justify the risk.
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.
In Capitalist America, bank robs you!
Require the key on startup (of some daemon, probably the Web Server ... add a command line option to apachectl, for example). The key is held in process memory for the processes that need it, not on disk (except maybe in swap). OK, so it's not perfect, but it's better than keeping the key on disk ... you have to admit it would be *hard* to get the key this way. As a bonus, no process started by an intruder would know the key either, even a web server instance ...
PGP-encrypted SMTP relayed on an internal VLAN to a machine with the 'recipient' key, decrypt ONLY on the destination machine, encrypt ONLY on the Internet-facing machine. Perl classes for this exist and implementing it is therefore a question of writing the appropriate 'glue' for your site.
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.
Remember that what's inside of you doesn't matter because nobody can see it.
It's not unusual for a merchant to ask for your credit card to process the refund. So, they ask for that again, and it's compared against a hash generated from the original order. Tada, easy as pie.
Our credit card info is stored encrypted in our Oracle database.
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.
Paypal ? Reputable ?
Surely, you must be kidding.
morcego
The best solution is to use a second machine to host the secret key. This one machine must be phisically disconected from the world, just a connection with the database machine.
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.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Very few make much sense, and very few are (hopefully) from people who have done it before. For what its worth, I have.
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.
For example in dealing with encrypted passwords in a database... lets say I have a user database with encrypted passwords in it. (Could also be credit card info, etc.) For security purposes, I'd like to NOT decrypt any passwords for authentication, because that will place the password in plain text somewhere in memory, which is undesireable. Instead, for authentication, when the user supplies a password, I encrypt it and compare against the encrypted string in the database.
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.
Skiers and Riders -- http://www.snowjournal.com
According to VISA rules, the merchant is NOT allowed to store the cardnumber - its the property of VISA.
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.
I'll have something intelligent to add one of these days...
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