Ok, I have a couple of nickels to throw at this:
1. MD5 (implemented in CF as the hash() function) is a hashing algorithm,
not an encryption algorithm. With MD5, you can only "one-way encrypt" data.
In other words, you can determine if you have the content that was
encrypted, but you can't decrypt it. Which is why it's so useful for
storing passwords. The ColdFusion encrypt/decrypt algorithms are not
suitable for real hardening because they use the same password for
encryption and decryption. Therefore, anyone who can get the encryption
password, can also decrypt the data. So, this would slow someone for a bit,
but not stop them.
2. I've been thinking of putting together a method of storing CC data that
is encrypted using FreePGP, so that the data can only be decrypted on a
[different] machine that has the private key, by personnel that know the
private key's passphrase. If anyone is interested, I'd like to co-develop a
couple of custom tags to do this and release them under the Open Source
license.
That can make repeat billing a touch more difficult, but the vast
improvement in security is worth it.
Daryl
- Original Message -
From: "Greenhagen, Robin" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 04, 2001 8:31 PM
Subject: RE: [KCFusion] Credit Card Transaction Processing
Use Thawte (www.thawte.com) instead of Verisign for the SSL key. It is
$125
vs $380 for the original cert file (key) and $100 per year for renewal vs
$290/yr with Verisign. They are good enough that Verisign bought them
last
year!
On the CC info, for your business, I would imagine that store forward is
probably your best bet for processing, since you already have subscription
services for traditional customers by credit card. For outsourced CC
processing, Authorize.Net is a good/big player, Verisign is good but their
support has been patchy.
Your storage/encryption options are a bit staggered right now, depending
on
what technologies you have implemented.
Some of the encryption options are:
1. Use the encryption/decryption from CF.
Pros: You can implement this in a matter of minutes. The encryption level
is MD5 based (Daryll will correct me if I am wrong), and is probably
sufficient to scare off 99.9% of the hackers. There are too many
unencrypted passwords and CC#s in the world to spend any time trying to
decrypt some that were exposed by hacking into your system.
Cons: MD5 is not 256 bit, TripleDES, SuperPGP, Kill a MainFrame [or Linux
cluster] encryption, so it could be reversed with brute force. Also, if
you
have multiple apps drawing data from your DB, all the apps would have to
be
able to do the decryption via the CF routine.
2. Use your DB to do the encryption/decryption work before storing and
retrieval. This can be a package in Oracle or an Extended Stored
Procedure
in MSSQL 7.0+. The to send CC#'s into the DB, just call the SPROC, the
SPROC encrypts and stores. As you select out, select via the SPROC and it
decrypts with whatever key you give it. There are some examples out there
on the net for this. SQL 2000 makes this MUCH easier, because it includes
UDFs (User Defined Functions) so you could call the ENC/DEC stuff directly
in SQL statements.
Pros: Harsher encryption, closer to the storage device, client independent
(You can get the data from CF, Java, PBuilder, ASP, etc.. if you know the
keys and the calls)
Cons: More expensive (time and licensing on components)
3. Build a reusable object. Using Java or COM, build a bean that does
this
encryption/decryption. Then you call that object from everywhere that
needs
the data.
Pros: Can be widely implemented in your organization for Passwords, CC#'s,
salaries, etc... You can base it on any number of public/commercial
libraries that are out there.
Cons: Time/Money
The number 1 way you MUST protect your customer data is with a strong
network security policy and architecture. Your DB server should not even
be
able to see the Internet, EVERYONE should be behind 1 or more layers of
firewalls, address translation, etc..., all the patches should be applied
on
a regular (weekly) basis to your hosting environment. Any code that calls
these security routines should be compiled/encrypted so that keys and
calls
are not compromised.
Ok, enough already...
Cheers!
Robin Greenhagen
President
GreenSoft Solutions, Inc.
-Original Message-
From: Chris [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 04, 2001 4:02 PM
To: KCFusion-List
Subject: [KCFusion] Credit Card Transaction Processing
We are wanting to start accepting Credit Card
Transactions on our web site. We are looking at using
VeriSign to handle this.
We will be doing less than 1000 transactions a month.
Has anyone had any experiences either good or bad
about doing this with VeriSign or any other payment
services like thi
