Here is my situation : we've got ID, named TIP, from remote and large databases. We want to store all the data, but laws prevents us to store the TIP directly, but rather anonymize them, for security reasons, as these TIP are, indeed, identifying a person and their personal confidential data.

However, as we reconstruct our own databases more or less mirrorring the remote databases, we get the TIP associated with variable data. To be more explicit : the only column that is the same accross the different remote databases is the TIP.

Hence, i've got a problem : i would like to hash the TIP (with argon2 as i heard it's the way to go nowadays), but since the TIP are very low entropy (a dozen of digits), i know i should salt them.

But what to use as salt ? Using a random value sounds good, but then i would have to maintain a table that associate a TIP with its salts, which make the whole hashing process useless as this database would exists along our own, and thus be vulnerable like the others to database theft.

I should also add that i have to maintain also a separate (logically and geographically) database that allow for resending some data (a very low amount compared to what we retrieve) to the original databases, hence there is necessarily a way to uncipher the hashed TIP, but this way would rather be awfully slow, and non-automatisable (that is, a Data Protection Officer will do it himself, verifying accordance to law row by row, because accessing these data depends of institutions strategies decisions, and of the goals and roles of the peoples asking for these lines).

We intuited of some ideas, but all feels like they are roll your own type.

hashed-peppered intermediary

Instead of storing a table associating TIP to its salt, instead store a hash of the TIP (without salt, just pepper) associated to its salt.

I fear that that solution only hide the problem ; instead of a table with TIP, we have a table with hashed but not salted TIP, which is better, but not secure.

Hashing with hash-not-salted as salt

Instead of storing a table, could we use the hash-not-salted of the password as its own salt ? Hence, we can, without any more information, get a high-entropy, configurable cost, UID from a single TIP. Is that theoretically acceptable ?

Another solution we didn't think of

Maybe there is a well-known, battle-hardened, proved solution that will meet our need ?

  • what laws are you talking about here? "Anonymizing" this ID seems like it means disconnecting it from the data. Or is this ID something like a social security number which in itself is to be protected? Regardless, if you can "uncipher" the hash, you're defeating the purpose of hashing in the first place. (This is sort of strange actually... why/how is this done manually?? someone does it on paper??)
    – pcalkins
    Sep 29 at 22:07
  • The TIP is used elsewhere, and would allow malevolants to identify a specific person and know about confidential information about that specific person. As such, we fall under specific laws that prevent us to store the TIP directly, and require us to prevent any TIP retrieval by anyone but a specific, identified person. For «manual», i should rather say «slow and inconvenient». The goal is to ensure a reverse way, but not automatisable from our end, disconnected from our local databases.
    – aluriak
    Sep 30 at 17:58
  • If you need to be able to recover the original TIP data, even occasionally, then hashing is the wrong approach. You should be encrypting the data with a key that is securely stored separately from the encrypted data. Access to that key will be how access to the original data is controlled.
    – Mike Scott
    Sep 30 at 18:24
  • @MikeScott thank you, that is resonating with my follow-up question
    – aluriak
    Oct 1 at 18:33


You must log in to answer this question.

Browse other questions tagged .