Hoy veremos cómo almacenar las contraseñas en una base de datos y cómo las plataformas conocidas resuelven este problema.
Texto sin formato
Cuando surgió la cuestión de almacenar contraseñas, por supuesto, la primera idea fue simplemente escribirlas abiertas en la placa de identificación apropiada en la base de datos. Y todo estaría bien si los clientes realmente no pudieran acceder a él directamente. Pero, desafortunadamente, una inyección SQL tan conocida a veces todavía funciona en varias aplicaciones web, sin mencionar otras vulnerabilidades potenciales. En materia de seguridad, generalmente se acepta asumir lo peor y preparar un plan de acción y protección incluso en tal caso. Suponemos que un atacante ha encontrado una laguna en una aplicación web, de una forma u otra descarga felizmente una tabla con nombres de usuario y contraseñas y luego los desecha a su antojo. En general, sus acciones adicionales pueden ser las siguientes:
- realizar acciones ilegítimas en nombre de los usuarios que usan sus credenciales en un recurso vulnerable: por ejemplo, una tarjeta bancaria está vinculada a una cuenta y ahora un atacante puede usarla;
- un intento de usar la contraseña recibida en otros recursos: lejos de siempre, los usuarios, siguiendo el consejo, siempre crean nuevas contraseñas para diferentes servicios;
- un intento de identificar la regla para generar una contraseña y pasar al segundo punto: algunos forman una regla para generar una contraseña, como resultado, las contraseñas en diferentes recursos son diferentes, pero obedecen la misma regla que se puede detectar;
- escalada de privilegios: la contraseña del administrador también se puede almacenar en la misma tabla, con el conocimiento de que a veces puede obtener el control total sobre el servidor.
Hash de cifrado
La idea inmediatamente resulta no ser tan buena. Que hacer Sería genial almacenar las contraseñas en forma cifrada. Entonces, incluso si se eliminan, no podrán recuperarse, o al menos pasarán demasiado tiempo en ello. Aquí la elección surge entre dos ramas de desarrollo: cifrar contraseñas o hash. Los desarrolladores se decidieron por el segundo y, en principio, está claro por qué. Compare nuestros solicitantes para diferentes características:
- Aporte laboral. El cifrado lleva más tiempo, y no importa qué conversión elijamos, tendrá que hacerse con cada verificación de contraseña. Uno de los requisitos para las funciones hash es la velocidad de ejecución.
- La longitud de los valores de salida. El resultado del cifrado es de longitud variable, el resultado del hash es siempre el mismo y es muy conveniente almacenar datos uniformes en una base de datos. Sin mencionar el hecho de que la longitud de la contraseña en forma cifrada proporcionará información sobre la longitud de la contraseña original. La misma longitud, sin embargo, conduce a la posibilidad de colisiones, pero más sobre eso a continuación.
- Gestión de claves. El cifrado requiere una clave, que también deberá almacenarse en algún lugar y esperar que nadie la encuentre. En cualquier caso, la generación y gestión de claves es una historia separada (no deben ser débiles, deben cambiarse regularmente, etc.).
- La posibilidad de conflicto. Al cifrar, la salida de diferentes datos de entrada siempre será diferente también. Con el hash, este no es siempre el caso. Una longitud hash constante significa que el conjunto de valores de salida de la función hash es limitado, lo que conduce a la posibilidad de colisión. Es decir, digamos que el usuario realmente se confundió y se le ocurrió una contraseña larga realmente genial, que tiene caracteres especiales, números y letras en minúsculas y mayúsculas. El atacante ingresa la contraseña no menos interesante "admin" en el campo de contraseña. El servidor lo ha procesado para verificar y comparar hashes. Hashes emparejados. Es una pena
Por lo tanto, con una puntuación de 3: 1, gana el hashing. ¿Pero es posible detenerse allí?
La respuesta es no.
Ataques de contraseña hash
Entonces, el atacante obtuvo nuestra tabla con nombres de usuario y contraseñas. Las contraseñas ahora están cifradas, pero esto no detiene a nuestro atacante, y él realmente intenta recuperarlas. Sus posibles acciones:
- fuerza bruta del diccionario: si el atacante no tuvo éxito con la contraseña de referencia del administrador, recurrirá al diccionario de contraseñas populares y probará suerte con sus hashes;
- tablas de arcoíris: en general hoy, tal vez no necesitará calcular nada y ordenar el diccionario. Será suficiente recurrir a las mesas arcoiris que se encuentran en la red. Las tablas de arco iris contienen valores hash ya calculados por alguien antes y sus datos de entrada correspondientes. Es importante tener en cuenta que, debido a colisiones, la contraseña que ofrecerá la tabla de arco iris no será necesariamente la que utilice el usuario. Los valores calculados ya son para MD5, SHA1, SHA256, SHA512, así como para sus modificaciones y algunos otros. Puede intentar revertir el hash, por ejemplo, aquí ;
- búsqueda exhaustiva: si esto no ayuda, tendrá que recurrir a la fuerza bruta e iterar sobre todas las contraseñas posibles en una fila hasta que los hashes calculados finalmente coincidan.
En el caso más general, un atacante tendrá que descifrar contraseñas. Y aquí su éxito dependerá, entre otras cosas, de la velocidad de cálculo de la función hash. Una comparación del tiempo de los hashes se puede encontrar
aquí . Por ejemplo, las funciones hash implementadas en Java en Windows 10 de 64 bits con 1 núcleo Intel i7 2.60GHz y 16GB RAM se ejecutaron un millón de veces para calcular un hash de 36 caracteres. Mostraron los siguientes resultados:
MD5 - 627 ms
SHA-1 - 604 ms
SHA-256 - 739 ms
SHA-512 - 1056 ms
Pero hoy la fuerza bruta se puede paralelizar y ejecutar muchas veces más rápido en la GPU (así como en la APU, DSP y FPGA). Sin embargo, además de elegir un algoritmo más largo y una salida más larga, puede hacer otra cosa.
Hash hash
Para evitar que un atacante use tablas de arco iris ya hechas, existe una técnica para descifrar una contraseña varias veces. Es decir, calculamos el hash del hash del hash del hash ... y así n veces (es necesario, sin embargo, no involucrarse demasiado con esto, porque el servidor también tendrá que hacer esto durante la verificación regular de la contraseña del usuario). Ahora, según la tabla del arco iris, es tan simple que no encontrará la contraseña, y el tiempo para la fuerza bruta aumentará significativamente. Pero nada detendrá al atacante de generar una tabla de arcoíris a partir del diccionario de contraseñas, conociendo el algoritmo de hash. Además, para las combinaciones más populares de este método, tales tablas ya se han generado:
"
Agregue sal al gusto
Para que no pueda hacer esto, las contraseñas se descifran hoy con la adición de sal.
Una sal es una cadena aleatoria adicional que se asigna a una contraseña y se combina con ella. No puede recuperar la contraseña del hash así obtenido de la tabla del arco iris. Conociendo la sal y el hash de salida, el atacante está condenado a la fuerza bruta y es muy probable que ninguna tabla calculada previamente lo ayude.
Contraseña de taxonomía de sal:
1. Según el principio de la salazón:
- una sal única para cada usuario: individual para cada usuario; de esta manera, si la sal se da a conocer al atacante, cada contraseña deberá ser eliminada. Y además, incluso si dos usuarios piensan de la misma manera y crean contraseñas idénticas, los hash seguirán siendo diferentes en la salida;
- sal global: la misma para todos, utilizada para todos los hashes;
- tanto eso como otro.
2. Según el método de almacenamiento de sal:
- en la base de datos: como regla, las sales individuales se almacenan en la misma base de datos como hashes de contraseñas; a menudo incluso en la misma línea;
- en el código (léase: en la configuración): la sal global generalmente se almacena no en la base de datos, sino, por ejemplo, en la configuración, de modo que el infractor tendría que pasar tiempo en su selección.
Suponemos que las sales de usuario individuales se almacenan en la base de datos, la sal global en la configuración. El atacante obtuvo acceso a la base de datos, y conoce todos los hashes y sus sales correspondientes (la sal global no se almacena en la base de datos, y él no lo sabe). En total, si se combinan todos los métodos, para obtener contraseñas en forma clara, como fue el caso en los primeros sistemas, él, siendo extremadamente decidido, encontrará los siguientes obstáculos:
- Él no conoce la sal global, por lo que tendrá que ser brutalizada.
- Él conoce las sales de los usuarios, pero no tiene tablas preparadas con estas sales, por lo que tendrá que descifrar contraseñas.
- Este proceso llevará aún más tiempo debido al hecho de que tienes que hacer hash hash n veces.
¿Cómo almacenan las contraseñas varios CMS?
Wordpress
Antes de la versión 3.x, las contraseñas simplemente se cifraron con MD5. Ahora se usa la biblioteca phpass. De manera predeterminada, salt se asigna a la contraseña en frente y la cadena resultante se codifica MD5 2 ^ 8 veces.
Joomla
Antes de la versión 1.0.12, solo se usaba MD5. Se utiliza la biblioteca phpass, por defecto bcrypt con sal y 2 ^ 10 repeticiones.
Drupal
Hasta la versión 6 md5 sin sal. Se utiliza la biblioteca phpass. El valor predeterminado es salado sha512 con 2 ^ 16 repeticiones.
Raya plateada
Utiliza Blowfish salado con 2 ^ 10 repeticiones.
Umbraco
Utiliza HMACSHA256 con sal. Utiliza la segunda sal global especificada en la configuración.