How are credit card numbers secured from hackers in a DB normally?
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   neal_ravindran
Posted On:   Wednesday, March 17, 2004 11:01 AM

We have to store encrypted credit card numbers in a DB for recurring billing purposes. Ok that is a risk with hackers galore in our new and modern world, once my key gets compromised. The risk is enormous, because, if suppose the credit card numbers get stolen my company would be liable big-time(which goes without saying I would be jobless under such a scenario;)



How have people achieved this (storage and safe-keeping of encrypted credit card numbers in a DB) in the past? I want a "bullet-proof" solution. How does "Bouncy Castle" fit into this? The DB server would be behind the firewall and would not be in the DMZ (the web server will be in the DMZ)

Re: How are credit card numbers secured from hackers in a DB normally?

Posted By:   neal_ravindran  
Posted On:   Tuesday, March 23, 2004 07:05 AM

We decided on this...

form submitted with credit card number (CC#).

CC# encrypted using TripleDES and a reference id inserted in web-connected DB. Reference id and encrypted CC# shipped to non-web-connected DB via sockets(yes there would be a custom sockets server app running on the non-web connected DB server)

Wehn the time comes for recurring billing, the reference Id in web-connected db is used to query the db table in the non-web-connected DB server (again using the custom sockets server), and the encrypted CC# is retrieved by web app, decrypted and used.


In summary 3 physical machines would be used. The App server machine, the web-connected DB server and the non-web connected DB server.



Can you poke a hole in this architecture? If so let me know

About | Sitemap | Contact