Data scrambling for the development data I have a lot of sensitive data in production like SSN, name, email, and phone number.

I have function to scramble this data using a random value hashmap technique. But in the case of SSN (social security number), we have different tables that contain the same SSN. This causes my data to be messed up because I need to keep keep the same scrambled value for every instance of the same SSN.

Currently, if I have a SSN 12345678 in both the person table and the elige table, then my function's logic causes the tables to have different SSN values after scrambling (i.e. 854612397 for person, 963258741 for elige table).

Desired output should be that the scrambled SSN is the same in both tables.
If you produce the new SSNs with a function like newSSN = makeSSN(hash(realSSN+salt)), where hash() is a known good hash function[1], salt is a long randomly generated string, and makeSSN() takes some/all of the hash function's output to make a nine-digit number output[2]. This way you get the same new value where-ever you have the same input SSN without needing to produce a mapping table to keep values consistent. To make sure that a real SSN can't be mapped to one in the resulting test data by using the same function[3] don't store the salt value between invocations.

Of course the "there are going to be other ways to identify what real person maps to which person in your munged test data-set" issue is something you should be aware of. For truly sensitive data it is far easier to be secure if you generate test data procedurally instead of by trying to depersonalise real live data.



[1] SHA2, SHA3, ...

[2] for example you could take the first or lowest 29 bits, or use CRC32 with output to decimal and strip off one character as it can produce 10

[3] though there are going to be other ways to identify what real person maps to which person in your munged test data-set