1

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.

4

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

  • what you mean by salt.if it random value it will return different values in different time that time how we can get same SSN value through makeSSN(hash(realSSN+salt)) – Araf Oct 10 '17 at 12:29
  • The random salt is decided at the start of the process and remains the same value until the end of the process, so for that one run the same SSN will always become the same fake SSN. You don't pick a new random salt until next time you run the process. Each run will then produce different results, but the results within each run will be consistent. – David Spillett Oct 10 '17 at 13:29
  • And, if you keep the code and the salt on the same server with the database, you are begging for someone to hack into the machine and give you a lot of grief. – Rick James Oct 10 '17 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.