RE: [cobalt-developers] SSL on RAQ 4 basic help

["Matthew Nuzum" <cobalt@xxxxxxxxxxxxx>]

> > > be to set up a secure connection via SSL and then send the email
using
> > > APOP.
> > > Is this the best way to do this? If so, how do I actually use the
SSL
> > on a
> > > web page? I know how to activate it on a site, but how do I
actually
> > > implement it for a particular web page (i.e.. the page that has
the
> > > details
> > > entered on to it..)?


> > It is considered very bad form (and misleading) to use a secure site
to
> > gather confidential information (such as a credit card number) and
then
> > use a less secure means (such as plain-text email) to forward the
> > gathered information over the 'Net to another host.  Don't even
think
> > about doing this unless the email (end to end, not just host to
host)
> > will use a level of encrpyption at least as good as that of your web
> > server (probably 128-bit).  Likewise, don't store the data
unencrypted
> > in any files on any system, including the secure server and the mail
> > server.
> >
> > When browsing clients see the padlock icon, they have certain
> > expectations of information privacy.  You may be opening a king-size
can
> > of worms if you violate those expectations for the sake of
expediency.
> >


> How do they ensure that the email, too, is secure?
> 
> Any other suggestions as to how to get this information to the client
> securely? Fax from the server?
> 
> Certainly, I am in absolute agreement that once the credit card info
has
> been transferred it should be immediately removed from the server (an
> email
> can sit in a pop account for days, a fax could be sent daily or hourly
> with
> credit card info deleted on confirmation of receipt by the facsimile
> machine).

I have to admit, that the subject of this thread is probably one of the
most difficult to accomplish.  How do you transmit information in such a
way that is secure but also reliable?

Let's say you rigged up a fax solution, which I highly doubt is feasible
for many people.  How do you know that the credit card number made it
safely?  What happens if the fax machine jams as it's printing the fax
and the credit card is unreadable?  Do you call the customer and ask
them for it again?

Email is equally insecure.  Some versions of email client software can
transmit passwords securely, but most do not use encryption for the
entire message.  This means that the password was securely transmitted
to the server and then insecurely transmitted to a user when they
checked their mail.  What's the point in using SSL at all?

I can propose three suggestions.  Two are more feasible, but have slight
flaws.

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.

The other two options have minor flaws, which I'll point out.

I should mention that I have used both of these for various customers,
so I can verify their "Do-ability".

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.

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.

Administrator's check the database frequently, download the data and
then delete it from the database.  This minimizes the risk of something
getting stolen.

Think carefully about handling credit cards on the web.  You expose
yourself to a LOT of risk.  What happens if you have six credit cards
stored on your server and someone hacks you and steals those 6.  Each of
these people see Thousands of dollars of unauthorized use on their
cards.  What do you do?

What happens if instead of 6 cards, it's 60?  Or 600?  Be careful.

Matthew Nuzum