¿Puedo confiar en una implementación de hash de seguridad después de probarla con entradas aleatorias contra otra implementación?

7

Digamos que quiero usar un algoritmo de hash de seguridad, como bcrypt, y quiero usar una implementación de bcrypt joven, por ejemplo. llamado libfancybcrypt , en lugar de una implementación bien establecida.

Por supuesto, simplemente puedo generar unos pocos miles o millones de cadenas aleatorias, hacerlas con libfancybcrypt y con la biblioteca antigua y bien establecida, y comparar las funciones al final. Así que supongamos que lo he hecho y la nueva biblioteca en cuestión produce el mismo resultado que el bien establecido para todas las entradas aleatorias.

Mi pregunta tiene dos partes:

  1. Supongamos que se puede confiar en el autor de la biblioteca. Dada mi prueba de entrada aleatoria anterior: qué tan probable es , que el autor accidentalmente introduce un error con el efecto de que hay entradas para las cuales hash equivocado es calculado?

  2. Suponiendo que no se puede confiar en el autor de la biblioteca. Dada mi prueba de entrada aleatoria anterior: ¿qué tan probable es que el autor haya introducido a propósito una puerta trasera de algún tipo?

Relacionado pero aún diferente:

pregunta Lukas Kalbertodt 06.05.2017 - 11:39
fuente

2 respuestas

5
  

Supongamos que se puede confiar en el autor de la biblioteca. Dada mi prueba de entrada aleatoria anterior: ¿qué tan probable es que el autor introduzca accidentalmente un error con el efecto de que hay entradas para las que se calcula un hash incorrecto?

Ser confiable no implica que el autor del software sea un programador competente que conozca todos los riesgos posibles. Esto significa que si confía solo en la confianza, no podrá conocer la probabilidad de introducir un error. Y dado que tal error solo puede ocurrir en casos raros como una condición de carrera o algún desbordamiento de enteros, no hay garantía de que desencadenará el error con sus casos de prueba aleatorios.

  

Suponiendo que no se puede confiar en el autor de la biblioteca. Dada mi prueba de entrada aleatoria anterior: ¿qué tan probable es que el autor haya introducido deliberadamente una puerta trasera de algún tipo?

Si la puerta trasera solo se activa con una entrada específica, nunca lo descubrirás sin inspeccionar a fondo el código. E incluso la inspección de código puede no ser de utilidad, consulte los ejemplos del Concurso de C debajo de la mano . Esto significa que es posible introducir una puerta trasera tan sigilosa. Pero, una vez más, no puede dar una probabilidad específica para esto únicamente en base a la información de que el autor no es de confianza.

  

¿Puedo confiar en una implementación de hash de seguridad después de probarlo ...

Sobre la base de las observaciones anteriores, esta pregunta no puede responderse definitivamente. Aparte de eso, depende mucho de para qué utilice la biblioteca: si es solo para obtener algunas sumas de comprobación con el fin de detectar datos corrompidos accidentalmente, sus pruebas podrían ser suficientes. Si se usa, en cambio, para fines en los que la falla del software podría llevar a la muerte, la filtración de secretos superiores o la infección por malware de infraestructuras críticas que tales pruebas probablemente no sea suficiente, especialmente si no confía en el autor.

    
respondido por el Steffen Ullrich 06.05.2017 - 12:04
fuente
1

Siempre que el hash resultante sea igual al de confianza, se puede confiar en el hash resultante . Inmediatamente esto lleva a las siguientes preguntas:

  1. ¿Se puede confiar en todos los hashes resultantes?

Podría haber errores de implementación, que solo ocurren en situaciones específicas, un ejemplo podría ser el manejo incorrecto de los caracteres /dev/random . Si realiza la prueba con suficiente entrada aleatoria, y los hashes son siempre iguales, esto es muy poco probable. Planear que una contraseña específica resulte en un hash no correcto no ayudará al atacante.

Otro problema específico del hashing de contraseñas es la generación de la sal, podría hacerse con una fuente aleatoria que no sea criptográficamente segura, lo que podría facilitar el craqueo. Esto puede ser revisado fácilmente por ti mismo.

  1. ¿Puede haber efectos secundarios ?

Independientemente de si el hash resultante es correcto, el código puede hacer lo que quiera, esto es principalmente un problema en el escenario de un autor malvado, pero también hay problemas con una implementación descuidada.

Hay ataques fáciles de detectar, por ejemplo, un algoritmo hash nunca debe realizar operaciones de E / S ni acceder a Internet, por supuesto.

Mucho más difícil de detectar es el código que puede ser explotado, tal vez cierta entrada provoque un desbordamiento del búfer a propósito. Entonces, si bien el hash resultante es realmente seguro, un atacante podría hacer un mal uso del proceso para atacar el servidor. Sin embargo, esto no está relacionado con el hash, se aplica a todas las bibliotecas de terceros.

Otro efecto secundario fácilmente supervisado es que si el código se lee desde /dev/urandom en lugar de %code% , podría drenar la fuente aleatoria y bloquear el servidor si se usa excesivamente.

myself Yo mismo prefiero usar una biblioteca no confiable que ofrezca un algoritmo seguro, en lugar de usar un algoritmo no apropiado de una biblioteca confiable. Por supuesto, depende de la importancia de su servicio, y siempre es bueno comprobar la fuente usted mismo (los algoritmos hash no son tanto código).

    
respondido por el martinstoeckli 06.05.2017 - 14:21
fuente

Lea otras preguntas en las etiquetas