Hash / Digest of string; Los clientes múltiples y la búsqueda inversa deben ser imposibles.

¿No puede conocer la identificación pero DEBE identificarlo de manera única? Entonces, ¿por qué no configurar otro sistema para proporcionar una identidad segura (par de claves de publicación) para una ID determinada? Ese sistema será el DB de búsqueda en caso de manipulación, pero también el punto débil en la privacidad de su sistema. Si no necesita ese mecanismo de recuperación, simplemente no cree ese DB de búsqueda en primer lugar ...

O, si realmente no te importa qué cliente usa tu servicio, pero solo porque es ALGUNO cliente válido, observa la autenticación anónima usando pruebas de conocimiento cero. Una solución simple también podría ser usar firmas ciegas al revés: el servidor distribuye firmas válidas al cliente durante la inscripción y el cliente las asigna al azar antes de la autenticación. En ese enfoque, el cliente puede crear nuevos alias aleatorizando una firma que le dio, pero siempre puede asegurarse de que la firma sea la que generó en algún momento.

Algunas implementaciones de criptografía de clave pública suenan como el camino a seguir. Cada cliente tiene acceso a "su" clave pública (cifrado), mientras que solo usted tiene acceso a la clave privada correspondiente (descifrado). Cifre a la clave pública, y (suponiendo que la longitud de la clave sea adecuada y no haya errores en la implementación) solo utilizando la clave privada se puede descifrar la cadena. No hay terceros involucrados, y se requiere muy poca coordinación.

Puede cifrar un hash o (probablemente más práctico en este caso, a menos que las cadenas sean largas, lo que no parece ser el caso) de toda la cadena.

Si esto es para una API pública, puede publicar su clave pública junto con las especificaciones de la API. Nuevamente, mientras use claves suficientemente largas y la implementación en sí sea sólida, el riesgo de seguridad de exponer su clave pública será insignificante.

enlace es probablemente un buen lugar para comenzar a aprender sobre todo esto.

Enunciado del problema. Esta es mi comprensión del problema que desea resolver. Cada cliente tiene un ID de cliente de 10 dígitos, que es sensible a la privacidad y que no desea que se almacene o transmita al servidor, pero desea poder identificar de forma única al cliente. Lo tengo.

Solución # 1. Aquí hay una solución bastante simple. Genere un identificador oculto mediante la aplicación iterativa del identificador de cliente de 10 dígitos varias veces, por ejemplo, un millón de veces. El número de veces que hash iterativamente es un parámetro que puede elegir. Le sugiero que elija el parámetro para que todo el proceso de hashing iterativo demore aproximadamente un segundo. Estamos tratando de hacer más costoso recuperar el ID de cliente original de 10 dígitos del identificador encubierto.

Cuando inscribe a un nuevo cliente, genera su identificador encubierto y almacena el identificador encubierto en la base de datos de la aplicación del servidor. Cuando un cliente instala una aplicación de cliente, la aplicación de cliente obtiene acceso al ID de cliente de 10 dígitos y repetidamente efectúa un millón de veces para crear el identificador encubierto. Este proceso tarda aproximadamente un segundo, pero la aplicación cliente nunca necesita volver a hacerlo: puede almacenar el identificador oculto permanentemente.

Cuando la aplicación cliente quiera hablar con su aplicación de servidor, debe conectarse a su aplicación de servidor a través de SSL / TLS y transmitir el identificador oculto a través de la conexión SSL / TLS. El servidor puede verificar la validez del identificador encubierto y usarlo para identificar al cliente. La aplicación del servidor debe usar un certificado SSL / TLS estándar, y la aplicación cliente debe verificar este certificado.

Análisis de seguridad de la solución # 1. La solución # 1 es un poco más segura que almacenar los identificadores de cliente de 10 dígitos en el servidor, aunque comprenda que no es perfecto. Digamos que tiene N clientes y, por lo tanto, N identificadores ocultos almacenados en el servidor. Un atacante que roba una copia de la base de datos del servidor puede recuperar todas las ID de clientes originales al crear una asignación entre números de 10 dígitos y sus hashes de un millón de veces. Le llevará al atacante 10 ¹⁰ × 1,000,000 = 10 ¹⁶ 2 ⁵³ operaciones hash para construir el mapeo completo. Este cálculo es factible, pero no trivial: no es algo que pueda hacer durante el fin de semana en su máquina doméstica (es más como cientos de años de CPU-computación, por lo que se puede lograr con un grupo grande, y probablemente se pueda alcanzar para miles o decenas de miles de dólares, pero no muy fácil). Una vez que el atacante construye el mapeo, puede recuperar fácilmente todas las ID de N clientes.

Esto podría ser lo suficientemente bueno para sus propósitos. Si no lo es, aquí hay una pequeña mejora:

Solución # 2. No almacene el identificador encubierto en el servidor; en su lugar, almacene un hash salado del identificador encubierto. El identificador encubierto se define como antes. Pero ahora, cuando inscribe a un nuevo cliente, genera el identificador encubierto, genera una sal aleatoria para el cliente y almacena (sal, Hash (sal, cloakedid)) en el servidor. No almacena una copia del identificador encubierto. Cuando el usuario instala una aplicación cliente, la aplicación cliente obtiene el ID de cliente de 10 dígitos, calcula el identificador encubierto y envía al servidor una solicitud especial que dice "Soy nuevo; aquí está mi identificador encubierto. ¿Podría enviarme mi sal?" ? " a través de una conexión SSL / TLS al servidor. El servidor toma el identificador encubierto I del cliente, y para cada par (salt, h) en su base de datos, verifica si Hash (salt, I) = h. Si es así, entonces ha encontrado la entrada coincidente para ese cliente y envía la sal del cliente nuevamente a la aplicación cliente. (El servidor no retiene el identificador encubierto). La aplicación cliente ahora almacena la sal y el valor Hash (sal, cloakedid). Cuando la aplicación cliente se conecta al servidor en el futuro, en lugar de enviar el identificador oculto, envía el valor Hash (salt, cloakedid). Esto es suficiente para identificar al cliente.

Análisis de seguridad de la solución # 2. Esto es más seguro que la solución # 1. Un atacante que obtiene una copia de la base de datos del servidor tiene que hacer 10 ¹⁶ operaciones hash por cada ID de cliente que desea recuperar . Para recuperar todos los N ID de clientes, un atacante tiene que hacer 10 ¹⁶ x N operaciones hash; compare con la solución # 1, donde solo se necesitan 10 operaciones de hash ¹⁶ .

Por otro lado, la solución # 2 es más complicada y, por lo tanto, puede ser más difícil de implementar y de implementar. Además, el servidor tiene que trabajar un poco más cada vez que un nuevo cliente instala una nueva aplicación de cliente (el servidor tiene que hacer N operaciones de hash cada vez que un cliente instala una nueva aplicación de cliente).

OK, se requiere un poco de conjetura aquí, asignando sus objetivos a lo que puede hacer crypto.

Objetivo: que una aplicación cliente no confiable demuestre que tiene una cadena válida.

Probablemente no sea posible sin la "cadena secreta" cargada en el servidor, o una clave incrustada en la cadena. Efectivamente, la cadena se convierte en una "clave pública", y el lado del servidor usa la "clave privada" para descifrar cualquier mensaje enviado.

Objetivo: hacer que una aplicación cliente que no sea de confianza proporcione una cadena que pueda determinarse como distinta de otras aplicaciones que te hablan.

Más fácil de hacer siempre que haya suficiente aleatoriedad en la cadena de clave, solo use un algoritmo de hashing de contraseña seguro con muchas repeticiones (consulte las bibliotecas).

Por lo tanto, la aplicación cliente tendrá que hacer mucho trabajo para codificar la cadena, de modo que usted, como administrador del servidor, no pueda forzar bruscamente todas las cadenas de entrada posibles.

Objetivo: aumentar la seguridad del lado del servidor al no requerir las "cadenas secretas" como parte de la infraestructura del servidor.

Puede usar la función anterior con el hash de contraseña y, cuando sea necesario, las investigaciones pueden hacer coincidir la cadena secreta con el hash sin conexión para los pocos casos que lo necesitan.

Objetivo: ¿Necesita que las compañías separadas a continuación sean validadas para su uso en sus sistemas?

  

El otro giro es que cada aplicación cliente es mantenida por una   compañía, por lo que cualquier método clave (o de salado) obvio para mí lo haría   necesita un tercero para coordinar las claves / valores de sal sin ellos   alguna vez volviendo a mí.

La seguridad https estándar (más generalmente llamada SSL o TLS) se puede configurar para resolver este problema. Cada una de las compañías crea sus propios certificados, se los envía a usted para que los firme y luego los devuelve. Entonces, tanto su servidor https como el software de su cliente están configurados para requerir solo los certificados firmados. Tenga en cuenta que esto conserva los secretos bien porque las claves privadas de todos los sistemas involucrados nunca deben ser reveladas a otras partes (esta es la clave de la magia en el sistema).