Come posso creare un identificatore univoco che non può essere facilmente invertito?

C'è un modo semplice per farlo con un hash in 2 passaggi.

Prendi un identificativo personale per qualcuno SHA256 (Nome Middname Cognome + Compleanno) e calcola questo dal lato del cliente.

Invia questo hash a un server. Metti questo con un singolo segreto prescelto di alta entropia (128 bit) noto solo al programmatore e tenuto segreto da tutti i ricercatori. Quindi SHA256 (segreto + HashOutPutStep1). Memorizza l'output nel tuo database come chiave per quel partecipante. Il segreto deve ovviamente essere lo stesso per ogni singolo studio. Se lo desideri, utilizza un identificatore univoco intero che si associa all'hash generato da SHA256. Questo ti darebbe un numero di riferimento facile da utilizzare per un essere umano.

Ciò rende impossibile invertire l'hash senza conoscere il segreto, ei risultati sono sempre gli stessi con lo stesso identificatore personale. Credo che questa soluzione soddisfi le tue esigenze poiché gli analisti non possono invertire questa stringa. Il segreto deve essere tenuto lontano dagli analisti, ma questa è una questione banale.

Quello che puoi fare è fornire ai partecipanti qualsiasi ID utente che sia facile per loro (come il loro indirizzo email, ecc.) Questo ID utente è memorizzato in un database protetto a cui gli analisti non hanno accesso. Quando un analista esegue query, l'applicazione crea userID casuali che vengono mappati temporaneamente agli userID reali (anche solo per quella sessione), fornendo in tal modo una "chiave" unica che potrebbe essere richiesta per le tipiche attività di query di tipo SQL, ma quella "chiave" "è decentralizzato dalla vera mappatura userID. Una volta usata la chiave casuale, questa viene scaricata e non viene mai più associata all'utente. Questo crea un riferimento "double-blind" che fornirà una certa protezione.

C'è ancora il rischio che un determinato analista possa essere in grado di individuare gli utenti a causa di problemi di aggregazione, ma che il rischio deve essere valutato in base al tipo di dati a cui gli analisti hanno accesso.

Il trucco sarà la progettazione dell'applicazione che impedisce agli analisti di accedere ai dati userID. Questo è un problema di progettazione di livello db-application a cui un architetto può dare una mano.

Suggerirei qui un elenco segreto-conservato di partipicanti e un ID casuale.

In questo modo: Nome Namesson ID = 18479 Test Testsson ID = 29472 e così via. Questo è tenuto segreto, e il lato analista non ha accesso alla lista.

Il problema con un identificatore univoco irreversibile è che devi ancora eseguirlo tramite un algoritmo del computer. Quindi è possibile che l'utente digiti il proprio nome e data di nascita, quindi verifica se esiste già una voce. Se la voce esiste, sostituire il nome reale dell'utente e la data di nascita con la voce esistente. Se la voce non esiste, creare una nuova identità casuale e sostituire il nome reale dell'utente e la data di nascita con la voce appena creata. Se si utilizza un sistema ID "automatico", è necessario assicurarsi che lo stesso utente non possa inviare di nuovo la stessa domanda. Ciò garantisce che non sia possibile eseguire il "test" degli ID, se si applica in tal modo se l'utente X invia un'applicazione, l'utente X viene contrassegnato come "speso" nel database. Quando si apre la prossima applicazione, è sufficiente rimuovere il marcatore "esaurito" su tutti gli utenti. Utilizzando un sistema "esaurito", è necessario anche eseguire il buffering di tutte le applicazioni in modo che non vengano inviate al lato analista fino a quando nessuno ha completato l'applicazione, OPPURE viene passata l'applicazione "data di scadenza". Altrimenti, il lato analista potrebbe semplicemente verificare per tentativi ed errori ogni volta che viene ricevuta una singola applicazione, che l'utente è ora "speso".

Oppure, si rilasciano identificatori casuali agli utenti semplicemente. Quindi l'elenco potrebbe essere tenuto su carta, conservato in una cassastrong.

Una terza soluzione consiste nell'utilizzare un hash algorithm o bcrypt, combinato con una chiave segreta o una password. La chiave segreta o la password sono conosciute solo dal lato del collezionismo, non dal lato dell'analista. Ciò significa che anche se il lato analista ha un elenco completo di partipicant e un elenco di tutti gli hash dell'applicazione, non è ancora possibile annullarlo tramite tentativi ed errori poiché non conoscono la chiave segreta o la password.

La chiave segreta o la password possono quindi essere conosciute solo dall'applicazione e archiviate in una cassastrong.