Entiende el código de forma correcta antes de adaptarlo a tu trabajo si ttienes algo que aportar puedes decirlo en los comentarios.
Solución:
Bcrypt tiene el mejor tipo de reputación que se puede lograr para un algoritmo criptográfico: ha existido durante bastante tiempo, se ha utilizado ampliamente, “atrajo la atención” y, sin embargo, permanece intacto hasta la fecha.
Por que bcrypt es algo mejor que PBKDF2
Si observa la situación en detalle, puede ver algunos puntos en los que bcrypt es mejor que, digamos, PBKDF2. Bcrypt es una función de hash de contraseñas que tiene como objetivo ser lenta. Para ser precisos, queremos que la función de hash de contraseña sea lo más lenta posible para el atacante sin ser intolerablemente lento para los sistemas honestos. Dado que los “sistemas honestos” tienden a utilizar hardware genérico estándar (es decir, “una PC”) que también está disponible para el atacante, lo mejor que podemos esperar es hacer hash de contraseñas norte tiempos más lentos tanto para el atacante como para nosotros. Luego ajustamos norte para no sobrepasar nuestros recursos (siendo el principal la paciencia del usuario, que es realmente limitada).
Lo que queremos evitar es que un atacante pueda usar algún hardware que no sea de PC, lo que le permitiría sufrir menos que nosotros por el trabajo adicional que implican bcrypt o PBKDF2. En particular, un atacante trabajador puede querer usar una GPU o una FPGA. SHA-256, por ejemplo, se puede implementar de manera muy eficiente en una GPU, ya que usa solo operaciones lógicas y aritméticas de 32 bits en las que la GPU es muy buena. Por lo tanto, un atacante con 500 $ en GPU podrá “probar” muchas más contraseñas por hora de las que podría hacer con 500 $ en PC (la proporción depende del tipo de GPU, pero una proporción de 10x o 20x ser típico).
Bcrypt depende en gran medida de los accesos a una tabla que se modifica constantemente durante la ejecución del algoritmo. Esto es muy rápido en una PC, mucho menos en una GPU, donde la memoria se comparte y todos los núcleos compiten por el control del bus de memoria interna. Por lo tanto, el impulso que puede obtener un atacante al usar GPU es bastante reducido, en comparación con lo que obtiene el atacante con PBKDF2 o diseños similares.
Los diseñadores de bcrypt eran muy conscientes del problema, por lo que diseñaron bcrypt a partir del cifrado de bloque Blowfish y no una función SHA- *. Señalan en su artículo lo siguiente:
Eso significa que uno debe hacer que cualquier contraseña funcione lo más eficiente posible para el entorno en el que operará. Los diseñadores de la cripta no pudieron hacer esto. Ellos basaron crypt en DES, un algoritmo particularmente ineficiente para implementar en software debido a muchas transposiciones de bits. Descontaron los ataques de hardware, en parte porque la cripta no se puede calcular con el hardware DES de stock. Desafortunadamente, Biham luego descubrió una técnica de software conocida como bitslicing que elimina el costo de las transposiciones de bits en el cálculo de muchas encriptaciones DES simultáneas. Si bien el corte de bits no ayudará a nadie a iniciar sesión más rápido, ofrece una aceleración asombrosa para las búsquedas de contraseña por fuerza bruta.
que muestra que el hardware y la forma en que se puede utilizar es importante. Incluso con la misma PC que el sistema honesto, un atacante puede usar bitslicing para probar varias contraseñas en paralelo y obtener un impulso, porque el atacante tiene varias contraseñas para probar, mientras que el sistema honesto solo tiene una a la vez.
Por qué bcrypt no es óptimamente seguro
Los autores de bcrypt estaban trabajando en 1999. En ese momento, la amenaza era un ASIC personalizado con recuentos de puertas muy bajos. Los tiempos han cambiado; ahora, el atacante sofisticado utilizará grandes FPGA, y los modelos más nuevos (por ejemplo, el Virtex de Xilinx) tienen bloques de RAM integrados, lo que les permite implementar Blowfish y bcrypt de manera muy eficiente. Bcrypt necesita solo 4 kB de RAM rápida. Si bien bcrypt hace un trabajo decente al dificultar la vida de un atacante con GPU mejorado, hace poco contra un atacante con FPGA.
Esto llevó a Colin Percival a inventar scrypt en 2009; esta es una función similar a bcrypt que requiere mucha más RAM. Este es todavía un nuevo diseño (solo dos años) y en ninguna parte está tan extendido como bcrypt; Lo considero demasiado nuevo para recomendarlo de forma general. Pero su carrera debe seguirse.
(Editar: scrypt resultó no estar a la altura de sus promesas. Básicamente, es bueno para lo que fue diseñado para hacer, es decir, proteger el cifrado key para el disco duro principal de una computadora: este es un contexto de uso donde el hash puede usar cientos de megabytes de RAM y varios segundos de CPU. Para un servidor ocupado que autentica las solicitudes entrantes, el presupuesto de la CPU es mucho menor, porque el servidor necesita poder atender varias solicitudes simultáneas a la vez, y no ralentizarse a un ritmo lento bajo cargas pico ocasionales; pero cuando scrypt usa menos CPU, también usa menos RAM, esto es parte de cómo la función se define internamente. Cuando el cálculo del hash debe completarse en unos pocos milisegundos de trabajo, la cantidad de RAM utilizada es tan baja que scrypt se vuelve, técnicamente, más débil que bcrypt).
Lo que recomienda el NIST
NIST ha publicado la publicación especial SP 800-132 sobre el tema del almacenamiento de contraseñas con hash. Básicamente recomiendan PBKDF2. Esto no significa que consideren a bcrypt inseguro; no dicen nada sobre bcrypt. Solo significa que NIST considera que PBKDF2 es “lo suficientemente seguro” (y ciertamente es ¡mucho mejor que un simple hash!). Además, NIST es una organización administrativa, por lo que seguramente les encantará cualquier cosa que se base en algoritmos ya “aprobados” como SHA-256. Por otro lado, bcrypt proviene de Blowfish, que nunca ha recibido ningún tipo de bendición (o maldición) del NIST.
Aunque recomiendo bcrypt, sigo el NIST en el sentido de que si implementa PBKDF2 y lo usa correctamente (con un recuento de iteraciones “alto”), es muy probable que el almacenamiento de contraseñas ya no sea el peor de sus problemas de seguridad.
bcrypt tiene una ventaja significativa sobre un simplemente hash SHA-256 salado: bcrypt usa un key algoritmo de configuración que es bastante caro a tiempo. Se llama key fortalecimiento, y hace que una contraseña sea más segura contra ataques de fuerza bruta, ya que el atacante ahora necesita mucho más tiempo para probar cada posible key.
En la publicación del blog titulada “Suficiente con las tablas del arco iris: lo que necesita saber sobre los esquemas de contraseñas seguras”, que personalmente le recomiendo leer, Thomas Ptacek, el autor e investigador de seguridad, recomienda el uso de bcrypt.
Personalmente, he estado mirando PBKDF2 últimamente, que es un key función de derivación que aplica una función pseudoaleatoria (por ejemplo, hash criptográfico) a la contraseña de entrada junto con una sal, y luego deriva una key repitiendo el proceso tantas veces como se especifique. Aunque es un key función de derivación, utiliza el principio de key fortalecimiento en su esencia, que es una de las muchas cosas por las que debe esforzarse al decidir cómo generar de forma segura un hash de una contraseña.
Para citar a Thomas Ptacek de la publicación vinculada anterior:
La velocidad es exactamente lo que no desea en una función de hash de contraseña.
Creo que la sugerencia de Gui sobre PBKDF2 tiene mérito, aunque sé que Rook no está de acuerdo. ¡Si tan solo tuvieran claro su razonamiento!
Independientemente, no hay razón para usar un hash SHA-256 salado en comparación con HMAC-SHA256. HMAC tiene la ventaja de bloquear los ataques de extensión.
Si conservas alguna cuestión o forma de reaccionar nuestro escrito te insinuamos añadir una aclaración y con placer lo interpretaremos.