How can I create a unique identifier that can not easily be reversed?

Question

I've been working on the design of a longitudinal study and one requirement is:

• all participants will have a unique identifier that
  • is not reversible from the data storage/analyst side of the study
  • is defined by something easily remembered by a participant that is relatively static over several years, ex. a participant's proper name and birth date in a given format.
  • Creation of the unique identifier will occur on the participant's computer and no portion of the defining string will be sent with other collected data

How do I go about meeting this goal?

Initial thoughts are to use bcrypt or something similar but that runs into the problem that if there is a list of possible participant names and birthdays it becomes trivial to determine who participated and their answers. This hypothetical situation is not very likely but concerning.

I've looked into ID based cryptography as a possible answer but the increase in complexity and high likelihood of user error are prohibitive.

Am I missing a simple answer?

Answer 1

There's a simple way to accomplish this with a 2 step hash.

Take a personal identifier for someone SHA256( Firstname Middname Lastname + Birthday) and calculate this on the client side.

Send this hash to a server. Hash this with a single pre-chosen secret of high entropy (128 bits) only known to the programmer and kept secret from any and all researchers. So SHA256(secret+HashOutPutStep1). Store the output in your database as a key for that participant. The secret must of course be the same for any single study. If you like, use a integer unique identifier that maps to the SHA256 generated hash. That would give you an easy reference number for a human to utilize.

This makes it impossible to reverse the hash without knowing the secret, and the results are always the same with the same personal identifier. I believe this solution meets your requirement since the analysts can't reverse this string. The secret must be kept away from analysts, but this is a trivial matter.

Answer 2

What you can do is to provide the participants any userID that is easy for them (like their email address, etc.) This userID is stored in a protected database that the analysts have no access to. When an analyst performs queries, the application creates random userIDs that are mapped to the real userIDs temporarily (even just for that session), thereby providing a unique "key" that might be required for typical SQL-like query tasks, but that "key" is decentralized from the real userID mapping. Once the random key is used, it is dumped and never associated with the user again. This creates a "double-blind" reference that will provide some protection.

There is still risk that a determined analyst might be able to pinpoint users due to aggregation issues, but that risk needs to be evaluated based on the type of data the analysts have access to.

The trick will be the application design that prevents analysts from accessing the userID data. That is a db-application level design issue that an architect can help with.

Answer 3

I would here suggest a kept-secret list of partipicants and a random ID.

Like this: Name Namesson ID=18479 Test Testsson ID=29472 and so on. This is kept secret, and the analyst side do not have access to the list.

The problem with a unreverseable unique identifier, is that you still have to run it through a computer algoritm. Then you could either have the user type their real name and birthdate - then it checks if a entry already exists. If entry exists - replace user real name and birthdate with existing entry. If entry is nonexistant - create new random identity and replace user real name and birthdate with the newly created entry. If you go for a "automatic" ID-system, you must ensure that the same user cannot resubmit the same application. This ensures "testing" of IDs cannot be done - if you enforce so if user X submits a application, the user X is marked as "spent" in database. When next application opens, you simply remove the "spent" marker on all users. Using a "spent" system, you must also buffer all applications so they are not sent to the analyst side until either everyone has completed the application, OR the application "last due date" is passed. Else, the analyst side could simply check by trial and error everytime a single application is received, which user is now "spent".

Or, you issue random identifiers to the users simply. Then the list could be kept on paper, stored in a safe.

A third solution is to use a hash algoritm or bcrypt, combined with a secret key or password. The secret key or password is only known to the collecting side, not the analyst side. This means that even if the analyst side do have a full list of partipicant and a list of all application hashes, they still cannot reverse it through trial and error since they do not know the secret key or password.

The secret key or password can then only be known by the application, and stored in a safe.