From: tedd > At 8:09 PM -0400 8/11/10, Bastien Koert wrote: >>From my experience, I'd have to say that it would be a real tough go >>to crack that. If there was a weak point in the scheme is that your >>end result pattern ( the ssn ) is defined with a pair of constants, >>the hyphens. In our scheme we remove the dashes and just provide a >>mask for display. We also keep a unique key with each ssn, the record >>number for extra security. > > The SS numbers can be stored in any format (with/without hyphens, > reversed, transposed, predetermined mixing, whatever). > > Of course, there can be another field where a unique key is kept, but > I'm not sure how that might improve security. > >>Where to keep it is tougher, OWASP suggests that the keys be stored on >>another non web facing server, with a locked down filesystem. That >>would be best if you have the hardware available. > > So that I understand, you are talking about two web sites where one > (domain1.com) would contain/run the scripts and the other > (domain2.com) contained the keys. > > It would work like so: > > When the script launches in domain1.com, the script would ask (after > authorization) domain2.com for the keys, which are kept in a locked > directory. After which the Encryption/Decryption scheme would work. > > Is that it? > >>One other option here is to load the keys into ram on server start >>up and never have >>them physically on the machine. > > I'm not sure as to how to make that work. But I assume that it > requires a dedicated server, right?
If I might make a suggestion or two. 1. Put all of the data on a separate DB server that is not accessible from the Internet, but only through authorized access to the web server. The data should still be encrypted, but at least you can eliminated brute force attacks. Even though the data is necessary for your client's business, it is still privileged information as far as his targets and the government are concerned. Treat it accordingly. 2. Spend some time reading all of the OWASP[1] guidelines and implement as many of them as you feasibly can. That might cost some time (and money) but will be better for your client in the long run. He reduces both his exposure and liability while still being able to use that data. 3. Spend some time reading the PCI requirements in your country and try to implement as many of those as possible. But keep in mind that they exist solely to protect the credit card issuers. You need to figure out how far you need to go in order to protect your client. Bob McConnell [1] <http://www.owasp.org/index.php/Main_Page> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
