No soy un experto en seguridad y no pretendo serlo, por eso lo pregunto aquí. Escribo muchas aplicaciones basadas en PHP y hasta ahora he estado usando bcrypt para cifrar mis contraseñas.
El sitio web de Scrypt afirma ser 4000 veces más lento que bcrypt, ¿puede realmente ser correcto este reclamo? Si es así, ¿sería "mejor" que un desarrollador consciente de la seguridad cambie para usar scrypt en lugar de bcrypt?
Se supone que Scrypt es "mejor" que bcrypt, pero también es mucho más reciente, y eso es malo (porque "más reciente" implica inherentemente que "ha recibido menos escrutinio").
Todos estos esquemas de hash de contraseñas intentan hacer que el procesamiento de una sola contraseña sea más costoso para el atacante , mientras que no es demasiado costoso para su servidor . Como su servidor es, básicamente, una PC, y el atacante puede elegir el hardware más eficiente para su tarea, los esquemas de hashing de contraseñas intentan ser tales que la mejor plataforma para ellos será una PC. PBKDF2 se puede optimizar completamente con GPU, mientras que bcrypt y scrypt son mucho menos compatibles con GPU. Tanto Bcrypt como Scrypt requieren RAM rápida , que es un recurso escaso en una GPU (una GPU puede tener una gran cantidad de RAM, pero no podrá acceder a ella desde todos los núcleos simultáneamente).
Da la casualidad de que FPGA integra muchos bloques de RAM pequeños que son muy útiles para optimizar un ataque de diccionario paralelo con bcrypt: esto significa que un atacante obtendrá un gran impulso al utilizar FPGA por un valor de 1000 $ en lugar de un PC genérico por un valor de 1000 $. Este es el tipo de impulso que queremos evitar. Por lo tanto, scrypt, que requiere mucha más memoria RAM; no es demasiado para una PC (solo estamos hablando de un par de megabytes), pero lo suficiente como para hacer la vida más difícil para una FPGA (consulte esta respuesta para un tratamiento detallado de la pregunta).
Por lo tanto, teóricamente , scrypt debería ser mejor que bcrypt. Sin embargo , todo esto está sujeto a si Scrypt cumple con sus promesas criptográficas. Este tipo de garantía de robustez solo se puede lograr a través del tiempo: el esquema se considerará seguro si sobrevive a los incansables ataques de los criptógrafos. El tiempo necesario es, por supuesto, un poco subjetivo, y también depende mucho de la exposición (cuanto más extendido es un esquema, más "interesante" es un objetivo en el que se rompe. aumentaría la fama académica del perpetrador, lo que atraería un mayor escrutinio). Mi propia regla de oro es esperar unos 5 años después de la publicación, por lo que 2014 en el caso de Scrypt.
También está la cuestión de disponibilidad : si desea utilizar una función, necesita una implementación que pueda insertarse en el marco de programación que utiliza.
Tomaría la afirmación "Scrypt es 4000 veces más lento que BCrypt" con un grano de sal. Primero, ambos algoritmos son de complejidad variable; incluso si esa cifra "4000x" se mantiene, puede hacer que BCrypt sea tan lento al agregar 11 rondas adicionales a la derivación clave. En segundo lugar, en algún momento tanto SCrypt como BCrypt están limitados por el tiempo que demora en calcular legítimamente un hash en la computadora del usuario promedio (o en su servidor si lo está haciendo en el servidor para una aplicación web). El hecho de que SCrypt sea 4000x más lento puede aumentar la tasa de rebote de su sitio web en más del aumento de la seguridad.
Razones para elegir BCrypt:
BCrypt tiene 14 años, se basa en un cifrado que tiene más de 20 años, y ninguno de los dos ha demostrado tener una debilidad teórica viable (existe una vulnerabilidad de texto simple en Blowfish que no afecta a BCrypt en lo más mínimo, pero hay un error en una implementación de UNIX de BCrypt que podría causar fallas en la aplicación si se alimentaran ciertos códigos de caracteres).
SCrypt solo tiene 3-4 años, por lo que no tiene el pedigrí criptoanalítico necesario para ganarse la confianza de la mayoría de los criptógrafos. Eso no significa que sea vulnerable; significa que los expertos en seguridad de mopst no tienen la confianza suficiente de que no es vulnerable todavía .
Realmente solo hay una razón para elegir SCrypt sobre BCrypt y es la razón por la que se diseñó SCrypt: la principal debilidad de BCrypt contra un sistema de craqueo distribuido es el uso bajo y constante de la memoria. Esto hace que BCrypt sea vulnerable a la fuerza bruta rentable al usar arreglos de puertas programables en campo o FPGA relativamente económicos. Estas matrices tienen una cantidad relativamente pequeña de SRAM incorporada en sus bloques lógicos, que aún es suficiente para mantener los datos de estado de BCrypt. Como dijo Thomas, estas matrices son más baratas de comprar y configurar que una red distribuida de crackbots basados en GPU o CPU tradicionales, de manera equivalente, su atacante obtiene más por su dinero.
SCrypt, por contraste, usa no solo el tiempo exponencial, sino también la memoria exponencial; a medida que aumenta el número de rondas de derivación, SCrypt requiere el almacenamiento de una serie de "instantáneas" de datos de estado intermedio, que se utilizan en operaciones de derivación adicionales. Eso no es un problema para la computadora de un usuario legítimo que genera un hash (probablemente esté usando unos pocos MB como máximo), pero la memoria limitada de un bloque FPGA rápidamente se vuelve insuficiente. Ahora, cualquier cosa que pueda almacenar, puede calcular "a pedido" en su lugar, pero debido a que cada uno de estos estados intermedios es el resultado de su propia serie de operaciones exponencialmente complejas (cada una de las cuales es de menor complejidad que el hash final, pero debe calcularse más veces para el uso a pedido), el atacante ahora está en las bocinas de un dilema; o bien necesitan más FPGA exponencialmente para mantenerse al día con el aumento del tiempo de cómputo del modelo a pedido, o necesitan actualizar los FPGA a algo con memoria suficiente para hacer el trabajo (básicamente, está considerando un CPU / FSB simple de gran capacidad) / Las arquitecturas RAM en este punto, que es lo que está detrás de los clústeres distribuidos petaflop multimillonarios). De cualquier manera, los FPGA ya no son tan factibles como lo son para BCrypt (o PBKDF2).
Con scrypt además de aumentar el cálculo, puede aumentar la cantidad de memoria necesaria para calcular el hash. Esto no molesta mucho a las implementaciones de software, pero es mucho más difícil de implementar con hardware, que es lo que un atacante dedicado probablemente desarrolle y use. bcrypt (y PBKDF2) utilizan cantidades de memoria constantes y pequeñas.
- Orip
Por enlace