credit card details - encryption
Moderator: General Moderators
-
Net_Monkey
- Forum Newbie
- Posts: 11
- Joined: Wed Jun 25, 2003 9:40 am
AES is new since I started needing to handle encryption. Looks like it went up with our most recent MySQL upgrade too (we upgraded to 4.0.11 as our first 4.x release)...nielsene wrote:Ok that sounds secure for the uses the OP was posting about. (Of course it means that the data is transfered from the database to the application in the clear, which may be unacceptable.)
The MySQL manual doesn't list what algorithm is used for ENCODE/DECODE. I'ld probably use the AES_* versions they provide so I know whats being used and I know AES is at least decent...
As for transferring the information to the database, the query is generated in the application and then the query executed by the database, so it would be passed in clear text. That's something I overlooked. We do have the benefit of having the database server and the Web server all installed on the same box, so it's never transferred over the network in clear text.
I do see your point about passing to the DB in clear text, though, so I'm going to work through some solutions to handle the encryption/decryption in PHP itself. That's something I completely overlooked.
Thanks for the information -- I needed another pair of "eyes". I've got some thinking to do...
As I mentioned in the other thread, in my opionion, no symmetric encryption whatsoever is good enough for such data in any type of shared hosting or standard public webserver environment.. The risk is simply too high, just imagine if you have 10000 records in there and a hacker gains access and charges each card five hundre dollars, that is $5 million in liability to you because you did not take all the precautions you easily and at virtually no cost could have..
-
Net_Monkey
- Forum Newbie
- Posts: 11
- Joined: Wed Jun 25, 2003 9:40 am
Apparently you didn't read this entire thread. In another message in this same thread, I pointed out that credit card numbers (and the CVN) are removed (except the last four digits) are removed from the database after the order is processed.Stoker wrote:As I mentioned in the other thread, in my opionion, no symmetric encryption whatsoever is good enough for such data in any type of shared hosting or standard public webserver environment.. The risk is simply too high, just imagine if you have 10000 records in there and a hacker gains access and charges each card five hundre dollars, that is $5 million in liability to you because you did not take all the precautions you easily and at virtually no cost could have..
Trust me, we don't like storing the data on the server, but we aren't about to send it to the person in an e-mail and there aren't a lot of options. We have minimized the amount of time the sensitive information is stored in the database and it's up to the client to update the status of their order -- and we make it a point to mention during training that they need to update the status.
You're never going to develop, devise, or otherwise create a perfect, unbreakable solution. The best you can hope for is minimizing the probability that the data will end up somewhere it shouldn't. I make sure I look at as many aspects as I can and I repair any flaws that are exposed (such as the one someone mentioned today).