On Aug 12, 2010, at 11:55 AM, tedd wrote: > At 11:39 AM -0400 8/12/10, Joshua Kehn wrote: >> Would one option be to have a table of unencrypted SSN's with an encrypted id for the user. So you could search the SSN's and then connect them, however if the table was dumped you wouldn't be able to link it directly to the person (as it would just have a SSN and an id). >> >> Regards, >> >> -Josh > > No, the problem here is to keep the database from containing any raw SS#. It is absolutely necessary to encrypt the data. > > The question is: > > 1. Is it legal? > > 2. How to do it? > > Cheers, > > tedd > -- > ------- > http://sperling.com/ Tedd- In my mind if you have a table of raw SSN's it's fine as long as they can't be readily linked to a person without decrypting the id. Again, I don't know the legalities of it so I defer. If you have to encrypt them then I'm not sure how you would run any %LIKE% query unless you went through and decrypted them OTF when running the query. This (I don't believe) can be done in MySQL (or any other RDB) so it would have to be done in memory. Depending on the table size that gets annoyingly slow. If the SSN's must be encrypted, and you aren't encrypting the parts separately ( enc - enc - enc) I don't think you will be able to run a %LIKE% query simply. Regards, -Josh ____________________________________ Joshua Kehn | Josh.Kehn@xxxxxxxxx http://joshuakehn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
