sabren.net archives
back to sabren.net...
back to the
archive...
entries for 2002/9/08
encryption
I've always been nervous about storing credit card numbers in a database. Zikeshop simply stored the numbers without encryption,
but knowing how dangerous that is, I simply haven't stored
credit card information at all for cornerhost.
The upside is that no one can steal numbers that aren't there.
The downside is that my customers have to enter the same
information month after month. Worse, sometimes people forget.
So, in the spirit of making it as easy as possible for people
to give me money, I want to store the numbers and make sure they're very very hard to steal.
My problem has always been the key. An encryption program needs a
key to encrypt data. Usually, if you have the key, you can unlock the data. If the key and the data are on the same machine, you're basically screwed.
Of course, I knew there was such at think as public key encryption, and I thought I understood it, but I was wrong. For some reason, I thought you used your private key in conjunction with
someone else's public key to sign data. I assumed that if you had
both your private key and their public key, you could
decrypt something you had just encrypted. I thought, therefore, that the data was secure as long as neither your private key nor their private key was available to an attacker.
But it turns out that's not how it works. My private key
isn't needed at all to encrypt a message to you. All I need is
your public key. As one book I'm reading points out, a public key is really like a safe. I can put anything I want in the safe,
and lock it, but then I can't get anything out again. You're the only one who can do that, because you have the private key.
GnuPG (and presumably PGP)
take this one step further: your private key itself is encrypted
with a passphrase. Assuming the phrase is sufficiently hard
to guess, the data can't be encrypted without it.
So. Someone can log in to my site, and give me a credit card number.
I can then encrypt it with a public key, store it in a database, and not have to worry about someone getting the credit card numbers, even if the database itself were compromised.
The private key can be kept offsite, behind a firewall. When I want to run credit cards, I download the list of transactions to make, download the encrypted credit cards, manually type in my passphrase to decrypt the card information, and then run the transactions. All of the data transfer gets piped through SSL, of course. That should be it.
I like this, because it's an example of solving a business
problem (collecting my receivables) by applying technology
to the core cause of the problem. :)
Of course, I still have to implement all this... :)the magic of fleas
Great fleas have little fleas
upon their backs to bite 'em,
And little fleas have lesser fleas,
and so ad infinitum,
And the great fleas themselves,
in turn, have greater fleas to go on,
While these again have greater still,
and greater still, and so on.
-- AUGUSTUS DE MORGAN, English mathematician (1806 - 1871)