¿Cómo sabe un pirata informático cuántas veces se ingresó una contraseña?

El número de rondas a menudo se almacena con la contraseña y el hash. Por ejemplo, usando bcrypt:

$2a$10$oEuthjiY8HJp/NaBCJg.bu76Nt4eY4jG/S3sChJhZjqsCvhRXGztm

El 10 indica el factor de trabajo, agregando efectivamente 10 bits de entropía en términos de tiempo de hashing a fuerza bruta. 2^10 = 1024 rounds .

Se almacena con el hash en caso de que sea necesario aumentar el factor de trabajo debido a la ley de Moore .

Si su sistema tenía un factor de trabajo secreto que es el mismo para todas las cuentas, esto podría usarse como una medida de seguridad adicional, como un pimiento. De hecho, en el caso de que un atacante pueda establecer su propia contraseña y ver el hash, deberá combinarla con un pimiento, de lo contrario, podría determinar la cantidad de iteraciones en juego al ver el hash resultante. Sin embargo, esto es más complejo para esto en el futuro que cuando se almacena con cada contraseña, ya que tendrá que almacenar un indicador de la versión de configuración de iteración que se usó para cada contraseña. Sin embargo, podría tener un factor de trabajo secreto que se agrega al valor almacenado con el hash.

Veracrypt ha agregado recientemente una función PIM (Personal Iteration Multiplier) que se puede usar como un secreto adicional para proteger sus datos cifrados.

¿Cómo sabe un pirata informático cuántas veces se hasheado una contraseña? De la misma manera que tú.

El objetivo del hash de una contraseña es hacer que sea imposible (en la práctica es muy difícil) determinar la contraseña, incluso con acceso completo a todos los datos .

El otro requisito para el hashing es que el servidor debe poder determinar si una contraseña ingresada es correcta. Esto significa que en algún momento durante el proceso de inicio de sesión, el servidor debe tener acceso a la fórmula completa para el hashing de una contraseña.

El propósito de variar el número de hashes es principalmente reducir los ataques de fuerza bruta y aumentar el espacio de búsqueda de las tablas de arco iris, y esto funciona sin ningún tipo de secreto . Es por eso que la cantidad de rondas normalmente se almacena directamente en la base de datos con el hash, como en la respuesta de SilverlightFox.

Hay soluciones que almacenan el número de rondas por separado e intentan mantenerlo en secreto, y pueden agregar una capa adicional de protección. Pero al evaluar el sistema de hash, debemos asumir que el atacante sabe todo lo que sabemos .

Después de todo, si hubiera un lugar para almacenar la cantidad de rondas garantizada para no comprometerse, podríamos almacenar las contraseñas allí y no molestarnos en nada con el hashing.

El número de iteraciones y el salt se almacenan en la misma base de datos, generalmente en el mismo campo que el hash de contraseña. Debido a que el sitio necesita saber esas cosas tanto como un posible atacante, tienen que estar fácilmente disponibles. Por ejemplo, bcrypt las contraseñas con hash contienen la (base de registros 2 de) el número de iteraciones separadas por $ signos del resto de el hash.

Si bien la respuesta actualmente aceptada es correcta y el número de iteraciones generalmente se almacena donde se encuentran los hashes, incluso si este no fuera el caso:

1. Por principio de Kerckhoff , debe asumir que el atacante puede descubrirlo. En la práctica, podrían descubrirlo, por ejemplo, creando su propio inicio de sesión con una contraseña conocida o cronometrando un intento de inicio de sesión.

2. Aunque el número de iteraciones fuera desconocido, solo agregaría un factor constante al tiempo requerido por el atacante para verificarlas todas, al menos con funciones comunes de hashing de contraseñas como PBKDF2 , donde puede obtener el hash de 1000 iteraciones del hash de 999 iteraciones con una sola iteración. El atacante solo tendría que comparar los valores intermedios con el hash de la contraseña.