Premise: I'm asked to develop a system that will trace sensitive data. The data are gathered by an intermediate operator (let's call him IO) on an office terminal. The final user (EU) will show up to the office, identify itself via an ID document, the operator will acquire the information and send it to the system. On request, given the not anonymous ID, the IO be able to consult the history of all the information acquired for that ID.
Objective: store the data on a centralized server in a completely anonymous way using an anonymous ID as an alias of the real ID. I want to make hard even for the technical operators of the server to retrieve the original ID.
My solution since now: as a first step toward the solution I thought of generating a salt hash starting from the password inserted by the IO, and use this salt for hashing the not anonymous ID, then send to the server the hashed ID instead of the real ID (there is the possibility of a hash collision, but, in my scenario it is an acceptable risk).
The problem is that every time the IO will change the password, he will lose access to the history of all the ID inserted (the same, not anonymous ID, will be translated as x before password change and as y after).
An improvement should be that the system will generate a salt on the IO machine at first login attempt, crypt it using the IO password and store it on the server. The salt will be retrieved at every future access, decrypted on the IO machine and used to generate the ID. If the user will change his password it will send, during the normal change password procedure also the hash encrypted with the new password. If the user forgot the password, the procedure to generate a new one will be started and IO will lose access to the history (this is acceptable given the sensitive nature of this data, it will be IO responsibility to store his password in the safest way possible).
At the moment I see a flawless on this procedure, on server side, every time a new encrypted hash will be sent to the server, technical operator will have access to a sequence of encrypted hash, they know this is the same number encrypted with different passwords, this will be a useful information tha will help to crack the salt. How can I protect against this? There are others weaknesses?
But there is more: the perfect solution will allow 2 or more IO to gather data for the same, not anonymous ID, and store it on the server with the same anonymous ID not allowing server operator to retrieve the original ID.
There is a way to achieve this result?
PS: as observed in one of the answers one of the challenges of this project is that not anonymous ID are very limited (in the order of billions) and can be easily enumerated.