Asegurar hashes de valores cortos enumerados

  

La sal debe ser común para todos los registros.

Esto se conoce como "pimienta", no una sal.

  

el atacante podría iterar fácilmente todos los valores posibles

Si el espacio de búsqueda es lo suficientemente pequeño como para que se pueda forzar con una fuerza bruta, incluso con un hash de alto costo como bcrypt , entonces estás confiando por completo en el secreto de la "pimienta" para evitar la fuerza bruta. En este caso, también puede utilizar un HMAC con una clave secreta. El uso de un HSM para almacenar una clave aleatoria y manejar el HMAC es lo mejor que puede obtener.

Solo ten en cuenta que debido a que necesitas la capacidad de buscar el hash, los mismos datos siempre tendrán el mismo valor de hash. Como la respuesta de Kevin entra en más detalles, los valores de hash duplicados pueden correlacionarse con otros datos para filtrar información.

Si bien sería ideal que los hashes fueran irreversibles, eso simplemente no es posible con un espacio de mensaje pequeño. Lo mejor que puede hacer es asegurarse de que solo se pueda usar el HSM para revertir los hashes. Esto ayudará a evitar las fugas de datos, pero aún así debe asegurarse de que la capa de aplicación no se pueda forzar con la fuerza bruta.

[Este es más un comentario largo que una respuesta]

Ha etiquetado la pregunta encriptación , pero estamos hablando de sales y hashes. Como señala, las funciones hash no son adecuadas para proteger un pequeño espacio de mensajes (ejemplo típico: los mensajes son "Sí" o "No"), por lo que debe ajustar todas estas sales y pimientos y las claves HMAC.

Sin embargo, el cifrado adecuado, específicamente los cifrados en bloque, están diseñados para ser seguros incluso en un espacio de mensaje "Sí / No". ¿Hay alguna razón por la que no pueda usar el cifrado AES real? (para obtener puntos de bonificación, almacene la clave de descifrado AES en el HSM).

Voy a tomar la respuesta corta: no puedes hacer lo que quieres. En realidad no.

Desea almacenar una serie de valores fáciles de adivinar en la base de datos, encriptados, para que nadie que rompa su base de datos pueda saber qué son ... pero desea poder buscar en la base de datos ese término. Lo que significa que cada "etiqueta" confidencial debe cifrarse con el mismo valor exacto.

De acuerdo, ¿qué tal un ejemplo?

Name     MedicalStatus
----------------------
Kevin    Dying
Bob      Alive
Charlie  Dying
Diana    Alive
Elaine   Alive
.... followed by 10k more rows of 'Alive' or 'Dying'

... cuánto más seguro es tener:

Name     MedicalStatus
----------------------
Kevin    dk3jnnd832jj3fd
Bob      cx32d89dh32gf1x
Charlie  dk3jnnd832jj3fd
Diana    cx32d89dh32gf1x
Elaine   cx32d89dh32gf1x
... followed by 10k more rows of either 'dk3....' or 'cx32d...'

Ni siquiera tiene que "descifrar" los valores. Solo tiene que adivinar uno; después de todo, dijo que eran fáciles de adivinar, y eliminó todas las demás entradas coincidentes de la tabla. No importa lo exagerado que esté tratando de ocultar esos valores y la seguridad de las tecnologías que utiliza, va a ser bastante obvio desde el punto de vista del atacante lo que está sucediendo.

(Heck, si son como yo, lo verán como un rompecabezas divertido; obligatorio enlace ) O, si son perezosos, solo crearán algunos registros en la base de datos utilizando la capa de la aplicación para ver cómo se almacenaron sus valores.

Dicho esto ... ¿qué puedes hacer?

Opción A : elimine el requisito de consulta rápida. Puede usar sal real (no pimienta) y hacer que las entradas estén seguras utilizando un algoritmo de cifrado reversible. Pero la desventaja es, como se dio cuenta, que las búsquedas tendrían que descifrar cada entrada durante una búsqueda.

Opción B : seguridad por oscuridad. Sí, sabes que esta opción va a ser fea (la seguridad de la oscuridad generalmente lo es). Pero puedes crear un campo, y llamar es un Hash, pero simplemente XORAR sus datos sobre la columna sensible para codificarlos. Al realizar búsquedas, ya no busca el campo en sí, sino el combo XOR. Significaría que ya no podría realizar búsquedas de índice (tendría que conformarse con las exploraciones de índice) y no es exactamente una configuración sólida ... pero al menos es mejor que tener todas las mismas entradas con los mismos valores.

Opción C : haga que solo se puedan buscar los hashes para la persona que realiza la búsqueda. Aka, hash las entradas usando una clave que es única para cada persona. Por supuesto, esto significa que no puede haber ninguna búsqueda global ; pero al menos permitiría a un usuario encontrar sus registros que coincidan.

Opción D : repensar y rediseñar. En serio, sus requisitos realmente no se ajustan aquí, y tengo la sensación de que va a terminar haciendo un sistema que no es seguro en absoluto. Su objetivo aquí no es "Hacer un sistema que cumpla con los requisitos X e Y de la forma más segura posible". Su objetivo es "Crear un sistema seguro que intente cumplir los requisitos X e Y". Si no puede lograr los objetivos de forma segura, no debe hacerlo en absoluto.

Creo que sin complicar su vida con el manejo de pimienta / sal / otros mecanismos de hash y como ha indicado que va a implementar HSM, es mejor usar el cifrado adecuado para asegurar sus valores enumerados.

HSM es un módulo de hardware de computación criptográfica con un almacén de claves protegido que funciona en un protocolo de interfaz bien definido y difícil de comprometer.

Las posibles claves simétricas / asimétricas que podría usar son:

• Symetric: AES, 3DES, Blowfish, etc.
• Asymetric: RSA, DSA, Diffie-Hellman, etc.

HSM podría ayudarlo de muchas maneras, incluso genera claves, transporte de claves, protege el almacenamiento de claves, maneja claves, proporciona funciones de respaldo / recuperación de claves, etc.