It is a good book (I own it) but isn't there anything newer to recommend on this subject?
Btw, I have your book, too. :-)
(I liked "Writing ...", but it could have used a couple of hundred more pages about modules (chapter 7).)
| [reply] |
It is a good book (I own it) but isn't there anything newer to recommend on this subject?
Nothing directly applicable jumps to mind. If you haven't already you might check out Applied Cryptography. It's a very useful overview of relatively modern cryptographic systems. In the same vein I find the author's newsletter, Crypto-Gram very informative.
Btw, I have your book, too. :-) (I liked "Writing ...", but it could have used a couple of hundred more pages about modules (chapter 7).)
Thanks! Chapter 7 was definitely the hardest to write in the book. I had grand plans for including many more modules and digging into the code in more depth but in the end I was happy to just get it done. It turned out to be quite challenging to present other people's work honestly and fairly.
-sam
| [reply] |
As soon as you've processed the transaction delete the card from your database. If it's not there then an attacker can't steal it!
It's not clear to me that this is always the safest option. Consider a shop where customers come back, and over time, do repeated purchases. If the shop doesn't store the credit card information, customers have to resubmit their credit card info for each purchase. So the shop reduces the number of credit card numbers stored in their on-line database (unfortunally, that doesn't mean the numbers are gone - good database management means keeping backups and transaction logs and those can stolen as well), at the cost of having more numbers floating over the network.
(Further remarks are addressed to the OP)
Security is more than win2k vs apache (which isn't a valid trade-off anyway, it's like saying "shall I have bread, or peanut butter" - you can run apache on win2k. You can make win2k secure, or leave it unsecure. You can set up apache securely, or unsecurely). It's more than the OS, web server, your code and any third party code. It's also the people - many credit card number thefts are inside jobs. Your code and setup can be bullet proof from the outside, it will be of no use if an operator makes a private copy of your database backups.
| [reply] |
It's not clear to me that this is always the safest option.
Let's be specific - you're worried that an attacker could collect CC numbers by intercepting or viewing traffic between the browser and the client. You propose to reduce this risk by storing CC numbers in the database.
This strikes me as a poor security trade-off. It reduces a rather unlikely threat (you are using SSL right?) in exchange for greatly increasing the value of your database to an attacker.
Also, make sure you consider whether you're allowed to keep those card numbers on file. There are FTC rules about this and the CC processors have rules as well. It's quite likely that what you're suggesting is in violation of those rules. I'm sure there's a way to do this which is in compliance but I doubt it involves keeping CC numbers in the clear in your database. Perhaps the CC processors offer a reusable token?
-sam
| [reply] |
This strikes me as a poor security trade-off. It reduces a rather unlikely threat (you are using SSL right?) in exchange for greatly increasing the value of your database to an attacker.
Amen.
Not to mention the additional risk of a "trusted" insider getting access to the database. Most fraud is an inside job rather than the results of the wily hacker.
If you really have to store the credit card numbers then for goodness sake don't store them in plain text.
For example XOR them with the users password so they can't be accessed on mass, and only decoded on an individual basis when the user is logged on.
(I'm naturally assuming that you'll only be storing a hash of the user password.)
| [reply] |