[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-users] payment method
- Subject: RE: [cobalt-users] payment method
- From: Rodolfo Paiz <rpaiz@xxxxxxxxxxxxxx>
- Date: Wed Feb 14 14:23:10 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
> 2. Credit Card number will be accepted online, where the host can
> then plug it in wherever they do their credit card transactions
> I'm really *really* wary about putting a customer's cc info
> anywhere on a server where there are also hosting clients.
Forget your standard security risks... Citibank has been hacked (to the
tune of $10 million, IIRC), as have the FBI, CIA, NSA, and pretty much
everyone else you can think of. Egghead exposed THREE MILLION credit
card numbers to a hacker recently. Someday, somehow, those numbers will
leak out.
I believe the only box that's truly secure is the one that's still in
the box. Never store sensitive info like this on a Net-connected server,
*ever*.
Thinking out loud here, if you want to keep this info around:
1. Demand that every customer who wants this have a digital certificate
for email (128-bits at least), and make it clear and legally binding
that *they* are responsible for the security of the computer on which
they store and use this certificate.
2. Take the CC# over a secure connection (obviously).
3. Immediately encrypt the CC# using your private key and the customer's
public key.
4. Email the CC# and the order data, inside a properly formatted email
so the customer knows what it is and how to read it, to a special email
account they use only for this purpose (e.g. secure@xxxxxxxxxxxx), and
which hopefully connects to the Internet once an hour via a dial-up
simply to check this mail before immediately hanging up.
5. Have the customer's mail client generate an autoresponded message
acknowledging receipt of this message.
6. Since only this type of messages get received by that account, the
customer can receive the message and process it to decrypt the info then
import it into their (not Net-connected) database.
7. Use an internal database to ensure that every encrypted message
you've sent to them gets an acknowledgment of receipt.
See if you can poke a hole in this process, and we'll try to improve it.
Or let's use it as one possible idea of how to ensure security
throughout. I've looked it through a couple times while I wrote it, and
it seems to be pretty secure. After all:
* Data is encrypted in transit and immediately upon receipt.
* Customer gets data and stores it off-line.
* You confirm that data gets through to the customer.
* Even if intercepted, which is not bloody likely, encryption with two
keys is going to be *really* hard to crack
> But I really do want the ability to let the host keep the cc
> info on hand and then they've got it for monthly billing, extra
> fees for time spent helping the customer, etc.
The bank that does the processing should be able to accept recurring
charges to an account with the customer's permission without your having
to send the data every time. Check with them for details, but push for
them to allow this kind of thing; it should not be a show-stopper.
> The system is almost ready for release, this one thing is
> holding me up, though.
Wanna beta-tester?
--
Rodolfo J. Paiz
rpaiz@xxxxxxxxxxxxxx <mailto:rpaiz@xxxxxxxxxxxxxx>