> However, before getting overly complicated, you could at > least do some level of your own encryption without a lot > of research that would prevent the lazy hacker from just > ripping off your credit card numbers. Splitting them in > two tables is not all that difficult to figure out. If > someone wants them bad enough, they're still going to get > them... Having access to your database is one thing, > getting access to your encryption code, even if it is > very basic is at least one larger step towards deterrence.
I don't know. If I had to choose between using the Rijndahl algorithm (the one chosen by the US government for AES, which will eventually replace DES) and telling everyone I was using it, or using some scheme of my own and keeping the details secret, I think I'd go with option 1. The "key" to successful encryption, of course, is key security, and that's where developers are more likely to run into problems. First, they might not realize the importance of keeping keys secure, and second, it might be difficult to both secure keys and make the application fulfill its business goals. For example, if you're storing credit cards, you're typically doing this so that you can reuse them if necessary - otherwise, you're better off not storing them at all. So, you need to keep the card number in an encrypted form, but your application will also need to be able to decrypt the card number when the customer needs to reuse it, and thus will need the key to perform the decryption. To be perfectly honest, I haven't seen a good implementation description for this kind of situation, and fortunately haven't been put in a position to have to deal with this problem on a serious scale myself. I'd be interested in hearing how others have dealt with key security in this kind of situation. > As far as CFENCRYPT, I meant public in the fact that you can > use CFDECRYPT to decrypt the values. Well, yes, but you need a key, unless you can break the encryption scheme used. Of course, since you use the same key to encrypt and decrypt (a symmetric key, I think that's called, as opposed to a public/private key), and since you're typically doing this within your application code, all the attacker has to do is find where you've stored the key. This is a common flaw in encryption usage, but it doesn't have anything to do with the strength or validity of the algorithm itself. That's not an endorsement of the algorithm used by CFENCRYPT, which I suspect falls into the "sucks" category. The best algorithms are, as mentioned before, public in the same sense. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get Your Own Dedicated Windows 2000 Server PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation · $99/Month · Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionb FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
