[thelist] how secure to store credit cards

[Keith]

Erik

> >http://evolt.org/article/Credit_Card_E_Primer/18/12694/
>  From reading that article, it seems like you can pretty much do
> whatever you want and hope nothing bad comes of it ... that just
> astounds me!

Perhaps you need to re-read the article. I think it says just the 
opposite. If you institute a method that exposes the cardholder to 
theft you are personally liable and penalties are extreme. However, 
VISA's guidelines March 2001 leave a great deal of latitude in how 
you set up your own security. If we all used the same concept we 
would have told the bandits what not to work on and made 
ourselves equally vulnerable when they crack the one shared 
concept. As in all things, there is strength in diversity.

> This is going to be for orders of products that need to be shipped,
> and to my understanding it's illegal to charge a card for a 
>purchase before the order has shipped.

All web credit card transactions have two stages, the first stage 
authorizes the amount, removing it from the card's availability, the 
second stage actually charges the card. The first stage reserves 
the amount for 30 days pending shipment. The second stage 
cannot be done until the product has been shipped. Most accounts 
require at least 24 hours between the two stages. It's not obvious 
but even over-the-counter transactions use both stages, in an OTC 
transaction the second stage is called "batching" and is done once 
a day, either automatically or by request.

> So my task is to find a  way to keep the card number until the 
> order has shipped. -- 

Do not do that. Your real task sould be to find a  way to keep the 
card number only until the number has been removed from the 
server and stored offline. Since you indicate that you will be 
authorizing and charging the card with offline processes you have 
no reason to leave it on the server, get that info off the web server 
ASAP, not after shipment.  Nothing else you can do will make your 
setup more secure than doing this.

>What are thoughts on encrypting the card numbers with CF's 
>Encrypt() and accessing them through SSL where the key has to 
>be given ... they key would have to be stored somewhere on the 
>webserver of course ... which bothers me ... ideas?

I'm not familiar with CF's Encrypt(). But there are two kinds of 
encryption. The crypt function encrypts a string in a one-way non-
reversible hash. That data cannot be unencrypted. This method is 
used to store passwords. Once the encrypted value of the 
password is stored a user submits their password, which is 
encrypted and compared against the stored encrypted value, if they 
match then the password submitted was correct. That obviously will 
not work for storing your credit card info since you need to 
unencrypt it.

You therefore need to use public-private key encryption. The public 
key is stored on the server. It encrypts the string but it cannot 
unencrypt the string. Only the paired private key can unencrypt the 
string and it is not stored on the server. When you go to get the 
orders off the server you submit the private key  so the server can 
unencrypt the string and return it to the browser. At no time are the 
unencrypted string or the private key written to the server, they just 
exist in memory and the entire sequence is done within an SSL 
session. PGP is the most commonly used public-private key 
program for this sort of thing. Cold Fusion may have a built-in PGP 
module available to Encrypt, the way you describe Encrypt  the 
private key would not be stored on the server, just the public key. 
On the other hand I suspect that Encrypt just does a one-way hash 
like for password storage.

>Is there a service where the entire transaction could appear to the 
>visitor to occur on the server

No, that's a violation of ethics and legal code. The cardholder has a 
right to know what domain their information is being submitted to. 
Any attempt to mask that destination is fraud and a violation of any 
merchant account issued after March 2001. For example: if you use 
a page from your server containing a form submitting to a different 
server the browser will warn the user that their submission is being 
redirected, unless the user disables that feature in their security 
options. Many services allow customization of their submission 
pages so the look and feel of your site is expressed on their page. 
But only a fool would allow you "have to have complete control over 
all the HTML." on a page on their server if they are conducting 
transactions.  The only way you are going to have complete control 
is to take complete responsibility: SSL enable your own server, 
store the data on your server, etc.

Here's something else to think about, does your customer know 
and trust your client, know and trust your security? Of course not. 
Instead of seeing a third party web page as a problem try looking at 
it as a feature. Make it clear to the consumer that their transaction 
is being done on a different server, a server run by security experts. 
The best setup I've seen for that is Bank Of America. It's obvious to 
the consumer that their information is being submitted to, and 
stored by, a major bank, that their information is being handled just 
as securely as it would be if they were at the teller window in the 
bank. I've seen websale increase 30% simply by converting to this 
kind of a submission. Web consumers feel more confident, and you 
can sleep better at night. Just a thought.....

keith

BTW, if you sell to Europeans, the cardholder's billing address, the 
item purchased, and the amount of the purchase need to be 
protected just as much as the credit card number. They justly have a 
very strict attitude about privacy in the lands of the Euro.