4

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?

  • What do you need to keep in the data storage? If you don't keep the birth date or name it is much more easier to make it not reversible... – ForguesR Jan 22 '15 at 18:53
  • Database, most likely postgres. We won't keep birhday or name, just the unique id. – bob0the0mighty Jan 22 '15 at 18:56
  • You need to separate the id data from the data that can be accessed by the analyst. The term you are looking for is "access control models" en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model – schroeder Jan 22 '15 at 19:08
  • I updated my question with one more sub-requirement. I want to be explicit in that, whatever defining string we choose, no part of the defining string will be transmitted or stored. Only the unique identifier may be transmitted. – bob0the0mighty Jan 22 '15 at 19:31
2

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.

  • This meets my updated post and is probably the route we will have to go. – bob0the0mighty Jan 26 '15 at 21:22
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.

  • This doesn't meet the requirement that: no portion of the defining string will be sent with other collected data. – Steve Sether Jan 23 '15 at 16:07
  • I like this answer but it doesn't meet the updated question. I particularly like the explicit note on aggregation issues as I brought this up as well but most people involved with the study don't see this as a problem. – bob0the0mighty Jan 26 '15 at 21:24
  • @SteveSether It can meet that requirement. The problem is not with the "sending" but with the "relationship" of the data. – schroeder Jan 26 '15 at 21:34
0

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.

  • your suggestion doesn't satisfy the "easily remembered" criteria – schroeder Jan 22 '15 at 19:17

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.