Any system is only as secure as it's programmed and it's server shored up. Granted, if you're doing business on the web in a manner that you're going to store credit cards, then you better be able to afford to protect them, whether it's PGP or other. My point is that PGP is not the end all for storing credit cards. You CAN build other systems. Face it, depending on the ability of the hacker, they can get at the cards, no matter where they are. One big problem is when folks put the numbers in databases that are in their web directories. Amazingly, even a short time ago, several high profile sites were storing credit card numbers in databases what were downloadable with a URL. Never put your database (Access) in a web accessible directory.
No system is "hack proof" - but you can at least make them work for it. The harder they have to work, the longer it takes and the less appealing it is to them. Dave ----- Original Message ----- From: "Dave Watts" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, October 04, 2001 2:14 PM Subject: RE: Storing Credit Cards > > OK - while we're on the topic. You state . . .that CC > > numbers have patterns in them that drastically reduce > > the number of valid resultsets . . . why not use brute > > force to just churn out a bunch of valid credit card > > numbers and use them ???? > > If by "use them" you mean "try to make purchase with them", you need more > than a number which falls within the set of possible credit card numbers. > You need a number which has specifically been assigned to a card and that > card's user. > > However, the fact that all card numbers fall within a set of possible > numbers makes it relatively easy to figure out if some number could possibly > be a credit card number. > > I would strongly recommend that you don't simply rely on "munging" the data > to make it secure. As Jochem mentioned, an attacker could simply make a > purchase through your site, then - knowing that number - find your key. > > As for generating a separate key for each card number, that would eliminate > the above possibility. However, you'd then have to secure the card numbers > AND the set of keys, and your application would still require access to both > to fetch a card number at runtime. So, the clever attacker would simply find > the key for their card number, then find the location of that key value, and > then you're back where you started. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > phone: (202) 797-5496 > fax: (202) 797-5444 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
