As Chris says, so long as you don't need to have the actual SSN in the database and you're just using it as a key then you can replace the ssns with a hash value. A shortened md5 hash will work fine. If your ssn is a 9 char character field then you can take a 6 byte shortened md5 (or sha) hash and base64 encode it for 8 characters total. If your field is 9 zoned then you've a problem :)

On 5/2/2012 11:23 PM, Chris Bipes wrote:
One good approach I read somewhere, is to put the last 4 digit of SSN in the original file and use a secondary file joined by primary unique key, to hold the encrypted fields.

Here is also a problem I have seen. The SSN# being the primary unique key of the file and used to link other tables. Time to redesign your database. But you can make it work by using a one way encryption scheme. That is where the data is also the key. You enter on to the screen the SSN#, (By the way it can be any data not necessarily a SSN#), Encrypt it before performing the DB lookup, and use the encrypted data as the key. The data cannot be decrypted, easily, but you can still retrieve the record if you already know the SSN# in this example.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].