¿Se pueden utilizar hashes deliberadamente de baja entropía para evitar ataques de diccionario?

3

Considere un sistema que recibe, pero no almacena, información confidencial X de un usuario. Si quisiera agregar una forma de recordar cuándo un usuario ha enviado la misma X más de una vez, ¿cuál sería la forma más segura de hacerlo? X no se utiliza para ningún otro propósito; no es una contraseña.

El enfoque obvio pero inseguro sería almacenar todas las presentaciones de X y verificar si hay duplicados. Una forma de hacer esto más seguro sería computar un verificador (bcrypt o similar) de las presentaciones. Si se genera correctamente, tengo entendido que esto anularía los ataques precocinados con tablas de arco iris.

Mi preocupación es con los ataques de diccionario. Si X es relativamente fácil de adivinar, un atacante determinado probablemente puede hacer un progreso lento pero constante contra el verificador. Una solución para esto es truncar deliberadamente el verificador para aumentar el número de posibles plaintexts que coincida. Debido a que X no es una contraseña, debería estar bien aumentar el número de falsos positivos (se detectó un duplicado cuando no hay ninguna). Pero en el lado del atacante, pueden encontrar que es fácil encontrar un texto plano que coincida, pero hay tantos de ellos que es imposible saber cuál es el original.

En otras palabras, si la entropía del verificador es significativamente menor que la entropía de texto sin formato, el conjunto de todos los textos que coincidan con un verificador dado debería ser mucho mayor que si las entropías fueran de un tamaño comparable. Entonces es imposible saber qué texto en claro es el original.

¿Es este un enfoque válido? ¿O es excesivo si el verificador se calcula utilizando un algoritmo lento como bcrypt?

    
pregunta Alex Quach 11.08.2016 - 20:28
fuente

2 respuestas

1

Has dicho que permites que "X" tenga falsos positivos. Por lo tanto, simplemente puede eliminar mucha entropía y permitir falsos positivos, pero el atacante se enfrentaría al mismo problema si obtuviera su base de datos.

Pero si '' X '' tiene suficiente entropía propia (128 bits o 256 bits), el atacante no podrá obtener más información del hash (por ejemplo, utilizando SHA-256 o SHA-3 ), y no tendrías falsos positivos. Hash solo permitiría exactamente esta información, es información nueva que obtuve igual a esta.

Si su '' X '' no tiene suficiente entropía y / o usted acepta el riesgo de tener falsos positivos, también puede reducir su hash (entonces se convierte en cuántos falsos positivos acepta tener) .

Por otra parte, al usar bcrypt y otros PKDF, encuentro que rápidamente se bloqueará la información. Suponiendo que la información '' a '' llegara a usted, no tenía más remedio que iterar sobre cada hash bcrypt almacenado y verificar si es '' a '', lo cual (dado que los PKDF son lentos) sería ineficaz de verificar.

Además, recuerde que el punto débil del sistema que solo pasa cierta información confidencial es un atacante activo, entonces simplemente puede almacenar cada "X" que recibió su servicio desde que fue pirateado.

    
respondido por el axapaxa 11.10.2016 - 02:34
fuente
0

Parece depender de los posibles valores de X.

Por ejemplo, si X puede tomar valor en un rango de 1 000 000 posibilidades, podría calcular un md5 de X y solo almacenar los primeros 16 bytes y mantener un bajo nivel de riesgo de colisión. La paradoja del cumpleaños muestra que la probabilidad de colisión es ((1000000 * 1000000) / pow (16.0,16.0)) * 100 0.0000054%

Si un atacante desea encontrar antecedentes de md5, tiene que elegir entre al menos 18 446 744 073 709 551 616 candidatos equiprobable sin posibilidad de saber si su intento es el bueno (que está cerca de ser inútil). Así que esta parte está bien.

Pero tiene que determinar qué tasa de colisión es aceptable para X. 0.0000054% no es muy alto (no se dice) pero cuando ocurre, ¿es un problema pequeño o grande? Si no puede manejar falsos positivos sobre los valores de X, los algoritmos hash no se deben usar, truncar o no.

Pero, considerando lo que describiste, tu enfoque parece lo suficientemente fuerte. Realmente no necesita un algoritmo de hash criptográfico, SHA podría ser suficiente para su propósito.

    
respondido por el Sibwara 12.08.2016 - 00:45
fuente

Lea otras preguntas en las etiquetas