Buscar en datos hash

Question

Buscar en datos hash

#1 de abacabadabacaba (4 votos)
#2 de Luc (3 votos)

2

Tenemos una solicitud para cifrar los datos personales del cliente (correo electrónico, dirección, etc.) Utilizamos MySQL que no tiene ningún TDE como MS SQL u Oracle. Entonces, junto con el cifrado de datos, debemos preservar la funcionalidad para consultar estos datos directamente (no como LIKE). Entonces algo como seleccione * de la persona donde email='[email protected] '.

La idea aquí es utilizar el hash y asegurarse de que el cifrado no sea redundante por una función de hashing deficiente. Entonces, si usamos bcrypt que tiene incorporado sal aleatoria, debería estar bien. El problema es que con la sal aleatoria no podemos construir el mismo hash nuevamente para poder ejecutar consultas de SQL. Si uso bcrypt ('[email protected]') y devolverá un valor hash diferente, no podré ejecutar select * from person donde hash_email = bcrypt ('[email protected] '). Puedo obtener el mismo valor hash solo si uso la misma sal (y factor de trabajo). Pero tener sal para toda la aplicación no parece ser una gran solución. Entonces, ¿qué se puede hacer al respecto?

Si tener un valor de sal por aplicación no es inteligente, ¿podría ser un tipo de mejora si generamos, por ejemplo, 1000 valores de sal aleatorios y los almacenamos en la base de datos? Si necesitamos un hash de correo electrónico, podemos hacer lo siguiente:

obtenga alguna función de hashing numérico rápido y calcule, digamos, m = num_hash (correo electrónico) mod 1000
ir a la tabla de sal tomar sal donde id = m
hash email con este salt email_hash = bcrypt (salt, correo electrónico) y almacene en la base de datos

Para realizar búsquedas podemos aplicar la misma rutina, obtener email_hash y ejecutar la consulta. Supongo que num_hash (correo electrónico) mod 1000 no dice mucho sobre el correo electrónico en sí. Tener 1000 sales aleatorias es mejor que tener una sola.

Cualquier sugerencia sería bienvenida

hash salt

pregunta MarkT74 20.09.2014 - 21:28

fuente

2 respuestas

Lea otras preguntas en las etiquetas hash salt

¿Por qué mi cliente no debe enviar el nombre de usuario y la contraseña del usuario con cada solicitud? ¿Es más seguro confiar en el software / compañía que ha sido hackeado en el pasado?

score 4 · Answer 1

Desafortunadamente, la protección proporcionada mediante el uso de un sal diferente para cada correo electrónico está diseñada para evitar exactamente el mismo tipo de consultas que necesita. Por lo tanto, si necesita consultas eficientes, debe usar la misma sal para todos los correos electrónicos o no usar la sal en absoluto.

La selección de una sal basada en el hash del correo electrónico no es más segura que usar la misma sal. Para ver eso, necesitas entender contra qué tipo de sales de ataque están diseñadas para protegerte. Supongamos que un atacante tiene n hashes to crack y un diccionario de m correos electrónicos. Si cada correo electrónico está marcado con una sal individual, dicho atacante tendrá que escribir cada correo electrónico en el diccionario con cada sal, lo que requerirá los cálculos de hash de n · m . Sin embargo, si se usa la misma sal, el atacante debe codificar cada correo electrónico solo una vez, por lo que solo se necesitan m cálculos de hash. Si la sal se selecciona de forma determinista en función del correo electrónico, de nuevo solo se necesitan los cálculos de hash de m .

En general, si sus aplicaciones permiten búsquedas rápidas por correo electrónico, el atacante puede ejecutar el procedimiento de búsqueda en todos los correos electrónicos en su diccionario. No importa cómo se implemente el procedimiento de búsqueda, si es rápido, el atacante podría usarlo para revisar rápidamente todos sus correos electrónicos. Por lo tanto, usar las sales correctamente (ya que se usan para el hashing de contraseñas) es incompatible con las búsquedas rápidas.

score 3 · Answer 2

En primer lugar, el cifrado no es hash y el hashing no es cifrado. Hablas sobre el cifrado y luego continúas sobre bcrypt, pero bcrypt está diseñado para el hashing de contraseñas.

Si utilizar hash o cifrado depende de sus necesidades:

Si tiene datos que no necesita saber, pero que necesita verificar más tarde (como una contraseña), debe tener un hash. Si solo usas direcciones de correo electrónico para la identificación, pero nunca se usan ni se muestran, entonces también puedes hacer un hash (aunque me parece extraño). Básicamente, los datos que usted no quiere que nadie conozca y que nadie necesita saber, incluso si tienen acceso a la base de datos.
Si tiene datos que deben mantenerse privados, incluso si alguien roba un disco del servidor, pero debe poder encontrar lo que leyó, debe usar el cifrado del disco en lugar de TDE (como dice, MySQL no tiene TDE). ). No hay necesidad de TDE específicamente.

Inventar tu propia "mala función de hash" es como intentar reescribir ssh en ensamblador porque no leíste su página de manual y no te diste cuenta de que lo que quieres probablemente ya existe.

También tenga en cuenta que bcrypt está hecho para ser lento, literalmente. La consulta de una base de datos que se ha copiado con los parámetros bcrypt adecuados será terriblemente ineficiente. La única forma de evitar esa lentitud es usar parámetros incorrectos, momento en el que es mejor deshacerse de bcrypt por completo.