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
- these multi-billion-dollar companies were trusting us with the data
- our privacy policy specified that the no employee of our company could see the unencrypted data
Then one day I saw a bunch of sensitive personal data on an engineer's screen. I averted my eyes and told him he shouldn't leave his account info on his screen like that. He said it wasn't his; it was "some end user's." I told him that was impossible, so he showed me another person's data, and another, and another. The engineer said they use the data for "quality control" purposes only, but the official line the company gives is this: what I saw is not possible. I didn't see it.So I guess if you [can't|don't want to] find a way to safeguard the data, the answer is to announce that it is safe. Who's going to know? It's not like it's going to get posted on slashdot.
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.
close but having a NIC in there is a recipe for disaster (you never know what security holes might surface in your OS in the future).
;)
if you connect the 'secure' box to your front box with a serial cable you are safer, since you *know* that the only data in/out goes on your serial cable to your back-end daemon.
The daemon itself (trigger-sensitive to exploit attempts as you outlined) uses your own protocol talking over the serial port, and off you go. If your daemon is not exploitable (and making it trigger-sensitive helps as well), you are sure that short of physically accessing the 'hard' box nothing else can really touch it.
Ideally the cc numbers never leave the hard box and on the serial cable you just pass digests etc., how to do that in your case is left as an exercise for the reader
You never want your database server to be the same machine as your web server. Separate the two and put the database server on a private switch, using private IPs (better yet named pipes or something) The chances of someone being able to hack the web server and traverse OLE DB ODBC DBI whatever you are using is slim.
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.
I own a small business, nothing major and not a lot of clients (yet). I do have a merchant account, and if I wanted to I could allow CC orders to transact online in real time. What I do instead is I take the numbers via phone and store only what is needed on a totally isolated box, no net, not even a lan connection. I then use virtual terminal software to perform the transaction via a secure connection. It is a "no-tech" solution for sure, but I do not have to worry about someone rooting my processor box at least and the CCs are not stored online (by me anyways).
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...
Sorry to burst your bubble, but there are few enough possible credit card numbers that there is no pair of CC numbers that have the same SHA-1 hash (theoretically you'd need 2^80 to make SHA-1 collide like that - practically the limit appears to be about an eighth of that, around 2^77 or so, but that's just about where the graph was headed - I wasn't about to let it run all the way to the end to know for sure).
Collision resistance is a laudable thing in a hash, but there's a drawback; because there are far fewer apparently-valid CC numbers than required to even come close to colliding the hash, this means that there is a perfect reverse mapping of SHA-1 hash back to credit card number.
Furthermore, it's not only possible, but practical with a big machine and a nice big storage cluster, to actually construct this lookup table. I did it six months ago for experimental proof, curious to see whether any collisions did in fact occur (none did). And once you've got that table, you could convert a table of CC number hashes back to valid CC numbers. Fortunately for you, (1) I'm not a credit card fraudster, and (2) I don't 0wn your servers.
The hard task of actually constructing the table might help keep the script kiddies away, but are they necessarily the only threat model you have to worry about? That's something only you can decide, based on your profile and the importance of the data you carry.
Don't try and solve this problem by using a bad hash, as collisions are also a bad thing in this case - you might validate a number as being stolen (you said negative db checking, right?) which, in fact, was genuine - really pissing off a customer. (Said customer would probably get quite frustrated with their credit card if the exact same technique was widespread, but that isn't the point, that's one less real customer...) So deliberately using a bad hash is also a bad idea.
Oh, and for what it's worth, keys stored in "secure chip" hardware can also be cracked, reversed, analysed, whatever. It just depends on whether you can get access to it, and how little you mind spilling concentrated nitric acid on expensive lab equipment, heh. I've tried a couple of those myself, although in my case I couldn't actually manage it even with the right equipment (I guess I was having a bad day). Others are considerably more skilled than myself in this field. Hardware solutions are not a panacea, believe me, but getting the actual key off one without physical access would be an impressive feat. Worth considering, if you like your cake with icing.
My advice would definitely, and always, be this: Just don't store credit card numbers. Anywhere.
The co-host idea mentioned elsewhere in the comments may also be a reasonable compromise for you, if you really HAVE to store the CC numbers, but I strongly advise against doing so! Why do you need to? Is there another way you could do it? Isn't the user needing to reenter details to reauthorise transactions more of a feature than a bug?
If you store CC numbers anywhere, in any form, for any reason, at all, you might be breaching your contracts with the CC companies; if your contracts allow this, storage should definitely be a point to mention in the privacy policy. The safe bet really is not to store at all.
That way, really, the worst case scenario is that your server gets cracked in a way you don't notice, and trojanned in a way that grabs and retransmits the numbers as they pass; and if you do your job with any kind of competence, you'll notice that quickly and take the servers offline before any actual numbers pass through it.
Good luck.
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