¿Qué nos impide comenzar a utilizar scrypt en producción?

6

Después de leer mucho la opinión de los expertos sobre el hash de contraseñas, entiendo que scrypt (que es tanto de memoria como de uso intensivo de la CPU) es un buen candidato para el hashing de contraseñas. Pero vi a los expertos recomendar una espera de al menos 5 años hasta que sea revisado por pares y horneado (¿problema de huevo y gallina? :))

  • En 2015, ¿podemos dar el paso y comenzar a usar scrypt con confianza?
  • ¿Existe un plan para convertir esto en un estándar / recomendación de NIST y otros organismos estándar?

ref 1

ref 2

    
pregunta acthota 19.11.2014 - 03:16
fuente

1 respuesta

13

Si queremos buscar razones racionales no para usar scrypt en este momento, podemos encontrar principalmente estos tres:

  • No está claro si una función de "memoria dura" es lo que se necesita, con las configuraciones de parámetros admitidas por scrypt. Scrypt se diseñó inicialmente para admitir el cifrado local, especialmente el cifrado de todo el sistema. Esto significa que la contraseña debe tener un hash durante el proceso de arranque del sistema; en ese momento, la computadora no tiene nada más que hacer, por lo que toda la CPU y la RAM están disponibles para un solo scrypt; y como el arranque ya lleva una cantidad de tiempo no despreciable, un hashing de contraseña que se extiende por 5 o 10 segundos no es una dificultad.

    Un servidor típico necesitará una configuración distinta, que use menos RAM (un servidor no puede permitirse un gigabyte por hashing de contraseña, si tiene que atender a varios clientes y no se desmorona bajo carga máxima) y menos CPU (una autenticación de sitio web debería se realizará en menos de 1 segundo, porque los usuarios no son pacientes y, nuevamente, debemos tener en cuenta la carga máxima). Aún queda por ver si scrypt es mejor que bcrypt cuando está configurado para el "uso del servidor"; de hecho, si necesita reducir el uso de la CPU a aproximadamente 1 ms por hash, scrypt utiliza menos RAM que bcrypt, lo que hace de esta última una opción superior.

  • En lo que respecta a la dureza de la memoria, scrypt resultó no ser tan óptimo como podría ser. Algunas optimizaciones basadas en GPU todavía son factibles con compensaciones de memoria de tiempo. La ganancia del atacante no es devastadora, pero si vamos a cambiar nuestra función de hash de contraseña, también podemos intentar encontrar una que cumpla sus promesas.

Tales problemas, y otra información, se pueden encontrar en esta presentación . Para resumir: si bien las ideas expresadas en el diseño de Scrypt son bastante interesantes, el sentimiento general de los criptógrafos es que debería haber más investigación; y, de hecho, impulsó el PHC : una competencia abierta, en el espíritu de esfuerzos pasados como AES, SHA-3 o eSTREAM, donde se proponen y revisan nuevos candidatos.

Si implementa scrypt ahora mismo en producción, entonces debería ser razonablemente sólido, aunque depende de los parámetros que elija. Esa es la conclusión principal de 5 años de investigación: la criptografía es sólida, hay un intercambio de memoria temporal que no es perjudicial, pero no tenemos mucha orientación sobre cómo configurarlo de manera que funcione bien en servidores típicos.

    
respondido por el Thomas Pornin 19.11.2014 - 20:03
fuente

Lea otras preguntas en las etiquetas