¿Cuál es la ventaja real de usar un algoritmo "más seguro" como bcrypt para el hashing de contraseñas?

Obtener acceso de solo lectura es un escenario mucho más probable que el acceso de escritura. Después de todo, el acceso de lectura a un servidor de prueba o copia de seguridad antiguo es casi tan bueno como el acceso de lectura al servidor real. (ya que las personas no cambian sus contraseñas con suficiente frecuencia)

Además, una cuenta casi en cualquier lugar (a menos que sea un sitio bancario) no es tan valiosa. Cientos de miles de cuentas, sin embargo, ahora estás hablando. Y si bien una sola escritura de db puede pasar desapercibida, miles de escrituras anómalas de db, especialmente con cada persona en la que se escribió la cuenta ahora no pueden iniciar sesión, generalmente se notarán. Además, al descifrar la contraseña de su usuario se obtiene acceso a todos los lugares en los que el usuario ha utilizado esa combinación de ID / contraseña, lo que probablemente incluya sitios más valiosos que los suyos.

En cuanto a su esquema de almacenamiento de registros, la razón principal para almacenar la salida de su función de hashing de contraseña en un blob que el resto de la base de datos no interpreta (a diferencia de los campos salt y hash ) es que no desea codificar su algoritmo hash en su base de datos. ¿Qué pasaría si mañana quisiera cambiar a PBKDF2, o scrypt, o de hecho bcrypt? Es mejor dejar que una función de hash de contraseña vetada existente realice la interpretación que vincularse con funciones de hash que se ajusten al formato de su método de hash de commodity de sal + actual. En cambio, si solo tiene un campo para algorithm y otro campo que es solo "cadena para pasar al algoritmo junto con una contraseña para ver si la contraseña es buena" (puede llamar a este campo hash o saltNhash ), incluso puede actualizar a los usuarios de forma transparente al iniciar sesión.

Como nota aparte, SHA2 con sal es una seguridad de contraseña aceptable si está estableciendo un servicio web en 1995. Veinte años después, use bcrypt o algo aún mejor . Los hash de productos básicos salados (como MD5 o la familia SHA *) son vulnerables a los ataques basados en GPU económicos, hasta el punto en que las tablas del arco iris ya no son económicamente eficientes: es más económico ejecutar el ataque del diccionario según sea necesario que mantenerlo alrededor de una mesa gigante que es trivialmente derrotada por la salazón de todos modos.

El hash de contraseñas es algo que otras personas ya han elaborado en detalle para usted. No escribirías tu propio cifrado o tu propio algoritmo de compresión de video; no cometa el error de ignorar la buena solución que tiene frente a usted a cambio de años de descubrir casos sutiles de rincones que la gente ya ha diseñado.

Si utiliza una sal aleatoria suficientemente larga y previene un ataque de precálculo (por ejemplo: tablas de arco iris ), no lo hará. protéjase contra un simple ataque de diccionario en la contraseña. Considere el escenario donde un atacante obtiene una copia de la base de datos. Si las contraseñas son solo SHA2 con sal, puede valer la pena su esfuerzo para ir tras un número de contraseñas. Esto podría hacerse calculando los hashes para las 100 contraseñas más comunes para cada sal que se usa en la base de datos. Alternativamente, si una cuenta está dirigida, el atacante puede realizar un ataque profundo en ese hash. El uso de bcrypt aumenta considerablemente el cálculo, el tiempo y el costo monetario de la ejecución de dicho ataque.

Como señala, el almacenamiento seguro de contraseñas no ayuda si el atacante obtiene acceso de escritura a la tabla de contraseñas oa la base de datos en general. Cuando eso ocurre, el atacante puede usar ataques más directos.