Re^2: Paranoid about web application security

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.

Comment on Re^2: Paranoid about web application security

Replies are listed 'Best First'.
Re^3: Paranoid about web application security by samtregar (Abbot) on Aug 09, 2005 at 18:59 UTC
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]
Re^4: Paranoid about web application security by adrianh (Chancellor) on Aug 10, 2005 at 10:47 UTC
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]
Re^5: Paranoid about web application security by samtregar (Abbot) on Aug 10, 2005 at 17:35 UTC
I was with you until the XOR. Please, use a real encryption algorithm! It's so easy to use strong encryption (via Crypt::CBC and Crypt::Blowfish or any of the others) that there's really no excuse not to. -sam	[reply]
Re^6: Paranoid about web application security by adrianh (Chancellor) on Aug 10, 2005 at 19:05 UTC


Your skill will accomplish what the force of many cannot
	PerlMonks