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/
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...)
I suggest you change your solution to run on Win2k.
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.
You can run but you can't hide, except, apparently, along the Afghan-Pakistani border.
I wonder if this question (and the others mentioned) have anything to do with this recent IDG story.
Sinepaw.org: Grape Winos
Comment removed based on user account deletion
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?
While it would be a pain in the butt to convert lots of data to seperate encrypted image/sound files it would be very secure, since many people don't use or suspect it.
Info on steganography can be found here.
-Tolerate my intolerance
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've done something similar before (though it was passwords, not credit card data) and the trick is to not store the secret key anywhere, especially on the server that stores the data.
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.
demi
IMO, the best thing you can do to protect sensitive data like this is to put it behind firewalls/proxies in addition to using data encryption. Also, do intrusion detection. Don't assume the security policy you implement is going to be "enough" to prevent anything nasty from happening.
Make sure encryption keys are either readable only by root and the machine is locked down to make it very, very hard to get root.
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?
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.
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 ...
I don't think this person is trying to be a troll. In this day and age, nobody can really believe that win2k and/or closed source is secure, so this person is actually trying to be funny.
who owns less than 50% of the web servers and account for about 99% of all broken into web sites and stolen credit cards? windows
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.
11*43+456^2
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.
oooh, nice troll.
you should put that in tags to preserve the width though.
In Capitalist America, bank robs you!
ah yes and crypto algorithm's are always closed source.. Have to love the closed source is secure argument..
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.
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.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
get a job homo
Store the private keys on a CD, make multiple copies put one in a safety deposit box. Write a PHP/TK or Perl/TK or Python/TK script that can run on a windows machine. Make the web based billing interface download the script which IE on the desktop will run using the local perl/php/python interpreter. That app can access the database and the CD for the keys. Remove the CD when not performing billing.
Now I hope and pray that I will But today I am still, just a bill
For each user that needs the pass phrase, use their password (or some password related token) as a key and store that version of the pass phrase with their user. Then, when that user logs in, you can decode the pass phrase with their password and when they change their password, update the encoded pass key.
That's your best bet (with my limited knowledge of security). And add in some obscurity and call the field something like GUID or something.
Could you move their job to another server and share the data through the network?
Good luck,
IMarvinTPA
Trusting software vendors is no smarter than trus
How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?
On my Palm Pilot.
I wear pants.
I would consider storing the numbers in Navajo. It worked in WWII.
Best Windows Freeware
The big boys use a system that requires multiple key segment holders to type in their part of the key order to get the system running. I.e. there isn't one person that knows that whole key and a number of the people who hold part of the key (pass phase in this case) need to be present in order to restart the crypto services.
It can be a tall order for smaller companies or companies where security and encryption aren't core competencies (read, it is hard to convince people that they should sign up for system that might require them to get up in the middle of the night just to keep "customer" data secure).
The only way I know to do this is to have the application prompt for the passphrase at startup. This stores the passphrase in memory and not on your harddrive. You could even encrypt the in-memory passphrase in case some uber geek cares to hack your memory.
-- Grow up and use mutt.
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
i totally disagree... open source by far has fewer security risks than m$ crap.. and this has been proven.. as far as security is concerned i would try using something like best crypt to encrypt the entire mount point this will protect the data from being accessed from an un authorized user for the most part... second would would be do u really need the credit card info? or just a way to validate that is is correct (ie online buying and such) or do you need to store the cc# each time a transaction is made if the answer is validate then just use a md5 of the origianal cc# and keep the md5 if you have the later then dont use pgp i would recomend something like blowfish or twofish encryption on the information in which you could use a secondary system to store keys (ie. every record has a unique random encryption key) that would make it alot harder to crack since each record would basicly be unique hope this at least points you in the right directection
dsteele@systeloa.com
As with most security related topics, depth layered solutions are best. Of course, design your network and connectivity with least access in mind--i.e. the database server itself is never directly accessible via the Internet, or even your first layer of permimeter defense. Typically, only http and https are externally acessible, with perhaps a few others like DNS, and FTP.
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
Here's an amazon link:/ qid%3D1023135591/ref%3Dsr%5F11%5F0%5F1/103-9142405 -3353431
http://www.amazon.com/exec/obidos/ASIN/020172152X
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.
Problem as understood - The Key lives on the data host because it is needed for bulk transactions.
Solution - Store the key on a second server, and set up your app to requisition it for the duration of the bulk-process and then forget it when the processing is done. That way the key is less available on the data host.
You can get silly/secure/paranoid from there. Set up the keyserver so that bulk transactions can only start on the 10-th minute of the hour. Set up the server software so that your bulk jobs start then, and you know that any other access can be rejected.
Or set it up so that someone has to "unsecure" the key on the key server (Authenticate on the other machine) to make the key available for the data server.
Just thinking...
No Good? Haven't you ever heard of laziness? Sometimes it goes by the name of convenience. Either way, customers typically like it, and will pay more for it. Making them click a link in an email and logging in is just too much for the consumer to deal with, and must be simplified if you hope to sell whatever crap you're hoping to push on the public. (well, maybe that's a little overboard) Either way, you trade security for simplicity.
One way to add protection is to make only the application that uses the data the only thing that has the ability to encrypt/decrypt data to the database, and keep the two separate. Sort of like a mail store - namely you don't encrypt the mail store, but rather the end-user retains the responsibility for encrypting/dencrypting the mail.
Of course, this isn't true security, because if you crack the app, you still get the data. But at least you don't put the keys in the front door of the safe this way.
Scary as it may be, the IT infrastructures of many major corporations rely on keeping people out of the house more than securing things inside. They'll encrypt it on its way out so nobody can sniff it, they'll scramble it in reports if needed, but in it's main storage location, it's just there, waiting to be had.
If you were to gain access to their infrastructure, and then subsequently got access to their databases, you'd find that the sensitive info like CC#s are probably plain-text. At most, those may be encrypted, but if you think any major corporation encrypts names and addresses, phone numbers, SSNs, etc., you're dreaming. For most companies, contact info is in no way considered sensitive, and as a main asset of the company, is shared as widely as possible to make sure that the "one customer, one view" kind of thing works. They care far more about having only one copy of that data in order to keep it up to date than they do about securing it from intruders.
Strive for the best, sure, but you should rest somewhat secure in the knowledge that you're already a good number of steps ahead of many of the big boys.
For many if not most applications, a cleartext key on the hard disk is not necessary (although a cleartext key in RAM for at least some period of time is probably unavoidable). If you have a situation where you need to decrypt a credit card when a user buys something, or you need to run a billing cycle periodically, you can do this: Generate a user key randomly; this is used to encrypt the password. This information in turn is encrypted by each system user that needs to access the data. Only the encrypted user key is stored on disk, one encrypted copy for each user who might need to access it. When the user wanted to make a purchase, they'd type in their password, which would be used to decrypt the user key, which in turn would decrypt the credit card number. If a customer service person or billing clerk needed access to the credit card number, they would enter their own password which would decrypt the user key. If you need the machine to decrypt the password without any human intervention, that's a tougher nut to crack. My guess is that there's no way to do it without having a cleartext key on the machine, or accessible by the machine.
Don't store the data on a machine that can get cracked.
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.
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
Why does the web server need to decrypt? It should be storing the sensitive info in the DB encrypted with the public key. If your personnel need to decrypt it for something, do that on a seperate machine.
administered by IBM
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.
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
So many people smoke.. Quite a few people shoot up Heroin, I can think of a few people that purchased Enron stock, oh and not to mention there are even a lot of people that are entertained by Jap Scat.. I guess by your reasoning all of that is "good also".. What am I doing still sitting here.....
A good solution (if expensive and cumbersome) is a highly tamper resistant hardware device like IBM 4758 Coprocessors (been talked about on slashdot before, too lazy to look up the links)
Basically, it is a seperate computer which sits in a PCI slot. You have the program which needs the data log into the card when it is started, and whenever the program needs secret data, it passes the encrypted data into the coprocessor, which decrypts it and passes back the plaintext. The idea is that only the running program has a valid session on the card. If anyone tries to pry the secrets out of the card, it nukes itself. (Obviously you'll want at least TWO cards, with one backing up the first...) This thing is seriously paranoid. Tempature, pressure, X-Ray, vibration, time, physical shock, intrusion, and other detectors. And they seem to work. (I've put one in an X-Ray machine: it died)
Obviously there are some "gotchas" with this scheme. For one, it assumes the program is a long running one. Additionally, it assumes that access to the program itself is secured properly. Also, if you're truly paranoid you'll be using signed biniares with the checksums stored in the secured memory as well...
The cheap answer is to make a long running authorization daemon ala ssh-agent. But, the same problems of access to the machine apply.
Hmm why wasn't this marked funny?
This may seem (may be) very naive, but what is wrong with an airwall.
In the situation that you described, billing isn't required to be real time, so just dump the batch records for today onto a tape, and load your billing database that resides on an inhouse network that isn't part of the ordering system. This or some variation.
So little of what we do today really needs to be real time, and there is so little attention paid to batch processing now days, but it hasn't really lost its utility.
If the isolated web interface ins't feasible, then maybe putting the key on a removable media (USB key?). Again, I really doubt your billing department mails out bills/submits to credit card company one account at a time, whenever the mood strikes them.
Use asymetric encryption. Put the public key on the web server.. encrypt the CC numbers with it. Everywhere in your system use the encrypted CC chunk..
Then sneaker net it to a backend system which actually processes the billing. The private portion of the key should exist only on this system...
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.
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.
decrypt it on the machines the billing staff accesses the accounts with.
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.
and I've implemented reasonably correct versions of almost all the others, so I am not just 'guessing' but offering observations from someone who's built several systems like yours.
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.
Remember that what's inside of you doesn't matter because nobody can see it.
I've been considering this issue for a little while and there's an approach I've been thinking that should work well to keep data secure.
What you do is use message queueing and set up a credit card "server" to instead act as a sort of client. You have a less secure server that hosts a message queue. Then you have your credit card server connect to the queue to look for credit card transactions to process. This eliminates the problem of having a service of any kind running on the credit card storage system.
The next thing you do is create a simple API of commands that can be sent to the credit card system. Add Card, Remove Card, Charge Card, etc. Thus, you can control the ways that the card processor can actually be communicated with to a rather small number of possibilities.
To get the cards onto the server you use a public key/private key system. So the less secure server encrypts incoming data, removes any transient trace of the unencrypted data, then passes along the encrypted data to the secure server using the API.
The only drawback to this approach that I'm aware of is that credit card processing is asynchronous. So you submit a transaction into the queue, then have to wait for the transaction to be processed and to return the result to the outgoing queue. So depending on how it was done, you may have some delays in your processing, but they should be minimal, and it's well worth it for the extra security.
The only ways I can think to compromise such a system are to get console on the system or somehow exploit the API (which you make intentionally very limited to only the functionality you need).
Here are a few options, none of which are perfect. You can use more than one of these -- mix-n'-match as you see fit.
1. Separate the web/app server and the DB server. This is something I think you should always do anyway, but to address this specific issue, this way the decryption key doesn't reside on the DB server, and the encrypted data don't reside on the web/app server. For more security, put the DB server on a subnet with a nonroutable IP address so that your web/app server can see it but the outside world can't.
2. "Store" the key in obfuscated form. Derive a key by grabbing the dates or file sizes of a handful of things that you believe will never change, and hashing them all together. Never store this directly, just recreate it at app startup time. This is ugly and fragile and also useless if the bad guys get their hands on your source code, but I'll argue that it's a little bit better than nothing.
3. Don't store the key on disk. Ask an operator for it each and every time your app restarts, and store it in RAM (slightly encrypted, even).
I used to work for a large charge card company...a card "you should never leave home [without]"...and all the card numbers were stored in a scrambled (or encrypted if you will) form. An algorithm was used to compress the card number into a shorter form than its orginal length. Our system could recompile them on the fly so personel could see the actual account numbers on screens and such. I'm not certain how this was done (not my area), but when data was pulled from our database using simple file extracts, the card numbers were unique, but didn't look anything like the real ones.
Ruger
First, balance the risks. It is a well known fact that most fraud comes from insiders. Close that avenue down first (you are probably the biggest risk yourself!)
Secondly, there are two different ways you might be targeted externally: by someone after YOUR data, or by an opportunist. In the first case, if they really want to get in, they will steal both computers physically, use social engineering, whatever, anyway - whatever you do. In the latter case however, if you are a small company, just make sure there is 'enough protection', and they will move on to an easier target.
Just make sure you don't make the target extra juicy; for example don't post on Slashdot that your system may have vulnerabilities! (p.s. glad no real email address in the front page at least :)
You might want to consider hardware based crypto like nCipher. This way you do the key storage and en/decrypt functionality in (supposedly) tamper resistant hardware. HOWEVER, if someone hacks your system and is able to access/copy your code and get the right privileges to talk to the nCipher box you are screwed anyway. But it would certainly raise the bar ...
you have reveiled thier new security strategy after the month long security audit they did.
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
Make sure the co-host is not networked at all; have the connection be a pair of RS-232 serial lines instead. On the line that sends the data to be validated, clip the wire that would allow signal to be transmitted back - (break RD, leave TD intact) to create a one-way signalling method.
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!
- 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.
Just a summy post to collect most of the points above that are good ideas:
.. if you need the # for display on pages (like receipts), you only need to display the frist/last 4 digits for confirmation purposes, so only store those (encrypted). This is along the lines of minimizing the 'pot of gold' in a worst case scenario.
.. depending on the data's sensitivity (and CC#s are supermega sensitive), you can opt for various levels of hardware isolation of the box that stores the key, via a serial cable or something.
... everyone knows car crashes can happen, but being drunk during one is going to void any possible blame that could have been placed on people other than you.
- 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
"Old man yells at systemd"
I would like to take this oppertunity to personally thank you for responding to my troll.
You can keep your symmetruc key on that same machine but you'll have a number of different options as to how to keep that symmetric key safe. One way I've found useful is to use a SALT, as described in the article. A SALT is a very large number which, once blended with a keyphrase produces a Key Encryption Key (KEK) that you can use to encrypt and decrypt your session key. Your keyphrase can be any of a number of things, from a dynamically entered password to another piece of information from the database (say a table name or DOB of a dummy record).
A new SALT is generated every time you want to re-encrypt your session key, helping you prevent precomputations (and therefore brute force attacks/dictionary attacks). The SALT can be stored locally or even on another machine in the clear. It is merely there to add entropy to your KEK. If it is stored on another machine, it could be on a machine segmented away from your network and could be retrieved via a VPN from your database server.
The key of this scheme is that you have dispersed your keys and you can then use machine security, network security, whatever to aid you in helping keep individuals' credit card data secret.
I'll need a copy of the database and the passwords, then I'll get back to you. Oh, It'll cost you $19.95, too.
TrustCommerce has a great system called BillingID's where you can submit all your credit card info for storage on our secure Linux servers. You are given a handle that you can use bill the customer at any time through our cool GPL'ed client API. Retrieval of the CC info is impossible so even if your server is compromised the hacker can't get your credit card information. This lets you bill customers at your leisure but lets you offload all the extra security responsibility onto us. Security is, after all, what we do. </shameless plug>
You can find this also here:
:)
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
At the company I used to work for, what we did was a little unusual but it was pretty close to 100% secure. Essentially we seperated the data collection system, which had to be on the Internet in a form that meant it could take incoming connections, and the data storage system, which only needed to receive data.
What we did was a little complicated. The web server was only connected to the Internet. When a customer connected to make an order (or change an existing order), a CGI would put all of the information into a packet, gzip it, pgp encrypt it, and post the encrypted message to the Usenet newsgroup misc.test. A second machine, connected to our internal network, would periodically dial in to a UUNET hub, and receive the newsgroup using UUCP. This meant that machine never had a live Internet connection. The machine would then post the articles to an internal NNTP server, and a script would read the newsgroup, identify our articles, decrypt them, and process the transactions.
That way our internal network never had to be connected to the Internet, ensuring the entire system was completely secure. A hacker would have either had to compromise the web server - and access only transient records available for a few seconds, or crack a 1024-bit PGP encryption key. Not easy.
It's another picture of Jon!
One option used by many companies is to compartmentalize the data that needs to be secured. HP sells VirtualVault, or you could brew your own by running a chroot jail, or more completely by running a seperate virtual machine like User Mode Linux.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
The best way to keep someone from decrypting it from the production server, is to not have the private/secret key anywhere near that server.
Use public/private key encryption on the credit card number, possibly keeping a copy of the last 4 digits in cleartext, so the customer can figure out what card it is.
Give your billing staff access to a private webserver which contains a copy of the public server's database. This machine should not be accessible to the public, and should be the only one decrypting the information.
Check out this whitepaper from CyberSource that describes a good solution for your problem. I'd add to this approach that you should use a keyed hash, and a hardware encryption device for both hashes and encryption/decryption so the keys are not readily available to someone with a login on the machine. I'd recommend Ncipher. Finally, use Tripwire or some such thing to monitor the machines for unauthorized programs that might gain access to both the database and the crypto HW.
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.
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.
Merchants are required to keep accounting records of this sort of thing for 7 years.
... check out the "secure storage" of credit card information at the local gas station or the restaurant. It's secured with a shoebox for the most part.
However, does this information need to be stored online? No!
Whenever people talk about credit card security I always snort derisively
I am not a number! I am a man! And don't you
Click Here The article will open in a new window...
Well, just to expand on that thought: you could store the key on a floppy (or CD, or that funky USB keychain, or whatever...) and require the disk to be inserted and mounted while starting the server. Then take the disk out, carry it with you, and guard it with your life :-)
___
If you think big enough, you'll never have to do it.
Once upon a, I worked on an early e-commerce project. This MIGHT have been S.E.T., or maybe just a variation. Anyhow:
- You select an item or items to buy, lets say $70.00 worth
- You go to "check out" and offer your address, CC number, name, etc
- I (or my program) takes that info, format it "right" and digitally sign it using MY key.
- I encrypt that chunk with VISA's cert and pass it to VISA for validation. Getting validation, I ack (to charge) and then ship the goods.
- I keep no CC info that I can read (or crackers, presumably).
In detail:I now have a (signed) chunk of data with MY company info, how much you spent, your CC number and personal info (and NOT what you actually bought). I've encrypted that with VISAs (whoever) public key and wipe the unencrypted info. I send that encrypted data to VISA for approval.
VISA will decrypt it and check the signature. They will validate that yes, your address matches your CC number and that you can take the $70 charge. They send back a "YES" and I return an ACK that causes the charge to actually occur.
At this point, I have a record of what you bought, your address, how much. That's for my records for shipping. I have an encrypted blob that VISA has accepted and the ACK code that they returned. I DO NOT have your credit card number stored in anyway that even I can read. If there are questions, I can resend the encryption blob to VISA and they can validate it, but I need never have that info.
Note also that Visa needs not know what you bought.
We had this running in 1995 or so, on a test system. It seemed obviously "right." Is this really hard to get?
Bad guy gets my computer, they get a lot of encrypted info that even I cannot decrypt.
Best answer is a "smart CC" with challenge response. "here is your valid CC number for this transaction, never to be repeated" but we don't have that yet.
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.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
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...
It's easy; don't store the information. If it's not there, noone can steal it.
;)
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 ?
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.
No matter how secure the file is, if your staff members take down the credit card number on scratch paper, possibly in a legal pad which they keep in their desk, or yellow stickies which they throw away in the regular wastebasket, you've got a problem. I tried and tried to get us some secure waste disposal at one place I worked, never succeeded. Fortunately we did not have any grifters among us (that I ever found out about).
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).
I agree with this to some extent, since most users can't remember 16 numbers at a time, I'd advise storing some of the data, and have them fill in the blanks. Like mentioned above, send an email with a link to login, and store the first 12 digits of the CC#. Then the user only has to remember the last 4 and their password. Security and efficency are an inverse relationship. You're a small company, don't let a 14 year old script kiddie, who got pushed into a locker one to many times that day, come home pissed off and be the downfall of your company. (Ahh, the good ol' days...)
This
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
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.]
I wonder how you'd expect Mastercard or Visa to make this a workable solution.
How the fuck did this get moderated a 5?
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.
RFC1925
Protegrity (www.protegrity.com) has a drop-in solution that works with most big-name databases. It provides a more mature key management system -- enterprise-wide -- on a separate box; much better than a grow-your-own solution. I haven't implemented it in production, but I've looked into it pretty closely. Works with most applications with a relatively small performance impact. EXCEPT.
EXCEPT for those databases which require the primary key (i.e. card number) to be encrypted. This means queries like "where CARD_NO = xxxxxxxx" must decode every single CARD_NO in the database looking for a match. Forget performance. Protegrity has a work-around for that particular query -- I believe they can now encrypt the CARD_NO field in the query before executing the SQL -- but it won't help for range lookups, i.e. "where CARD_NO between 1234500000 and 1234699999" (this is a useful kind of query for card issuers; it allows them to separate gold card accounts from the riff-raff, for example).
The proper approach -- which usually can't be retrofitted -- is to replace CARD_NO with three fields. The first is a hash of CARD_NO -- this is used for all lookups. The second is the encrypted CARD_NO, and the third is the field you show on reports and customer support screens, something like "*****6051"
It's supposed to be completely automatic, but actually you have to press this button.
The authentication schemes used by credit cards are really lousy. We need a system where the number itself doesn't have to be private in order to be secure. What I'd love to see is a smartcard that stores a secret key and uses some sort of challenge-response system.
The notion that such things as your home address and phone number constitute "authentication" is ridiculous.
When you want to make a purchase, the merchant asks for your credit card number, and sends you a "challenge", a random message, which you then input into your smartcard (either via a small keypad on the card or a USB port). The card generates a signature (the "response") that the merchant can verify using your public key which is available from the card issuer.
Assuming that attacking the crypto is sufficiently difficult, nobody can ever use your credit card without being in physical posession of it.
But I don't see how this would scale to more than a few boxes. As much as we like to believe in the rock-solidness of our servers, there are many things that will cause them to crash, usually at the 3am or some other highly inopportune time.
When servers go down and then come back up, you can't have your site inoperable because the console is stuck at some password prompt, waiting for human intervention. I say this from experience: just last night one of our backend Solaris machines had some kind of trouble and rebooted itself.
Honestly, I don't know the best solution to the original question, but my experience says that it's better to automate and be able to shut down quickly when there is suspicious activity rather than relying on human intervention for routine activities such as starting up services/applications.
-Steve
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Loosely paraphrased from The 48 Laws of Power.
There was an ancient Chinese king who was so feared and respected that once, when he was at war and cornered in a city with only a smattering army against a massive foe, he simply told his soldiers to leave him alone. He then left the city gates wide open, and sat in the town square in the lotus position, meditating. When the enemy advanced in on him and the general saw the king sitting there, seemingly completely unprotected, he realized that only a fool would leave himself so obviously at mortal risk, and since the king was no fool, that must have meant that he had a hidden motive so devastating that, conversely, only a fool would advance in on him. The general immediately left the city, and not too long after, signalled his surrender.
The moral of the story is that one should create a shell around him or her, so easy to crack that it dumfounds potential assailants, convincing them that there is a hidden defense waiting for them. The more harmless the outer appearance, the more sinister that hidden defense will seem in the imagination of the assailant, until they will capitulate and leave well enough alone. Therefore, it is important to choose a platform that on the surface appears to a hacker to be laughably weak, and the weaker the better.
In other words, any number of Microsoft products should do the trick just fine.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
I am faced with a similar problem: storing PET scan overreads for peer/specialist review along with patient medical information and allowing access to those overreads by only the referring physician and his peer.
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.
My $0.02 will always be worth more than your â0.02, so
If a cracker gets control of a system that is capable of decrypting, she can trace the code and find the key.
If the decryption is done on a separate system, she can pretend to be a system that is allowed to ask for decryption services.
If the key is manually entered by an operator and only kept in the memory of a running decryption program, she can trace through the memory.
You can't make it perfect; you'll have to be satisfied with making it hard and separately working hard to prevent the system from being cracked in the first place.
If you are only charging the customer one time, I don't see anything wrong with just using the card once and then getting rid of it. Just a one shot deal. As far as repedative billing, I agree with the other comments about keeping the key on a seperate server. Just in case. Now, i'm no expert in encryption but one method that I always thought was cool was the random keys that are generated from a device that's about the size of a calculator, or a key chain. A new number is generated every few minutes and is pretty much a one shot deal. This is synced with the server before being handed out. Could you use this with your employees, or possably impliment a similar system between the machines that will be dealing with/storing this info? Just my $0.02
Continuing on the idea of a co-host containing the key, you can use a program called vtun to create a secured tunnel between the machines to send data back and forth. My own experience with this problem led to this solution:
;)
;)
1. Firewall / IDS system. This is an absolute must for any company that stores any kind of client information
2. Machine lockdown. The servers that contain credit information run 3 process besides the neccessary system processes: MySQL, Tripwire, and a custom C application that would respond TRUE/FALSE when a credit card # was submitted to it. It also handled recurring billing by having the API for Authorize.net built into it. The only thing customer service could view about a customers credit card is, on a TRUE relpy, it would also send the last 4 card digits. Thats it.
3. Co-host running all other applications.
4. Vtun between the 2 machines. Since one was in Dallas (Customer Service) and the Credit database was in Atlanta, Vtun allowed Dallas to see Atlanta as a local machine, vice versa. This, in conjunction with firewall rules that would only allow one IP to open up to port 22, which Vtun was tunneled thru (woo!! double-tunnel!), seemed fairley secure, although still kind of scary.
5. Secure server room. No explanation needed. Not to mention that the back of the server had a secure plate on it (homemade by me, 1/4inch steel welded) that had a tumbler lock on it like those you see on coke machines. No terminal access or case access to someone who got it. It was literally a tank of a case, but the area the server was in couldn't be trusted to provide good security, a fact that was due to bad mangement, NetOps had to take it into our own hands. (I'll find pics of the case, it weighed about 80lbs).
So in summary, the credit server never gave out customer #'s. It would let you know if a number existed in its database, would return the last 4 digits, and would do recurring billing. 2 people had access. The server password was changed every 3 days and was stored in a safe that only those 2 people had access too, mainly because the password was 20 characters/digits long.
Anyway, nothing can replace good security practices, and what we had to do might seem WAY overkill, but we had a lot of security issues to worry about, from random people being in the server room, to customer service reps who had felony convictions. (so much for background checks). Hope this helps
-===- "Those who would sacrifice freedom for security deserver neither" -===-
Who knows if the log files are even examined? What is to say that they would not get lost in a massive amount of logging, if logging is even turned out (performance issue at hand)
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."
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
I work for another industry... health care... while with credit cards you can deal with various situation with hashes and the such, in the health care industry, and within our website, patients need access to their PRIVATE information 24/7. This leads to a very interesting dilemna.
- -- [DATABASE]
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.
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.
Unless you particularly need to store the data in an online system, don't.
Most of your recurring billing doesn't happen using an internet based service, yes? The software dials a credit card service at intervals to process the cards. So, make the connection between your online system that first sees the credit card to your database that stores it a "write only" link. Not hard to do. Think: serial port and perl script. Then, drop any information from the "online" portion of the database that isn't strictly needed in the online portion.
It can't be hacked over the net if it isn't on the net.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
If the data you are protecting is valuable enough to make the company bother with a setup like this, one can add a whole host of features.
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.
No one does it, which is why security is in sucha sad state of affairs, but what you want is an operating system that supports mandatory access control. Like Security-enhanced Linux, for example.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Don't use encryption at all and don't store the original - run it through MD5 and store that value. Run what the user gives you through MD5 and compare that to the stored value.
This is what the "Big Boys" do.
There are at least 2 HSM (Hardware Security Module) sellers (Atalla/Compaq/HP being one).
The "master" key is kept in the HSM. All data to be encrypted/decrypted is sent through a local TCP/IP link to the HSM.
This may seem impractical but if all you are dealing with is the credit-card numbers it is quite viable.
If you want to do more then you simply store the encryption key (for large amounts of data) ENCRYPTED by some variant of the Master KEY (only stored in the HSM) and make sure that you do not have your programs ever storing the decrypted key on disk (best way of doing this is to store it temporarily in exclusively owned shared memory that is NOT virtualized - and thus never goes to disk).
Even just keeping each process only seeing the decrypted key in its own memory is probably enough since a random bit of data in memory that is NOT known is very hard to find without reverse-engineering the binaries that are actually accessing it.
etc. etc. etc.
I suggest you change your solution to run on Win2k.
You are absolutely right. No one can break into a computer that is always down due to reboots and virus infections!
Healthcare article at Kuro5hin
Failing that...
Use a secure hash on the passphrase to generate the encryption key "k".
Use the encryption key "k" to encrypt the customer's data with a symmetric key algorithm of your choice.
Store the encrypted customer data on the disk.
That way, neither the unencrypted customer's data nor the encryption key are stored on disk.
You can do the same thing with the database password that was described above for the customer data.
Brute force is always possible. Make sure you have a sufficently time-consuming secure hash and encryption functions so that brute force takes prohibitively long.
Also make sure you have a good passphrase generator.
There are a number of vulnerabilites still. Someone can use the FBI keystroke logger on you to get the passphrase, among other things.
In the end, though, your system will be exploited by someone writing down the passphrase on a sticky and sticking it to the monitor. 8') Either that or being tricked out of it by a hacker disguised as a legitimate user asking for the passphrase.
Other posts have indicated why most companies need to keep the CC#. However, in a properly architected system, sensitive data such as CC#'s should be compartmentalized and isolated. A couple simplified examples:
There's *no* reason why CC# verification logic needs access to the database containing CC#'s. E.g., put the CC# database on a separate machine (with internal firewall, proxy, etc.), with external access limited to "verify this CC#" or "verify this CC# for this amount".
In the unfortunate event that the application isn't well architected, a shadow CC# database can be constructed using one way hashes of the CC#'s; the "real" database is kept elsewhere, and is only directly accessible to systems that require the real CC#. This achieves a reasonable level of protection without (usually) having to gut the application.
In short, the effectiveness of the security for these types of systems is heavily dependent on the application's architecture. (You can't retrofit systemic security.)
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.
Unfortunately, this doesn't work well for online shopping for many reasons. One being that a customer's credit card is often not charged at the time a customer hits the "buy" button. It's often only later when the item or items are actually being shipped that a charge is made, and then it's only for the actuall items that are being shipped, which is potentially a subset of the whole order. If an online reseller waited for a response from their customers each time something was about to ship, it would be a major bottleneck in their fulfillment center.
The bottom line is that whenever you talk about security, you need to consider how much a particular security policy will save you and how much it will cost you. Not storing any personal information is a security policy that will likely put you out of business since other online retailers will be able to make their services much more convenient and efficient, while providing a sufficient amount of security to this information at relatively little cost.
"The only rights you have are the rights you are willing to fight for."
Well, there might be better solutions. Check out this new secure key hiding (SKH) and code obfuscation (or as they call, universal program encryption, UPE) technology of Tamper-Proof Verified Systems (TPVS) http://www.tpvs.hu/.
I think, in principle, it is capable of solving the problem mentioned above, as several others.
Why not have the billing sstem physically disconnected from the network?
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
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
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.
Living better through chemicals
Sorry, when it comes to credit card numbers, that's often not accurate.
I'm an e-commerce Web/database programmer, so I've actually built systems like this. I've found through experience that storing the name, expiration date and LAST FOUR digits of the customer's credit card number is all we need for issuing credits, accounting, etc. Even if a hacker were to steal our database (which has never happened), they wouldn't have enough info to make charges on our customer's cards.
IMHO nearly all sites that get their databases of (full) credit card numbers stolen were stupid and asking for trouble for storing all that unnecessary info in the first place (CD Universe, anyone?). I've built completely functional e-commerce businesses which run just fine without it.
Sure, our customers have to re-enter their credit card number (only) each time they visit our site, but so far no one's complained. As a customer myself, I consider it a very small price to pay for the increased security. Wouldn't you?
So let's see here.
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.
About all of the effort that goes into protecting your credit card number when you shop online, and yet, when you go to a resturant, they collect a bunch of numbers, put them in an envelope and shove them in an unlocked filing cabinet.
It's true that a gas station has a much more limited # of cards so the overall fraud is smaller. But that's the credit card companies problem (who, for there own crap security, get whatever they deserve). So if you get my number then it matters to me. And since you probably give your card to many more insecure physical merchants than insecure electronic merchants, your net risk from the former is higher than the net risk of the latter. It's like air safety. Airplane crashes kill many fewer people than car crashes but when they do, it makes a big explosion (and kills a bunch of people).
All I'm saying is people tend to respond to specific threats while ignoring other threats which have become common.
I am not a number! I am a man! And don't you
Fundamentally, you change nothing. You add a tiny layer of obscurity, but that's it.
Would your "ideal" system include passwords for users to log in remotely? Probably. If you have a password, the security is based on the assumption that only you know it. Once it is publicized -- no longer "obscure" -- it is no longer effective. As long as the obscurity you're relying on is sufficiently difficult to guess, it's effective.
This is not to say that security through obscurity by itself is effective, but it is frequently an essential component.
Nope, no sig
A couple of good practices...
If you store password data in the database, make sure that it is salted and then hashed. SHA1 is nice because of the 160-bit output value. This makes brute forcing the password extremely difficult.
If you collect credit card numbers, use asymmetric crypto to encrypt the card data immediately prior to writing it to the database. Do not decrypt and process it on the same box. Decrypt and process on a separate box. Depending on your security requirements, you can store the decryption key in software (worst), smartcard (better), or hardware security module (best) such as an nCipher nShield, or Chrysalis Luna. The last two keep the keys off of the physical host, making it nearly impossible to recover the private key without physical access to the host.
Some companies do choose to store the last 4-5 digits of the credit card number and the expiration date in separate fields in the database. This is for user convenience (you can display the numbers so that they know what credit card is being charged).
It goes without saying, but I'll say it any way; the host where the credit card processing takes place should be a secure, bastion host. The only connections allowed should be initiated from the host to the database. This should be enforced by firewall rules. The host should be in its own distinct DMZ.
-LW
I don't know if anyone posted this yet (or if it might've not been moderated above my threshold), but....
One method would be to prompt for the passphrase upon starting the process. That way only a trusted admin (if there is such a thing) would have the passphrase. Then the passphrase would be stored in memory and never on disk.
Of course there's the possibility that someone could cause the process to dump core and sift through it looking for the passphrase. Or someone could read from a memory psuedo device. Either way would likely require root access. You could try and prevent this by obfuscating the passphrase in memory, but that is a cat and mouse game. I think if you went with the premise that if someone gained access to the machine with enough priveledges to read a process's memory space, there's nothing you could do.
_______
2B1ASK1
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
how about storing only public key on the host that collects information and keeping private key on another host separeted by airgap? that way even if the networked host is rooted, there is no decryption key on the host. also maybe some kind of message authentication code could be used to make sure no information is missing/altered. I remember seeing paper by schneier... something like "keeping secure logs on insecure hosts". maybe there is some info there?
Yeah, yeah, so CC #'s are important. They're so important that we give them verbally over the phone, we fax them in forms and we trust 19 year old waiters with them daily.
Let's have a little perspective. Sure, keep them encrypted, don't unencrypt them unless you really need to and then make sure the key isn't saved on disk in plaintext. Lock down your machines (no telnet, in particular) and use intrusion detection software. All good, all fairly standards-based and not very expensive.
But I don't see a serious need to install some sort of Rube Goldberg, quantum-kryptonite system that will be hellishly expensive and probably break down all the time (taking your critical data with it).
You can use the approval code with a good payment gateway. This is what payment gateways are for.
This is where S/N really comes out. It's obvious that many people on here haven't actually done e-com, or if so, not seriously. To clarify for others talking out the ass. The person needs to do recurring billing. You can't just get on VisaNet and say "bill that guy again". The card number needs to be stored. They also need all the billing address and phone number. This needs to be done for AVS. If you don't know what AVS is and you posted in the thread you're part of the noise. Not having all the info costs merchants real money. There's more to writing a good CC Number system than being able to patch a web form into Signio/Verisign.
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.
Yes, nicely worded.
That's one of the things I tell people when I'm speaking on the topic of credit card theft:
How do you know how well a site is protecting your card number? Go to your user profile. Can you see your full credit card number and expiration date there? Well, guess what...
Comment removed based on user account deletion
Philip Greenspun's idea is ideal.
a l
"What would plug this last hole is for CyberCash to give us a public key. We'd encrypt the consumer's card number immediately upon receipt and stuff it into our Oracle database. Then if we needed to retry an authorization, we'd simply send CyberCash a message with the encrypted card number. They would decrypt the card number with their private key and process the transaction normally. If a cracker broke into our server, the handful of credit card numbers in our database would be unreadable without Cybercash's private key. The same sort of architecture would let us do reorders or returns six months after an order." - Philip Greenspun - http://philip.greenspun.com/doc/ecommerce-technic
This lets us store credit card numbers and even we don't have access to the numbers once they are stored. However we can still communicate with our credit card processor and perform any necessary operation with this card number.
Coding Blog
Comment removed based on user account deletion
Comment removed based on user account deletion
Set it up so part of your security is only alowing people with the correct MAC id to even gain access to your machine.
Also, use rolling passwords. That way they have to have the device that tells them what the password is at a given moment.
Then, store the decrypt key on your partners machine.
If you want to prevent insider, ultimally you will need physical security. I recommend talking to IBM about there server room security.
The Kruger Dunning explains most post on
Comment removed based on user account deletion
First, let me say that the safest thing you can do is not store sensitive data. Barring that, the next safest thing you can do is store sensitive data on a physically secured machine(s) not attached to a network. Any data accesses/transfers should be done "manually" (moving HDDs, or CDs, etc.) and logged by trusted personnel. Barring that, you want your database
process to be able to locally decrypt stored data. This implies, regardless of encryption scheme, that the secret portion of your key somehow be locally available. Because the key is available locally it is subject to attack if your server comes under attack. Therefore the only thing you can do is make access to the secret key as difficult as possible...
First, regardless of the scheme you choose you should monitor this machine(s) and the database process(es) to the best of your ability to detect aberrent behavior. For example, if a database process dies, you need to understand why -- was someone trying to cause a core dump to get at its memory? Logging of machine level and process level events and online/offline auditing of your logs can help detect aberrent behavior. Contact a security firm if this kind of stuff keeps you up at night.
Second, physically secure the machine(s) to the best of your ability. Hosting facilities generally provide pretty high physical security. Buy good locks for your cage(s) and only give logged physical access to trusted personnel. You can get as crazy as you want with physical security if you are really worried...
Off the top of my head I can think of two ways to make access to your secret key difficult.
(1) Store the secret key only in the volatile memory of your database process -- don't allow core dumps of any sort and don't allow your process to swap to disk. The key should be entered by hand by trusted personnel through a secure terminal upon database process reboot and rekeying of the database.
An attacker from outside would need to be able to get access to the memory of your process and sift through it to find your key. There are ways to do this, but it would require a pretty sophisticated adversary. If you are monitoring activity on your
machine you would probably be able to detect such an attack. If a machine was physically stolen, continuous power would have to be supplied to it during the theft -- doable, but somewhat difficult.
(2) Have encryption/decryption performed by a "tamper-proof" hardware card or attached machine. Here, to "get at" the key the
attacker _should_ have to convince the card that he is the authorized process, usually through a challenge-response mechanism. At some point a secret needs to be provided to the process. The advantage with this method, is that after it is authenticated the process can forget its authentication secret and/or that the authentication secret is only good for one authentication. Again, the authentication secret should be entered into the processes' volatile memory by trusted personnel through a secure
terminal.
In this scenario, an attacker from outside would have to hijack the process after it has been authenitcated and direct it to execute his code. This attack is doable, but with good monitoring should be easily detected.
Insider attacks are much more difficult to prevent. With trusted inside personnel you can usually only depend on unimpeachable event logs to track down attacks after they occur. When trusted insiders collude it may be next to impossible to prevent and/or prosecute attacks.
But since the system is administered and controlled by IBM (or any other company), they become liable for problems. Therefore they're going to be on the ball about controlling access, etc, and limiting their liklihood of getting sued.
The living have better things to do than to continue hating the dead.
Excellent solution.
Mod Up. Clear description of sound answer.
The perceptions here are somewhat incorrect..
Let me explain..
Encryption was orginially employed to secure non-known data that is not known to the enemy or hacker.
The problem with CC numbers is that you can thorugh a few rules and use of the mod fucntion generate all valid cc numbers for all major cc companies.
So what we have here is avery unsecure index value if you wil to the actual insecure data of the person themselves, ie address, ss number and etc..
If I encrypt the cc number..its still vunerable to a standard dictonary attack..
A better way would be to use privvate=public encryption key pairs to encrypot the cc numbers and the associated data..
That would stop dictonary attacks on the cc numbers themzselves..
But remeber here tha tyou are building a system where the componenet shave to work together well and work if one fails without compromising anything...saem design requirements for major aircraft, spaceships, and etc.
Don't Tread on OpenSource
CC account numbers are only 19 digits long. There is just no good way to encrypt these that is not subject to a dictionary attack.
I have to say that I really like that attitude. But I still wonder if the convenience and efficiency provided by storing your customer's info would be better.
But cookies are not persistant. Is this what you meant?
"The only rights you have are the rights you are willing to fight for."
You can brute force CCNs. Only about 1/10 are valid, and if you know MC v.s Visa you know what it begins with. If you know the bank you know more numbers. If SHA(ccn) == test... You can hash a block of numbers and look.
Add some junk or the address or something that wouldn't be compromised on the same server.
CCNs would take a while, but I'd still worry. SSNs or other smaller numbers would be completely insecure.
I dont agree with the arguments for storing CC info. It's not necessary, why not use a bank for financial transactions? Someone commented they need to store the info so they can refund money if needed, banks can do this just as well.
:(
If organisations like the FBI keep their sensitive data totally isolated from the internet, because thats the only way to ensure its safe, then getting Slashdot security advice for storing CC info on your system is seriously asking for trouble, in the order of million $ liabilities
The approach I prefer is to isolate the risk to a separate machine. The incoming credit card number is passed directly through to a separate billing machine along with the associated user ID and overwritten in the webserver's memory.
There's a very limited connection between the two machines - this could be as simple as a serial cable or as complex as XML-RPC or SOAP depending on your needs (the simple approach is easier to secure but may not be suitable for your environment). The webserver request a few limited operations - "Bill user #... this amount", "get a list of transactions for this user", "update the card info for this customer", etc. The billing system is very restricted, so everything else must be done on the console. The idea is that there's very, very little on the billing system and you can carefully lock the system down as much as possible.
This doesn't protect against a cracker who just wants to create a customer service nightmare for you - he can still bill your users arbitrary amounts on your system. Depending on your needs, you could setup some policies (e.g. max amount over n days) to make this harder.
There's no good way to protect against interception from the client-side, either - code-signing is useless unless you know you'll have a component installed on a significant number of client browsers which will always check a client-side encryption system using your carefully protected code-signing key and cannot be transparently "upgraded" with a trojan. If you can magically provide this, you could encrypt the data with the billing system's public key on the client.
Q. What's the shortest path to build a bridge from Alaska to Australia.
A. Don't build a bridge. Build a boat (or plane)
There are a number of companies that make equipment to handle this type of situation - NCipher is the only one I'm familiar with specifically (I've never used it - just evaluated it).
Basically its a PCI card, or a little box with a SCSI connector on it (don't ask), that you plug in/hook up to your server. The card/server can then store keys internally and perform operations on data passed in & out of it. So, generate a key, store it on the card/box, write your app to pass CC info to the card library, statically link the library into the application and then erase the library.
To protect the information from physical tampering, the card and the box implement FIPS-grade protection. The card is level 2 (iirc) - the chips that store the data have a big thick black cover on them. Should you tear that off, it creates a chemical reaction that destroys the chips and their data. The box can be FIPS level 3, which means if you pick it up or otherwise shake it, the keys are destroyed.
Key escrow is handled by built-in smartcard readers, and you can do secret sharing (i.e. requiring two-of-five people to insert their smartcards to load the key).
It's not cheap - the lowest-end model is 11k, as I recall, but it gives you what you need. It's a secure mechanism for maintaining secret data.
For an extra level of paranoia, use LIDS or Argus Trusted Solaris, and use ACLs to only grant your application permission to access the device files for the key storage. That way, even if someone wrote an app and linked it against the key management lib, they can't get at the device instance to do anything.
Just depends on how much you're willing to pay and go through (hassle-wise) to get real security.
Thanks,
Matt
me@mzi.to
The wole premise of your problem is that you are trying to secure your end; this only works if your end is the target of an attack/exploit/whatever credit card fraud goes alot further, so, why not cease to log this stuff in a database and just print it out on paper, lock it up somewhere until it is needed again. This reduces the ability of a remote comprimise in the future.
Sure, it's less efficient, but the faults on your end, in real-time are fewer, an unscrupulous employee has just as much ability to commit fraud either way. But remote hacks have been reduced to MitM, and social-engeneering, which you should take to task at any rate.
Don't you think that an employee will be a bit more scrutinizing if he/she is asked to go down the hall to the filing room and dig up 40 odd transaction reccords. YES!
If it's just a matter of some kind of SSH vunerability, and looking up and down for private keys, you're dead. If it can happen, this is probably the most likely way.
If someone had your secret key, then by definition, they don't need to run a brute-force attack of your keyspace.
Barring weak links of:
poor keys (easily guessed, too-small keyspaces),
people (HUMINT, bribery, "rubber hose" queries, sticky note passphrases),
network (sniffing keystrokes across unencrypted LANs, Magic Lantern/ software keyloggers), or
physical (TEMPEST attacks, hardware keylogger inside/near keyboard, stealing a computer/drive or backup tape and doing forensic analysis on the data),
...without the key, a brute-force method should be the only way to read the data.
kill yourself
I work at a Bank. We issue credit and debit cards. We store the data somewhere. We have to. not just the last 4 digits.
So your solution does not always apply.
In general, though, you're right.
"Piter, too, is dead."
First, instead of faking up a general purpose computer as a crypto box, you are much better off getting a FIPS 140 rated hardware crypto device. They may cost a bit more up-front (although they are becoming cheaper), but dedicated devices have a lot of advantages. They are designed for security from the ground-up, and you don't have to worry about the "weekly" patch. They usually perform cryptography much faster (think SSL accelerators), and have better protection against insider attacks too.
Second, you need to break down the data access requirements. Carefully look the functions that need to be performed. Many times when you think you might need access to the data, you really can get by with something else (for example as mentioned in another thread, you can create a cryptographic hash of CC info, and compare it with a stored hash).
Most importantly, the design should not require the crypto box to decrypt the data. It does not matter how safe the crypto box keeps your keys, if the hacker can decrypt the data by hijacking an existing decryption script. So long as the crypto box can't decrypt data, the hacker could have complete control of the machine and still have no way to get the protected information. You can see this also protects against insider attacks too.
A logical questions is how do you actually use the credit card info, if the crypto box encrypts it right away, and has no way to decrypt it? The basic technique is to allow the box to make limited "translations". For example, incoming data is translated from SSL to a database key. Another transaction translates the data from encryption under a database key into a switch key. If someone absolutely has to see the data in the clear, make them use a smartcard; and have the crypto box translate the data into a format that only that specific smart card can decrypt.
You can see why you have to be so careful about knowing what functions need data access. Actually, I'm leaving a lot of things out, but here are a couple more considerations. Be very careful with the allowed translations, since you don't want to allow the attacker to translate the protection into a usable or weak format. Also don't forget about auditing all of these transactions (a Visa requirement).
I'd recommend starting by looking at crypto box vendors. A traditional way is to get a crypto box that either already supports this type of application (protecting CC info is a common problem), or to arrange for custom commands (also see Atalla, Thales, and Eracom). There is a relatively new concept of running ordinary programs on a secure box (such as nCipher). I'm kind of skeptical of this approach, since designing a logical secure interface can be fairly difficult. I recommend using PKCS#11 based boxes only with great care, since the protocol has some significant logical security problems, and is probably not the right type of tool for this issue.
A problem with using a diskette for both transfers is that it would delay transferring the CC data off the main computer.
Makes buying stuff with cash sound much better =) I think it would be nice if I could go to my bank website, enter my name and password, and issue a one time credit card that I could use on a website to buy something with. I would make it for the exact amount of the sale, and it would only be used that one time. If someone gets that number later, it wont matter.
My only thought to all that is this:
I buy something with a one time credit card issued from my bank or whatever.
I get a refund on said 'something'
The company I got a refund thru would send that info back to the bank, but could they securely trace that 'one-time' credit card back to my account?
I guess what im thinking is an FDIC insured paypal =).
Up front, I dont know what im talking about. I had heard of other people in this thread mention that you had to keep records of a credit card sale for later use (to cross reference with credit card companies, or whatever it might end up being). Does yer system accomidate for this in any way, or is it untrue (about having to keep records), or do you not live in the us and its different there or what? I apologize in advance if its a dumb question im really sick today :-o.
I mean, who would think of that?
Don't put the private key on the server, put the public key on the server and use PGP or GPG to encrypt using the public key. This can only be decrypted with the private key.
Keep the private key on a seperate network - perhaps the one for billing (you didn't put that on the internet, did you?) and require the passphrase be entered each time (don't store in a file) that access to the sensitive credit info is required. This should only be once a month at billing time.
Use a file dump to CD or tape to "walk" the data from your internet systems to your private network.
All those moments will be lost in time, like tears in rain.
All it takes is a couple people with Uzis. Then you pull the server off the rack and walk out the door. As with anything else in this world, it really depends on how badly you want something and what you're willing to do to get it. I do agree with you about the problems about relying on another company to look after your security. Even though you may hire IBM or whoever to look after your systems, it still remains your responsibility.
www.clarke.ca
so much hubris... and such a small mind
How do you know how well a site is protecting your card number? Go to your user profile. Can you see your full credit card number and expiration date there? Well, guess what...
I'm the guy that posted this question to ask slashdot.
Our customers cannot see their full credit card number, because in order to decrypt the credit card numbers, a person has to supply our program with our passphrase. That, in combination with the secret key on the machine, is used to decrypt the cards. Obvious the passphrase isn't stored anywhere on the machine.
Comment removed based on user account deletion
Why not just store the key on a removable device. Doesn't have to be a fancy smart-card system, could be a USB key-ring thing, or a small external USB/Firewire drive, or a compact flash card. Most of these have Linux drivers which can map the device to some kind of file-system, which gets automounted when you attach it to your box. Whenever somebody does the billing, they pull out their key and have at it.
The only true security is an air gap.
I'm assuming that your web server is sitting somewhere else. That you are using some kind of hosting service.
:)
Your public box gets the CC and processes it for validation/billing through your CC service (I used PayflowPro from Verisign).
Your public server stores has it's own secret key and your public RSA key. Encrypt using that pair and store to database. Do not store your secret key on the web server AT ALL.
Later on, you need to re-bill that number or need to access the card number for some reason. Set up a script that dumps the encrypted information to a file and you scp that file from your public box to a box in your internal office. (Don't scp from your public box to your private box, because then your public box will in some way know the private box's password information).
If your internal users just ABSOLUTELY HAVE TO HAVE a web interface to this data, set up that interface on your internal box, lock down the IP addresses that can use it, disable every service that is not absolutely essential etc etc etc.
The theory here is, it is much harder to harden a box on the public internet that must serve pages than it is to secure a box in your internal network sitting next to you on the floor of your office. You can keep your secret key- server public key on this box, or better yet, keep them on a some kind of removable media. Power down this internal box when not in use, do not keep the removable media attached to this internal box when not being used specifically for CC reading.
Be REALLY PARANOID about your internal box. Using this model, the security of your CC numbers rests on the security of your internal box, not your public web server. And, again, it's much easier to harden a box sitting next to you on the floor. You can just unplug the network cable
[oakbox]
Not just answers, the correct questions.
Don't the CC companies have rules and guidelines on this that they require their partner businesses to follow?
A technique that I have used before is to generate public & private keys. Encrypt (e.g. DESWithMD5) the private key with a long passphrase (*not* password) and for extra security, store it on an inaccesable machine. The passphrase should be atleast 20 (maybe even more) characters otherwise the password won't have enough entropy to be useful.
In your server process, for each new encryption generate a new symmetric key (e.g. 3DES) and encrypt the credit card info with the symmetric key, then encrypt the symmetric key with the public key. Store both the cc info and the encrypted symmetric key in the DB. ( It is important to have the intermediate step because CC numbers often start with the same digits)
Now, when you start your offline process or any program that needs to access the cc info (preferably on another machine), you'll need to specify the passphrase for the secret key, so that the secret key can be decrypted.
Et Voila!
hashes in the clear to verify passwords match.
Because the charge on the CC can be done at shipping time and not ordering time (customers like it better this way), because you need to cancel a charge sometimes, or because a customer ask you to "charge the same card as the last time". All perfectly good reasons to keep the numbers.
:)
What should be done : encrypt the CC number on the server, and decrypt it only on the employee personnal system using a custom-made software. This avoid leaving the private key on the server.
Beside CC have a "built in" security feature : they all expire sometime
[I'm posting this because I think there'll be enough answers on how to build good systems]
Critical data and systems should be handled by trustworthy and competent people.
You should place more importance over the integrity of your people than the integrity of your systems. Similarly for reliability of your people. Machines just multiply the abilities of people. Good tool x bad person = bad results.
Structure things so as to limit exposure to the less trustworthy/competent - you'll have these around, they are still useful, and they may actually prove to be trustworthy/competent later. Note that people are competent at different things (and competency can change) and thus should be placed accordingly.
Once you have done a decent job of that, then your job is mostly done - even if the data is accessible to internals, it will be to just a few competent individuals of integrity - they won't screw up or sell out. So you (or a trusted and more security competent employee) design the systems so as to keep the exposure accordingly - physical security, network security. No matter what you do you are going to have to trust somebody. If you have a small business you can do everything, but if your business grows you need other people.
If you can't find any trustworthy and competent people, try to build the competency of a trustworthy person. It's easier to build and test competency than trustworthiness.
The reason why some bad systems don't fail is because there are good people around.
Fix the bad systems but don't forget the people.
Cheerio,
Link.
I think looking more carefully at this question could be one possible answer to your problem. I built a system where an exchange of key data coming in over the net took place in a directory that was shared by a second machine on a local ethernet. The second machine was monitoring that directory a few thousand times a second for updates. When there was an update, it took the key and checked it for validity on the second machine. This seemed to simplify everything because then I just used a very restrictive firewall on the machine that did the confirmation.
I'm sure this is not the best solution and perhaps for a bank or something with mega transactions it might be too slow, but for our needs it was mucho security and it was easy and cheap. In the end security was the least of our problems, but building the system was a lot of fun.
The closest that normal banks come to web access, is "internet banking". Account access is normally carefully controlled and monitored, but I've found some weak implementations too.
That way only the data link is exposed if the Internet server is compromised. You can restrict that data link, such as by having the details server never feed certain info back. To check a password you send the password (or hashed password) over, and get a reply back with the status (OK, not OK). To display a user's data to them a query has to be sent, and some info is not provided -- such as only the last 4 digits of the credit card number are given.
You can be even more obtuse. When the user logs in, use part of the plaintext password to create a hash. Require that this second hash be provided during any queries or the details server won't reply with valid info. Store that hash in a cookie, so it is available when needed but it is not kept in the server. Your Internet server now no longer can request any user data except when the user's machine is making a request. And the details server will complain through a different link if bad requests are made.
It also is not mandatory that this link be TCP/IP. Put your own protocol on it and there won't be accidents with servers accidentally talking to too many Ethernet interfaces.
Of course, the user details server has a separate connection for Billing and other systems which need info such as credit card numbers. And if this is a situation where CC numbers are only needed for billing during a few hours each month, write the CC info on a CD-R and lock it up until it is needed. Updates during the month can be added to another CD-R, then merge them into a single set (yes, "set" in case one CD is not enough). Only the updates would be on disk, until they are written out.
Welcome to the 21th century!
There is no obscurity involved, you can even take out a full page ad in 2600 Magazine and tell everyone how you did it. It doesn't change the level of security you get.
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)
Sure you can root the data processing machine but so what ? You realy don't think that a security aware programmer would allow "SELECT * FROM Customers" query to run ?? (If you do, can I please have some of the stuff you are smoking ?)
Most likely the client would only send some details like name/address over the serial line and the server would reply with the rest of the personal information.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
In fact, the big problem is how to keep your key in secret, we had done it here, by writing the private key in one smart card, and acessing it from terminal, only the user with the PIN of the card, can access it. but remotely its a problem, there is ways to access smart cards thru network(by using activeX) but you'll need to write your code from scratch since all solutions are not free software
The ultimate solution is using the "The Intergalactic WebDing Encryption algorithm". Its quite a complex operation but I will nonetheless attempt to explain the process by which you can encrypt/decrypt data using this process. It is rumored to be used for U.S. military satellite to satellite communication in their location tracking orbitals. The credit card data is passed through the function I usually call "private String hashData(String d){...}" This function takes your String d and converts it to WebDing font. Crack that silly humans!!hahahaha.. hehem..
Your approach works great for one-time purchases. What if I am selling a service that I need to bill you for every month? Asking you for your information again every month is not a solution.
I think what people are usually missing here is that the only place stored credit cards need to be read is when they are used in the billing cycle.
Lets take an ISP for example. I don't want to encrypt my entire customer database because I'll need to search/query it quite often, and it's hard to sort or query an encrypted database. It's up to me to maintain an information disclosure policy that my customers will accept. I'll definately want to encrypt the credit card information though, but nobody should ever have access to anything (internal or external) that displays the credit card information. The only "process" that ever decrypts the credit card information is the application that processes the automatic payments once a month for those who choose to pay that way. You could even store the private key on a floppy or USB dongle drive and allow access only to those in the accounting department who need it. The public key is good enough just to encrypt the data. Store this on the webserver so customers can sign up, enter in their credit card, it gets encrypted with the public key and stored in the database. If one were to hack into this webserver, they would be able to encrypt data, but not decrypt it.
Perhaps store "xxxxxxxxxxxx4321" in plaintext so you could verify with a customer what card we are using and allow them to change the card number. I don't think storing the last 4 digits like this is that much of a risk, YMMV. This would be an optional feature anyway.
But that's simply not true. That is akin to saying Q: "What's 2+2?" A: "2+3=5".
You're not answering the question.
For the question "how do I make a Windows box secure", the answer is: "go through a long and convoluted process of turning off a large number of services, possibly disconnect it from the net, remove the floppy/CD or lock the BIOS with a password to stop booting from anything but the hard drive, etc... but the fact of the matter is it's a long and difficult process and might not be possible..."
Your "answer" of "you don't, you make it Linux" is in fact not an answer at all, but merely a suggestion.
Q. What's the shortest path to build a bridge from Alaska to Australia.
A. Don't build a bridge. Build a boat (or plane)
That is not an answer. It is a suggestion of an alternative means to accomplish what you believe the problem behind the question is.
If the person wanted to build a bridge from Alaska to Australia to allow bicyclists to bicycle straight from Gnome to Sydney, your "answer" doesn't help.
That's why one can't "answer" a question with a simple remark akin to "don't do what you want to do, do this instead".
Okay, first of all, it is hardly fair to say that all personal information stored online will inevitably be compromised. That's patently absurd.
You could reasonably assert that all personal information stored online is compromisable. But there's a big different between the two.
Now, more to the point, many times there is no choice. You mention that not storing personal info online is difficult to sell to your boss. In many situations I would say it is completely impossible. If the client (the real boss) says they want to store personal information, you can advise them against it but the final say resides with them (or they won't be your client for very long).
We have to make compromises (no pun intended) all the time. Yes, you're right that not storing personal information is the best way to make sure it doesn't get compromised. But suppose that's not an option, the question then becomes how can I make my data as secure as possible.
This same thing applies to your last comment. If my boss asks me to secure a Windows box and I refuse, saying "That's impossible, we need to install Linux!" then I'm likely to not have that job for very long. So again, the question becomes how can I make the best of the situation I am forced to deal with.
Being idealistic is great fun, but it doesn't pay the bills.
This kind of adressing a question while leaving the original question open is called "begging the question". People misuse the phrase "begging the question" all the time though, so it is approaching meaninglesness.
...and this lie crawls out of its mouth: 'I, the state, am the people.'
I don't know why you got modded down, I thought your post was interesting and the points you raised should be considered by anyone serious about understanding the issue.
Read the previous post. The guy/gal said s/he works at the bank that *issues* the card. They need the card numbers so they can print your statement, send you a new card, verify charges from merchants, and generally maintain your credit card account.
-kb, the Kent who can't figure out *how* you got mod-ed up.
You gotta remember that the person asking the question has the power to implement a policy, but not the power to change the policy.
If the business is big enough to be head-strong, the suggestion of 'dont do it' is not productive to the questioner, since the business will not listen and change it's practices.
Yes, it is a good option, but in context may not help the questioner.
----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
I agree that that's a small price to pay for security. However, how many end users see this as being more secure vs just assuming that those companies who keep their data provide adequite protection for it? And those companies, while possibly being less secure are a bit more convenient.
Besides, that doesn't solve the problem of implementing a convenient repeat billing feature. Why not keep the CC info on a seperate machine with only one service running - one waiting to accept a bill-me transaction so that if the entire network were comprimised and someone figured out your system and was able to talk to your billing server, the most they could do would be to cause you to erroniously bill your customers - certainly a bad thing, but at least that could be reversed when caught. And if you kept the listener process simple (i.e. listen for the transaction, write the transaction to a transaction file, doitagain) with a seperate process to periodically pick up and process the transactions, you could limit the possability of your exposed service being compromised.
All in all it sounds great, but you'd have to be really specific about what you use to generate hash keys and other crucial data in such a scheme.
Scientists restrict study to entire physical universe; creationist
Hrmm.. I thought begging the question was this:
http://skepdic.com/begging.html
Read Applied Cryptography, by Bruce Schneier (ISBN 0471117099). It covers all the basics of cryptographic systems, in depth, including when to use which kind of setup.
After you've read that, if you want more information about Alice and Bob, read here.
----
Open mind, insert foot.
Perhaps someone needs to explain recurring billing. Here's my go: Recurring billing is like monthly bills and if they have the credit card number they don't have to bother you with asking each month. (Not to mention the possible insecurity of having to transmit it to them)
Hey, you're right, thanks for the tip...
...and this lie crawls out of its mouth: 'I, the state, am the people.'
Comment removed based on user account deletion
Comment removed based on user account deletion
First of all, what evidence do you have to support the claim that EVERY system on the Internet will inevitably be hacked?
Again I am not advocating a position of not worrying about security because "surely WE won't get hacked." I am simply saying that considering most sites have a finite lifetime, I don't see how one can claim that ALL sites will be hacked. But this is beside the point.
The point is, it's not about what is practical, it's about what the client wants. If the client (despite all your best efforts to convince them otherwise) wants to store billing information for its customers so that they only have to login with a username and password to order something (and not have to enter their address and such every time) then you are going to give the client what they want.
And once again, the question becomes how can I make this inherently insecure system as secure as possible while maintaining the requirements specified by my client (or boss or whatever).
Simply saying "Don't do it that way" isn't an option.
Yes you would definitely freeze all the accounts. But think of the ramifications of that:
- Your CC processing company gets pissed at you for causing them hassles. Your risk/annoyance factor goes up, and likely so does your processing fee
- The CC companies have to reissue credit cards to, say, 100,000 of their cardmembers. Or deal with it somehow.
- You lose MAJOR credibility with anybody who hears about it. If this story makes it to the press, it would make you look Very Very Bad. Customers place a very high importance on the security and privacy of their data, ESPECIALLY their credit card information. Not everybody, but most people.
Sure, if 100,000 credit card numbers are stolen the credit card companies and police will be able to cross-reference them VERY quickly to your store (hmm, where have all these people shopped in the last couple years?) but that still won't help YOU.
www.clarke.ca
In the end, my point about the uzis was a little tongue in cheek to just say that if anybody really wants your data, they'll find a way to get it. If the reward justifies the hassle and risk to somebody, they'll do it.
I haven't been into any large hosting facilities since the September 11 deal, but before then I NEVER saw an armed guard in any of the facilities I went to. Not to say they aren't at some, but never were at Verio, level3, etc. Or I didn't see them...
Anyways, it's really just a risk =? reward equation. If myself and one or two others had automatic weapons and explosives and really wanted something, I don't think a smart card reader would really stop us...
www.clarke.ca
List of things for which we have to have the original numbers:
Reissue the card.
List of card numbers issued.
List of cards numbers issued
Report fraud to Gov't
Verify card info on the phone. If the customer reads out the card number , you don't want the custrep to have to type the number and press the "check" button. You want the custrep to be able to follow on-screen. Most customers would get super edgy if they heard keystrokes that matched their reading of their own credit cards.
"Piter, too, is dead."