Sí, la comparación de cadenas (y/o la búsqueda de índice) puede, en principio, filtrar cuántos bytes iniciales idénticos almacenó el hash de contraseña en la base de datos y el calculado a partir de la contraseña compartida ingresada.
En principio, un atacante podría usar esto para aprender iterativamente un prefijo del hash de la contraseña, byte por byte:primero encuentra un hash que comparte su primer byte con el hash en la base de datos, luego uno que comparte sus primeros dos bytes, etc.
No, es casi seguro que esto no importará.
¿Por qué? Bueno, por varias razones:
-
Un ataque de sincronización puede permitir que el atacante aprenda una parte del hash de la contraseña del usuario. Un esquema de hashing de contraseñas bien diseñado (usando sal y expansión de claves ), sin embargo, debe permanecer seguro (suponiendo, por supuesto, que las contraseñas en sí mismas no sean fáciles de adivinar) incluso si el atacante conoce la totalidad. hash de contraseña. Por lo tanto, incluso si el ataque de sincronización tiene éxito, las contraseñas mismas estarán seguras.
-
Para llevar a cabo el ataque, el atacante debe enviar contraseñas cuyo valor hash conoce. El valor hash depende de la sal. Por lo tanto, a menos que el atacante ya conozca la sal, este ataque no es posible.
(Es cierto que, en la mayoría de los análisis de seguridad de los esquemas de hash de contraseñas, se supone que la sal es información pública. Sin embargo, esto se debe a que dichos análisis asumen el peor escenario mencionado anteriormente, donde el atacante ya ha obtenido una copia de toda la base de datos de usuarios, salts y hashes y todo. Si el atacante aún no conoce el hash, no hay razón para suponer que conocería el salt).
-
Incluso si el atacante conoce la sal, para llevar a cabo el ataque iterativo descrito anteriormente, deberá generar contraseñas que se conviertan en un valor con un prefijo deseado. Para cualquier función hash segura, la única forma práctica de hacerlo es probar un error, lo que significa que el tiempo necesario para hacerlo aumenta exponencialmente con la longitud del prefijo.
Lo que esto significa en la práctica es que, para extraer suficientes bits del hash para poder realizar un ataque de fuerza bruta fuera de línea contra él (que no es necesario que sean todos, solo más que la cantidad efectiva de entropía en el contraseña), el atacante necesita realizar tantos cálculos como sea necesario para descifrar la contraseña. Para un esquema de hash de contraseña bien diseñado y una contraseña elegida de forma segura, esto no es factible.
-
Lo que el ataque iterativo puede darle al atacante, en principio, la capacidad de realizar la mayor parte del cálculo de fuerza bruta localmente en su extremo, mientras solo envía una cantidad bastante pequeña de contraseñas a su sistema. Sin embargo, incluso esto solo es válido si reciben información de tiempo detallada y confiable de parte de cada uno. contraseña enviada. En la práctica, los ataques en tiempo real son extremadamente ineficaces y requieren muchas consultas (a menudo miles o millones) para producir cualquier información útil en absoluto. Es muy probable que esto anule cualquier ventaja de rendimiento potencial que el ataque de sincronización podría proporcionar al atacante.
Este punto se amplifica si utiliza un esquema de hash de contraseña de extensión de clave adecuado, ya que dichos esquemas están diseñados deliberadamente para ser lentos. Por lo tanto, la comparación de cadenas en la base de datos probablemente tomará una cantidad de tiempo insignificante en comparación con el proceso de hash de la contraseña en primer lugar, y cualquier variación de tiempo causada por esto se perderá en el ruido.
