I have noticed that you have posted quite a few really simple ASP.Net questions lately - like you've been asked to do something outside your normal job description? Is there anything we can do to help you pick it up more quickly? You always seem to have a good college try at things, which is great, but I wonder if you're getting frustrated often? Do you think there's any way we can help so you don't have to wait for answers to get past this kind of thing? I hate to think there are users waiting on the kindness of strangers.
I read the other post, which says to never store credit card numbers on your server.
I thought about the subject, and don't find a difference in storing a token number to use a credit card number on a payment gateway server versus just storing the credit card number.
The trick is to never expose the number, only display cloaked numbers.
But try to use at least 256 bit encryption if you can, and choose a type that is supported by c++, .net and so forth, in case you need to encrypt and decrypt in other operating systems in the windows family.
Be careful now, the world will be on your shoulders.
don't find a difference in storing a token number to use a credit card number on a payment gateway server versus just storing the credit card number.
One of the differences is that the payment gateway has probably been through a thorough Q&A procedure. Another is that it's usually the provider of the payment gateway that carries the resposibility if anything goes wrong, as you usually redirect the user to a site operated by the vendor of the payment gateway to perform all operations related to online payment by credit card ...
Now, if you encrypt the data, how do you handle the key? If you look at the OWASP Top 10 for 2010, 'Insecure Cryptographic Storage' ranks as the 7th most common security related error.
I get payment gateway vendors calling me every week to use there services. They claim to pay for my PCI testing, but in return, I have to shift all of my customers to their service.
The ultimate problem is where to store the keys. If you store the keys where an IT employee can gain access to them, then you have a breech in security, and that employee can turn on you and sell the keys and the data.
I have to shift all of my customers to their service
Not really, they should handle only the operations related to the monetary transaction, and never touching the credit card info of your customers protects you from potential slander too.
If you store the keys
If you do that, you really have to be sure what you're doing. In an deal world I would not touch anybody elses certificates, or anything else that can be used to compromise the security of their system. When the sh*t hits the fan, people will be looking for scapegoats - so I do things the standard way leveraging the capabilities provided by the platform that can be configured using tools provided by the platform vendor.
I'm not joking about the payment gateway vendors here in the US.
In the beginning, about the year 2006, one company in Denver Colorado offered the token service.
I wanted to write for Chase Payment Tech, but JP Morgan cut a deal with a company in Denver to give them all the gateway business, but in exchange, you had to use their token system. They wanted my company to pay them a huge fee to use the system ($7500.00 USD), plus change my software to a single payment gateway solution.
I did some digging, and found the API for Orbital-Salem and Tampa, and a sandbox yo test against, and was able to write my code for Payment Tech.
In about the year 2010, I started getting calls from these small payment gateway start ups. Same scenario, but they claimed to pay for everything. But the terms of agreement were identical.
In the year 2011, I started getting calls every Friday morning, from various payment gateway companies offering the same exact service with the same exact terms, after a couple of months, they kept calling and starting threatening me with terrible scenarios.
I've come to the conclusion that someone out there wrote a token system for payment gateways, and sold hundreds of copies of the program to cash in on the credit card processing market.
Overall when considering the trade off, with morality as the focal point, I don't want to get locked into their system, locked in to monthly fee's being raised every 6 months, out of control AVS look up surcharges, Batch Capture surcharges, to the point where the normal service fee of $20.00 a month goes to $150 a month. - And then I'm trapped and I can't leave them, because my application is dependent on them.
I'm not looking at this from just a programming point of view, or the theory of practical security, shifting responsibility or blame up the ladder. I see the whole picture in play here.
I can see me getting blamed for not protecting the tokens and it all comes back on me.
I respect your opinion, and overall in theory it makes pure sense, and is the logical choice of course, but then the morality of people come into play here.
Money, morality - those are words you seldom see mentioned in the same sentence.
I've implemented 'real security' three times in my life - I think the stuff I did works as it's supposed to, but that's the only pieces of code I've written that I've ever been really nervous about.
I like your website, nice and clean.
Thank you, I think it needs a brush-up to look modern, and lately a few pages doesn't work as they are supposed to. I looked long and hard at a prize winning site when I built it, and I guess I borrowed more than a few ideas.
You lit my fire today, and hit the torture button on me.
After reading Jasmines comment,
I was wondering who's drinking the red or blue kool-aid. (Kool-aid is a powdered drink for kids that comes in various colors and flavors, with a reference to Morpheus and the red or blue pill).
I wrote my eCommerce App, sweated out the credit card encryption and security for years, had numerous conversations on the subject. And the question I always ask myself, are they really that much better than me, or is it just talk and aggressive persuasion, projecting pure confidence on the subject as if I'm a moron, yet they did the minimum required to protect sensitive or personal information.
Perhaps it's like stealing money, you can rob it from the cash draw, skim it, rob a bank, counterfeit it, swindle it, create digital counterfeit currency, steal it electronically, and it just goes on and on, limited only by the imagination.
Espen Harlinn wrote:
I've implemented 'real security' three times in my life
When our time comes and we pass on, we may never know the answer. Your a sharp guy, I'm sure you thought it through.
Alright, this is a dead horse for me, and I'm not going to beat it with my stick anymore.
To close, the answer I always got back was the same, - people will hack the path of least resistance. - Joe Maloney
The difference is, the token authorizes a certain thing, like a one-time payment, on a particular card. The card number itself authorizes almost anything you want to do. So, the token protects both parties.
For PCI compliance you CAN NOT store the CC NUMBER. You must obtain a token from the authorizing service and you must use that. Some tokens are one-time usage, but others may be stored to authorize monthly payments for example. You may store and display the "LAST 4" of the credit card number to help the user identify which account is being used.