On Thu, Aug 12, 2010 at 11:32 AM, tedd <tedd@xxxxxxxxxxxx> wrote: > At 10:56 AM -0400 8/12/10, Bastien Koert wrote: >> >> However, the data must be stored in an encrypted format and it must be >> transmitted via SSL. We do it that way (taking both a hash for >> searching for the ssn and the encrypted form) and haven't had any >> issues as yet. > > The data will be encrypted and only accessible behind an SSL via an > authorization process -- that's given. > > I have given some thought about searching the database for encrypted SS#'s > and have been perplexed as how to do that. > > For searching standard fields, it's a piece of cake to use %LIKE%. For > example, let's say the investigator has a piece of paper that has the number > "393" on it and want's to search the database for all phone numbers that > contain "393" -- he could use %LIKE% and that would produce 517-393-1111, > 393-123-4567, 818-122-4393 and so on. That's neat! > > However, if the field is encrypted, then how do you preform a partial search > on that? You can't encrypt the search string and use that because you need > the entire string. So, how do you solve that problem? > > If you hash the number of store the hash, then you can create a hashed > search string and use that. But again it doesn't work for partial %LIKE% > searches. For example, I couldn't search for "393" in a SS# -- I would have > to search for the complete SS#. > > So, how do you solve the %LIKE% problem with encryption and hashes? We didn't...in our case the user either has the ssn or doesn't. No direct searching on ssn without the full ssn is supported. We do allow searching on names so its a work around that way. > >> The other thing to consider is that more and more states are looking to >> encrypt PII data >> (name, dob, ssn etc) for more security. > > I'm considering that as well, but that also raises more searching problems > as described above. > >> You could consider storing just the encrypted ssn and link data in a >> separate database, that would require a different logon to access when >> the data is required. > > Interesting -- I might also hash the foreign link. But I have to think about > that. > > Cheers, > > tedd > -- > ------- > http://sperling.com/ > -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
