Anonimizzazione dell'identità dell'utente

Question

Anonimizzazione dell'identità dell'utente

#1 da (2 voti)

3

Voglio fare un anonimato per i dati dell'utente nel mio semplice sistema. Ogni utente ha due file, ad esempio <id-number>-1.json e <id-number>-2.json .

Voglio memorizzarli in qualche repository di tutti i file degli utenti (il repository è protetto). Voglio spostare i file su questo repository e rendere anonimo il numero ID utente (senza la possibilità di ricevere l'ID dal nome del file), e voglio rendere i nuovi nomi di file con la funzione hash diversa in modo tale nessuno sarà in grado di capire che questi due file sono collegati a un utente.

Gli obiettivi:

Per poter accedere a entrambi i file tramite l'ID utente.
Gli altri utenti che vedono un solo nome di file non saranno in grado di identificare l'utente proprietario.
Gli altri utenti che vedono entrambi i nomi di file non saranno in grado di sapere di essere di proprietà dello stesso utente.

Ho pensato ad alcune soluzioni per questa situazione:

Primo file: SHA512(<id-number><40-characters-suffix1>) , secondo file: SHA512(<id-number><40-characters-suffix2>)
Primo file: multiple times AES(<constant-long-string>, <id-number-as-key>) , secondo file: multiple times AES(<other-constant-long-string>, <id-number-as-key>)

Quale modo è meglio usare? C'è un altro modo migliore per farlo?

hash anonymity

posta nrofis 07.01.2018 - 12:53

fonte

1 risposta

Leggi altre domande sui tag hash anonymity

Un file .PS PostScript può contenere un virus? Bloccare l'indice dell'array - è una buona idea per la mitigazione di Spectre di Javascript?

score 2 · Accepted Answer

Vado con il primo sistema, non c'è differenza significativa rispetto a quello AES; ma devi comunque considerare altri fattori, possibilmente non correlati.

UPDATE : ripensandoci, potresti usare PKDBF2 come "hash" ", al fine di mitigare le possibilità di una bruteforcing di successo.

Attacco forza bruta

Se i suffissi sono noti o, in generale, esiste un mapping noto tra l'ID utente e l'hash, allora un utente malintenzionato potrebbe semplicemente enumerare tutti gli ID possibili.

Ad esempio, l'utente malintenzionato sa che gli ID iniziano da 1 e sono al massimo 100.000; anche utilizzando un algoritmo CPU e memoria-hard, generare gli hash per tutti possibili ID utente e archiviarli in un database non richiederebbe più di qualche giorno. Usando SHA1 o AES, è questione di minuti, forse anche di secondi. Successivamente, per sapere quale ID si nasconde dietro un determinato hash, è solo questione di cercare l'hash nell'elenco.

Potresti prendere in considerazione la possibilità di sostituire gli ID sequenziali con quelli casuali (il che può essere un problema nelle regioni inferiori e devi gestire il caso in cui una nuova ID casuale collide con un vecchio ID ancora da sostituire). A quel punto i "possibili ID" non sono più centomila (da 1 a 100.000) ma diversi miliardi di miliardi (da 0x00000000000000000000000000000000 a 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF). La bruteforcing impiegherà ora un tempo impossibile e / o un database incredibilmente grande per contenere gli hash.

Le correlazioni

Considerare la possibilità di correlazioni non banali tra file1 e file2. Mentre una correlazione banale sarebbe entrambi i file contenenti un identificatore univoco o, peggio ancora, una copia dell'ID utente, potrebbero esserci informazioni in entrambi i file che potrebbero consentire di determinare l'ID utente o il collegamento tra file accoppiati; ad esempio, un timestamp o un UUID invertibile per alcune risorse.

Questo problema potrebbe estendersi a metadati come mtime, o numero di inode, o posizione nell'elenco delle directory; due file creati nello stesso secondo o memorizzati uno dopo l'altro potrebbero essere tracciati sullo stesso utente, anche se non è possibile eseguire il backcalcolo dell'ID utente.

Dovresti prendere in considerazione l'archiviazione dei file in una struttura a 2 o 3 livelli, ad esempio

/rootdir/ae/02/47/ae0247f19a8b52f.json

e usando un filesystem non aggiornabile ad atime; e / o quando modifichi o crei o elimini un file, touch dell'intero ramo (qui ae, ae / 02, ae / 02/47 e ae / 02/47 / ae0247f19a8b52f.json) a un tempo di trasmissione fisso, tale come mezzanotte del 1 gennaio 1970.

Inizializzazione del repository

Quando trasferisci i file nel repository, potresti voler prima produrre un elenco:

 000001-1.json      aae3799a82b9fb8ccd34c1d5aa6565b2
 000001-2.json      539c50984894084b3e3b1047eee187ae
 ...

Quindi scramble l'elenco. Una volta fatto questo, per ciascuna coppia sulla lista che si sposta, ad es. 000001-2.json a repositoryRoot/53/9c/50/539c50984894084b3e3b1047eee187ae . In questo modo, non ci sarà alcuna correlazione tra gli inode, la posizione del filesystem o la posizione fisica del disco di 000001-1.json e 000001-2.json .

Tieni presente che sulla maggior parte dei file system, questo approccio aumenterà sensibilmente il tempo necessario per eseguire la copia.

Email come ID

Questo non sembra molto promettente in termini di sicurezza, perché le e-mail sono spesso supponibili e / o riciclate. Molto dipenderebbe da cosa è esattamente memorizzato su quei file JSON e quale sia lo scenario di attacco (i due casi di un hacker che accede a un repository di informazioni imbarazzanti e tenta di ricattare i proprietari - quindi per tornare dal JSON all'e-mail e qualcuno che cerca di acquisire le informazioni di una vittima di cui si conosce l'email, deve essere gestito molto in modo diverso).

Una possibilità potrebbe essere avere una tabella di anonimizzazione tenuta fuori dal repository:

ID                   RandomToken
[email protected]     5231b225ea0dbcced14c993523af4986
....                 ....

A quel punto potresti usare token come password "segreta".