[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-developers] SSL on RAQ 4 basic help
- Subject: Re: [cobalt-developers] SSL on RAQ 4 basic help
- From: Jeff Lasman <jblists@xxxxxxxxxxxxx>
- Date: Wed Nov 21 15:39:00 2001
- Organization: nobaloney.net
- List-id: Discussion Forum for developers on Sun Cobalt Networks products <cobalt-developers.list.cobalt.com>
Matthew Nuzum wrote:
> The one that is likely to be least feasible is to use a server that
> verifies and debits the credit card instantly, like authorize.net. I
> personally don't like dealing with companies that have a monopoly like
> hold on an industry, and the pricing for these real time credit card
> companies resembles that to me.
Though I understand how you feel and why, I think this is the best
solution for most of us, and has the side effect of leaving us with the
least liability if things go wrong, since authorize.net was handling the
transaction and we don't even know the credit card number.
> Slightly more difficult, but maybe slightly more secure in a ~trusted
> environment is GnuPG. You can encrypt the data using PK encryption
> which is very secure, if your key is secure. So if you're in a shared
> server, it may not work unless you set your key file to be read-proof
> for all users but the CGI that does the encryption. The encrypted card
> number can then be stored in a mailbox and transmitted pretty securely
> across the Internet.
Is GPG a single-key solution? If so then it's totally insecure, since
the key is stored on the server. Use a private-key/public-key solution,
and encode the email with the public-key. Then on your own system
(possibly one not even connected to the Internet) decode it with your
private-key.
> Easier yet is the option mentioned previously. This is probably the way
> that provides the safest option in an easy-to-implement package. Encode
> the data and store it in a database. Send an email to an adminitrator
> that the data is ready to be picked up. The database can then be
> accessed only over an SSL connection and the database password is a good
> strong password.
I just don't like storing the CC# on the server, even in a protected
database.
Jeff
--
Jeff Lasman <jblists@xxxxxxxxxxxxx>
Linux and Cobalt/Sun/RaQ Consulting
nobaloney.net
P. O. Box 52672, Riverside, CA 92517
voice: (909) 778-9980 * fax: (702) 548-9484