He visto preguntas similares en el sitio, pero no esta exacta.
El más cercano fue Modificar las contraseñas antes de almacenar donde la respuesta aceptada se resume en indicando que la transformación de la contraseña se desperdicia en ciclos de CPU que, de lo contrario, podrían pasar por una mayor iteración en su hash real.
Si bien eso es correcto, considere el siguiente escenario:
Digamos que su aplicación usa un host para el código de la aplicación y otro host para la base de datos / almacenamiento. Es posible que, en algún momento en el futuro, su base de datos se vea comprometida, pero el código de su aplicación permanezca en secreto.
Si eso sucede, el atacante puede intentar revelar las contraseñas de los usuarios con una mezcla de fuerza bruta o listas de palabras con expresiones regulares, algo que probablemente descubra al menos algunas contraseñas, y más a medida que pase el tiempo.
Obviamente, si descubriera que su base de datos se ha comprometido, restablecería todas las contraseñas de los usuarios. Pero en el momento en que el Delta se ha comprometido realmente, y al descubrirlo, el atacante tiene un potencial vector de ataque para acceder a las cuentas vulnerables de ciertos usuarios.
¿Entonces pensé, específicamente para este escenario, que simplemente no agregaría algunos datos basura a las contraseñas de los usuarios antes de que el hashing hiciera este ataque mucho más débil? (es decir, dificulta que un atacante revele las contraseñas a tiempo antes de que descubras qué sucedió y las restableciste)
No estoy hablando de transformaciones generales, sino específicamente de agregar porque: 1. garantiza que todas las contraseñas permanezcan únicas después de la modificación, por lo que no pierden la entropía. 2. es una tarea de cálculo de costo relativamente bajo en el proceso de un servidor que acepta formularios de registro y respuestas de formato. 3. es simple, y no agrega complejidad de código que haría que la aplicación sea más difícil de mantener en el futuro.
La cadena a agregar sería una cadena constante, almacenada en un lugar en el código de la aplicación. Obviamente, si el código de la aplicación se ve comprometido, todo esto no tiene sentido. Pero si solo se comprometieron los hashes de contraseña de usuario:
- ¿Sería esto efectivo para frenar a un atacante? (es decir, demorar más en revelar las contraseñas de los usuarios utilizando métodos modernos)
Y, en general:
- ¿Esto introduciría alguna nueva vulnerabilidad en el sistema?
Ejemplo:
El servidor de aplicaciones tiene una cadena constante: "! @ # $% ^ & () ,;"
User A se registra con la contraseña "secretpassword"
El servidor concat los dos, creando: "! @ # $% ^ & (),; secretpassword"
Luego, codifica la nueva cadena y almacena el hash resultante en la base de datos.
Para cada intento de inicio de sesión futuro, la cadena constante se agregaría al comienzo de la contraseña del usuario (en el servidor) antes de volver a calcular el hash.
Ahora digamos que tengo un millón de usuarios, y un atacante consiguió un millón de hashes de contraseña que mi aplicación usa para autenticar a los usuarios. El atacante también sabe que estoy agregando una cadena constante al comienzo de las contraseñas de usuario en el servidor, de hecho lo estoy declarando públicamente en mi GUI de registro. Sin embargo, el atacante no conoce la cadena real que estoy adjuntando.
la cuenta de User A sería más segura (es decir, le tomaría más tiempo al atacante revelar su contraseña secreta escrita "secreta" o encontrar una manera de ingresar a su cuenta y tomar posesión de sus datos) o sería ¿lo mismo?
¿algún otro User X se volvería menos seguro ahora debido a este cambio, o ningún otro usuario se vería afectado para peor?