¿Cómo almacenar una contraseña en la base de datos?

La mayoría de las aplicaciones web requieren que sus usuarios se autentiquen solicitándoles el nombre de usuario y la contraseña. Comparan las credenciales proporcionadas por el usuario con los datos almacenados en su base de datos y, si las credenciales coinciden, se otorga acceso al usuario. ¡Suena bien! Pero, ¿qué sucederá si la base de datos en la que el sitio web almacena sus contraseñas se ve comprometida?
Este artículo cubre varias técnicas de almacenamiento de contraseñas en la base de datos.

De acuerdo con la seguridad desnuda , ¡el 55% de los usuarios de la red usan la misma contraseña para la mayoría de los sitios web! Implica que si el sitio web que almacena su contraseña en texto sin formato se ve comprometido, el pirata informático no solo puede obtener acceso a su cuenta en ese sitio web, sino también a todas sus cuentas de redes sociales, correo electrónico, foros, etc. en las que está utilizando la misma contraseña.

Bueno, muchos deben preguntarse si la base de datos está expuesta al hacker, ¿qué se puede hacer? El hacker tiene acceso a toda la información. ¡¡EQUIVOCADO!! Hay muchas formas en las que el proceso de recuperación de contraseñas de la base de datos puede volverse engorroso para el hacker. Incluso entonces, los desarrolladores tienden a ignorar las pautas básicas y almacenan las contraseñas en texto sin formato. Hay más del 30% de sitios web que almacenan sus contraseñas en texto sin formato (incluidos algunos sitios de renombre también). Si el sitio web almacena su contraseña en texto sin formato, no importa qué tan fuerte elija la contraseña, ¡no está seguro!

Almacenar contraseñas de texto sin formato en la base de datos es un pecado.

También se podría pensar que, si no es texto sin formato, debemos cifrar la contraseña y luego almacenarla. También es una idea terrible. Las funciones de cifrado proporcionan un mapeo uno a uno entre la entrada y la salida y siempre son reversibles. Si el hacker obtiene la clave, podrá descifrar las contraseñas. La mejor manera sería usar una función hash criptográfica de una vía. La función hash proporciona una asignación de muchos uno entre la entrada y la salida y es prácticamente imposible revertir una salida. Una buena función hash criptográfica tiene un número menor de colisiones (es decir, para diferentes valores de entrada a la función, es difícil obtener el mismo resultado). Las colisiones no se pueden evitar por completo debido al principio del casillero. Para contraseñas hash podemos suponer que la función hash generará una salida única, es decir, para dos contraseñas diferentes no obtendremos el mismo valor hash.

Algunas de las funciones hash criptográficas populares son MD5 y SHA1. En lugar de almacenar una contraseña de texto sin formato en la base de datos, una forma es almacenar el hash de la contraseña. Podría estar pensando que si no podemos recuperar la contraseña real del hash, ¿cómo vamos a verificar las credenciales que ingresó el usuario? Es simple, aplique la misma función hash en la contraseña que ingresó el usuario y luego compárela con el hash almacenado en la base de datos. Si ambos hashes coinciden, el usuario está autenticado (ya que el hash de la misma entrada dará la misma salida). Ahora, si el atacante puede obtener acceso a la base de datos, solo podrá ver la salida codificada y no la contraseña real.

Usar la función hash criptográfica es mejor que almacenar contraseñas de texto sin formato .

Los piratas informáticos son tipos inteligentes y una vez que se dieron cuenta de que los desarrolladores están almacenando contraseñas codificadas, calcularon previamente el hash de una gran cantidad de palabras (de una lista de palabras populares o palabras de diccionario). Crearon una tabla de palabras y sus hashes correspondientes. Esta mesa se conoce como Rainbow Table y está disponible en línea. Pueden usar esta tabla para realizar una búsqueda inversa de la contraseña real comparando los hash obtenidos de la base de datos. Por lo tanto, es muy importante tener una contraseña segura ya que la posibilidad de que su contraseña aparezca en la lista de palabras se vuelve menor.

Simplemente almacenar el hash de una contraseña ya no ayudará. La potencia de procesamiento ha aumentado drásticamente con la introducción de GPU y CUDA, bibliotecas OpenCL. Una GPU rápida puede generar millones de hashes MD5/SHA1 en un segundo. Por lo tanto, un pirata informático puede generar fácilmente una gran cantidad de hashes mediante la fuerza bruta de varias combinaciones posibles y puede compararlos con los hashes almacenados en la base de datos para extraer la contraseña real.

¡Incluso las contraseñas cifradas no son seguras! ¿Sorprendido?

¡No pierdas la esperanza! Todavía hay algo que los desarrolladores pueden hacer para mantener sus contraseñas alejadas de las miradas indiscretas de los piratas informáticos. ¡Haz que las contraseñas sean deliciosas añadiéndoles un poco de sal! Sí claro..! Añadir una sal . Un salt son datos aleatorios que se concatenan con su contraseña antes de enviarlos como entrada de la función hash.

Por ejemplo :
si su contraseña es abc y la sal es !ZaP0#8 , el resultado de hashFunction(‘abc!ZaP0#8’) se almacenará en la base de datos en lugar de hashFunction(‘abc’) .
Por lo tanto, los ataques de la tabla del arco iris no serán efectivos ahora, ya que la probabilidad de que la tabla del arco iris contenga un hash de‘abc!ZaP0#8’ es escaso (porque generalmente las tablas de arco iris se construyen a partir de palabras comunes, palabras de diccionario, etc.). Salt no se almacena en la base de datos y solo está presente en el archivo de configuración de la aplicación, que no es accesible para el mundo exterior. Obtener acceso a los archivos de origen es más difícil que obtener acceso a la base de datos.

El método de salado anterior es estático. Tenemos una sal fija para todas las contraseñas. Para autenticar al usuario, primero concatene la sal fija a la entrada proporcionada por el usuario (contraseña) y luego pase el valor a la función hash y compárelo con el valor almacenado en la base de datos. Sin embargo, este enfoque sigue siendo vulnerable a la fuerza bruta y, si el atacante puede obtener la sal estática, puede utilizar la metodología de ataque antigua concatenando la sal en cada palabra.

Un mejor enfoque sería usar una sal dinámica. Para cada usuario, se genera un nuevo salt mediante un generador de strings aleatorias criptográficamente fuerte. La contraseña ingresada por el usuario se concatena con un salt generado aleatoriamente, así como con un salt estático. La string concatenada se pasa como entrada de la función hash. El resultado obtenido se almacena en la base de datos. Se requiere sal dinámica para almacenarse en la base de datos, ya que es diferente para diferentes usuarios. Cuando se va a autenticar al usuario, primero se obtiene de la base de datos el valor de salt dinámico para ese usuario, se concatena con la entrada proporcionada por el usuario y el salt estático. El resultado se compara con el hash almacenado en la base de datos.

Si la base de datos se ve comprometida, el hacker no solo obtendrá los hashes de su contraseña, sino también la sal dinámica utilizada. Quizás se pregunte cuál es la ventaja de la sal dinámica sobre la sal estática si el atacante tiene sal dinámica. Incluso si el atacante tiene sal dinámica, necesita crear una nueva tabla hash (o tabla arcoíris) para todos y cada uno de los usuarios presentes en la base de datos (según la sal dinámica). Esta es una operación mucho más costosa que crear una sola tabla para todos los usuarios.

El enfoque anterior es bastante bueno para ralentizar a un hacker. Sin embargo, se recomienda utilizar algoritmos como bcrypt y scrypt.en lugar de MD5/SHA1. Bcrypt es un algoritmo hash basado en Blowfish. Requiere que especifique un factor de costo/trabajo. El factor de trabajo hace que el proceso general sea más lento y, por lo tanto, el tiempo necesario para generar una tabla hash aumentaría varias veces.

Referencias:
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/

Este artículo es una contribución de Saket Kumar . Si le gusta GeeksforGeeks y le gustaría contribuir, también puede escribir un artículo usando contribuya.geeksforgeeks.org o envíe su artículo por correo a contribuya@geeksforgeeks.org. Vea su artículo que aparece en la página principal de GeeksforGeeks y ayude a otros Geeks.

Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.