Anonimización de identidad de usuario

Question

Anonimización de identidad de usuario

#1 de LSerni (2 votos)

3

Quiero realizar una anonimización de los datos de usuario en mi sistema simple. Cada usuario tiene dos archivos, por ejemplo, <id-number>-1.json y <id-number>-2.json .

Quiero almacenarlos en algún repositorio de todos los archivos de usuarios (el repositorio está protegido). Quiero mover los archivos a este repositorio y anonimizar el número de ID de usuario (sin la opción de recibir la ID por el nombre del archivo), y quiero hacer los nuevos nombres de archivos con la función hash diferente para nadie podrá entender que estos dos archivos están conectados a un usuario.

Los objetivos:

Para poder acceder a ambos archivos por la ID de usuario.
Otras personas que ven un solo nombre de archivo no podrán identificar al usuario propietario.
Otras personas que vean ambos nombres de archivos no podrán saber que son propiedad del mismo usuario.

Pensé en algunas soluciones para esta situación:

Primer archivo: SHA512(<id-number><40-characters-suffix1>) , Segundo archivo: SHA512(<id-number><40-characters-suffix2>)
Primer archivo: multiple times AES(<constant-long-string>, <id-number-as-key>) , Segundo archivo: multiple times AES(<other-constant-long-string>, <id-number-as-key>)

¿Cuál es la mejor manera de usar? ¿Hay otra forma mejor de hacerlo?

hash anonymity

pregunta nrofis 07.01.2018 - 12:53

fuente

1 respuesta

Lea otras preguntas en las etiquetas hash anonymity

Sujeción del índice de matriz: ¿es esta una buena idea para la mitigación de Javascript Specter? ¿Cómo encontrar el origen de algunos html invasivos?

score 2 · Accepted Answer

Iría con el primer sistema, no hay una diferencia significativa con respecto al sistema AES; pero aún debe considerar otros factores, posiblemente no relacionados.

ACTUALIZACIÓN : pensándolo bien, es posible que desee utilizar PKDBF2 como un "hash ", con el fin de mitigar las posibilidades de una fuerza bruta exitosa.

Ataque de fuerza bruta

Si se conocen los sufijos, o en general hay un mapeo conocido entre el ID de usuario y el hash, entonces un atacante podría simplemente enumerar todos los ID posibles.

Por ejemplo, el atacante sabe que las identificaciones comienzan en 1 y tienen como máximo 100,000; incluso utilizando un algoritmo de CPU y memoria, generar los hashes para todos los posibles ID de usuario y almacenarlos en una base de datos no llevaría más de unos pocos días. Usando SHA1 o AES, es cuestión de minutos, tal vez incluso segundos. Luego, para saber qué ID se esconde detrás de un hash determinado, es solo cuestión de buscar ese hash en la lista.

Es posible que desee considerar la sustitución de las ID secuenciales por las aleatorias (lo que puede ser una molestia en las regiones inferiores; y debe controlar el caso en el que un newId aleatorio colisiona con un oldId que aún no se ha reemplazado). En ese punto, las "ID posibles" ya no son cien mil (de 1 a 100,000) sino varios miles de millones de billones (de 0x000000000000000000000000000000 a 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF). Bruteforcing ahora llevará una cantidad de tiempo imposible, y / o una base de datos increíblemente grande para mantener los hashes.

Correlaciones

Considere la posibilidad de correlaciones no triviales entre archivo1 y archivo2. Si bien una correlación trivial sería que ambos archivos contengan un identificador único o, lo que es peor, una copia del ID de usuario, podría haber información en ambos archivos que podría permitir determinar el ID de usuario o el enlace entre archivos emparejados; por ejemplo, una marca de tiempo o un UUID invertible para algún recurso.

Este problema puede extenderse a metadatos como mtime, o número de inodo, o posición en la lista del directorio; dos archivos creados en el mismo segundo, o almacenados uno después del otro, se pueden rastrear al mismo usuario, incluso si uno no puede volver a calcular el ID de usuario.

Debería considerar archivar los archivos en una estructura de 2 o 3 profundidades, es decir,

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

y usando un sistema de archivos que no sea de actualización de atime; y / o cuando cambia, crea o elimina un archivo, touch la rama completa (aquí ae, ae / 02, ae / 02/47 y ae / 02/47 / ae0247f19a8b52f.json) a una fecha fija, como como la medianoche del 1 de enero de 1970.

Inicializando el repositorio

Al transferir los archivos al repositorio, es posible que desee generar primero una lista:

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

Luego, codifica la lista. Una vez hecho esto, para cada par en la lista se mueve, por ejemplo. 000001-2.json a repositoryRoot/53/9c/50/539c50984894084b3e3b1047eee187ae . De esta manera, no habrá correlación entre los inodos, la posición del sistema de archivos o la posición física del disco de 000001-1.json y 000001-2.json .

Tenga en cuenta que en la mayoría de los sistemas de archivos, este enfoque aumentará de manera apreciable el tiempo requerido para hacer la copia.

Correos electrónicos como ID

Esto no parece ser muy prometedor para la seguridad, ya que los correos electrónicos a menudo son adivinables y / o reciclados. Mucho dependerá de qué se almacena exactamente en esos archivos JSON y cuál es el escenario de ataque en realidad es (los dos casos en que un pirata informático obtiene acceso a un repositorio de información vergonzosa e intentan chantajear a los propietarios, por lo que requieren para volver a trabajar desde el JSON hasta el correo electrónico, y alguien que intente adquirir la información de una víctima cuyo correo electrónico sea conocido, debe ser manejado muy de manera diferente).

Una posibilidad podría ser tener una tabla de anonimización fuera del repositorio:

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

En ese momento, puedes usar token como la contraseña "secreta".