I do research with people about their illegal drug use, and for one project I'm doing surveys with them when they visit a needle exchange. So over time the same people get repeatedly surveyed as they visit the exchange many times over.
In order to link together multiple surveys from the same person across time (because we want to track things like engagement with drug treatment and changes in level of drug use), I ask them to give me some information that they can remember from visit to visit but which would at least moderately limit the ability of someone to identify them from it: the first two letters of their mother's first name, the day of the month on which they were born,and their gender. E.g. a woman (
F) born on [month]/20/[year] whose mother's name is Jane would get the code
So every survey gets this code as a unique identifier, and you can link multiple surveys done by the same person without having to record blatantly identifying info like names and dates of birth (or ask a street-based drug user, potentially with mental health problems as well, to remember a unique study ID from visit to visit). Not perfect from a security point of view, and not unique if you have thousands of people, but when the data is being entered on a single laptop with full disk encryption and all study files are stored encrypted and you have a Federal Certificate of Confidentiality (protects research data on illegal activity against subpoena), and there's only about a thousand people using the service, probably good enough.
But storing that identifier still bothers me. I'd really like to do something to it at the point of data entry so it can't be 'reversed' back to the potentially identifying day of birth, gender, and first two letters of mother's first name. My initial thought was to hash the unique identifier before storing it, which again is better than nothing but anyone who knows the format of the unique identifier could easily use a rainbow table approach to unmask it. As I understand salting, self-salting would mean the hash was different each time for the same individual, so I'd lose the ability to link surveys done by the same person. And using a single salt would just make the salt the vulnerable piece of data.
Does anyone have any ideas (or well established techniques I'm just ignorant of) for one-way hashing a string which a) is not vulnerable to rainbow tables, but b) produces the same output every time from the same input?