¿Cómo puedo crear un identificador único que no pueda revertirse fácilmente?

Hay una forma sencilla de lograr esto con un hash de 2 pasos.

Tome un identificador personal para alguien SHA256 (Firstname Middname Lastname + Birthday) y calcule esto en el lado del cliente.

Envía este hash a un servidor. Hash con un solo secreto pre-elegido de alta entropía (128 bits) que el programador solo conoce y mantiene en secreto a todos y cada uno de los investigadores. Así que SHA256 (secreto + HashOutPutStep1). Almacene el resultado en su base de datos como una clave para ese participante. El secreto, por supuesto, debe ser el mismo para cualquier estudio individual. Si lo desea, use un identificador único de entero que se asigne al hash generado por SHA256. Eso le daría un número de referencia fácil para que lo utilice un humano.

Esto hace que sea imposible revertir el hash sin conocer el secreto, y los resultados son siempre los mismos con el mismo identificador personal. Creo que esta solución cumple con su requisito ya que los analistas no pueden revertir esta cadena. El secreto debe mantenerse alejado de los analistas, pero este es un asunto trivial.

Lo que puede hacer es proporcionar a los participantes cualquier ID de usuario que sea fácil para ellos (como su dirección de correo electrónico, etc.) Este ID de usuario se almacena en una base de datos protegida a la que los analistas no tienen acceso. Cuando un analista realiza consultas, la aplicación crea ID de usuario aleatorios que se asignan temporalmente a las ID de usuario reales (incluso solo para esa sesión), proporcionando así una "clave" única que puede ser necesaria para las típicas tareas de consulta similares a SQL, pero esa "clave" "está descentralizado de la asignación de ID de usuario real. Una vez que se utiliza la clave aleatoria, se descarga y nunca se asocia con el usuario nuevamente. Esto crea una referencia "doble ciego" que proporcionará cierta protección.

Todavía existe el riesgo de que un analista determinado pueda identificar usuarios debido a problemas de agregación, pero ese riesgo debe evaluarse en función del tipo de datos a los que tienen acceso los analistas.

El truco será el diseño de la aplicación que impide que los analistas accedan a los datos de ID de usuario. Ese es un problema de diseño de nivel de aplicación db en el que un arquitecto puede ayudar.

Aquí sugeriría una lista secreta de partipicantes y una identificación aleatoria.

Me gusta esto: Nombre Namesson ID = 18479 Test Testsson ID = 29472 y así. Esto se mantiene en secreto, y el lado del analista no tiene acceso a la lista.

El problema con un identificador único irreversible, es que todavía tiene que ejecutarlo a través de un algoritmo de computadora. Luego, puede hacer que el usuario escriba su nombre real y fecha de nacimiento, luego verifica si ya existe una entrada. Si existe una entrada, reemplace el nombre real y la fecha de nacimiento del usuario con una entrada existente. Si la entrada no existe, cree una nueva identidad aleatoria y reemplace el nombre real y la fecha de nacimiento del usuario con la entrada recién creada. Si opta por un sistema de identificación "automático", debe asegurarse de que el mismo usuario no pueda volver a enviar la misma aplicación. Esto garantiza que no se puedan realizar las "pruebas" de ID. Si lo hace, si el usuario X envía una solicitud, el usuario X se marca como "agotado" en la base de datos. Cuando se abra la próxima aplicación, simplemente elimine el marcador "agotado" en todos los usuarios. Al usar un sistema "agotado", también debe almacenar todas las aplicaciones para que no se envíen al lado del analista hasta que todos hayan completado la solicitud, O DEBE pasar la aplicación "última fecha de vencimiento". De lo contrario, el analista podría simplemente verificar mediante prueba y error cada vez que se reciba una sola solicitud, y el usuario ya está "gastado".

O, usted emite identificadores aleatorios a los usuarios simplemente. Luego, la lista podría mantenerse en un papel, almacenada en una caja fuerte.

Una tercera solución es usar un algoritmo hash o bcrypt, combinado con una clave secreta o contraseña. La clave secreta o la contraseña solo es conocida por el lado recolector, no por el lado del analista. Esto significa que incluso si el lado del analista tiene una lista completa de partipicantes y una lista de todos los hashes de aplicación, todavía no puede revertirla a través de prueba y error, ya que no conocen la clave secreta o la contraseña.

La clave secreta o la contraseña solo pueden ser conocidas por la aplicación y almacenadas en una caja fuerte.