Tabla de contenidos
“Ayer nos robaron nuestra base de datos de contraseñas. Pero no se preocupe: sus contraseñas están encriptadas «. Regularmente vemos declaraciones como esta en línea, incluida la de ayer, de Yahoo . ¿Pero deberíamos realmente tomar estas garantías al pie de la letra?
La realidad es que los compromisos de la base de datos de contraseñas son una preocupación, sin importar cómo una empresa pueda intentar manipularlos. Pero hay algunas cosas que puede hacer para aislarse, sin importar cuán malas sean las prácticas de seguridad de una empresa.
Cómo se deben almacenar las contraseñas
Así es como las empresas deben almacenar las contraseñas en un mundo ideal: usted crea una cuenta y proporciona una contraseña. En lugar de almacenar la contraseña en sí, el servicio genera un «hash» a partir de la contraseña. Esta es una huella digital única que no se puede revertir. Por ejemplo, la contraseña «contraseña» puede convertirse en algo que se parezca más a «4jfh75to4sud7gh93247g …». Cuando ingresa su contraseña para iniciar sesión, el servicio genera un hash a partir de ella y verifica si el valor de hash coincide con el valor almacenado en la base de datos. En ningún momento el servicio guarda su contraseña en el disco.
Para determinar su contraseña real, un atacante con acceso a la base de datos tendría que calcular previamente los hash para las contraseñas comunes y luego verificar si existen en la base de datos. Los atacantes hacen esto con tablas de búsqueda: enormes listas de hash que coinciden con las contraseñas. Luego, los hashes se pueden comparar con la base de datos. Por ejemplo, un atacante conocería el hash de «contraseña1» y luego vería si alguna cuenta en la base de datos está usando ese hash. Si es así, el atacante sabe que su contraseña es «contraseña1».
Para evitar esto, los servicios deben «salar» sus hashes. En lugar de crear un hash a partir de la contraseña en sí, agregan una cadena aleatoria al principio o al final de la contraseña antes de aplicar el hash. En otras palabras, un usuario ingresaría la contraseña «contraseña» y el servicio agregaría la sal y el hash de una contraseña que se parece más a «contraseña35s2dg». Cada cuenta de usuario debe tener su propia sal única, y esto aseguraría que cada cuenta de usuario tenga un valor hash diferente para su contraseña en la base de datos. Incluso si varias cuentas usaran la contraseña «contraseña1», tendrían diferentes hashes debido a los diferentes valores de sal. Esto derrotaría a un atacante que intentara precalcular hashes para contraseñas. En lugar de poder generar hashes que se aplicaron a cada cuenta de usuario en toda la base de datos a la vez, tendrían que generar hashes únicos para cada cuenta de usuario y su sal única. Esto requeriría mucho más tiempo de cálculo y memoria.
Es por eso que los servicios a menudo dicen que no se preocupe. Un servicio que utilice los procedimientos de seguridad adecuados debería decir que estaba utilizando hashes de contraseña con sal. Si simplemente dicen que las contraseñas están «codificadas», es más preocupante. LinkedIn codificó sus contraseñas, por ejemplo, pero no las saltó, por lo que fue un gran problema cuando LinkedIn perdió 6.5 millones de contraseñas hash en 2012 .
Prácticas de contraseñas incorrectas
Esto no es lo más difícil de implementar, pero muchos sitios web aún logran estropearlo de varias maneras:
- Almacenamiento de contraseñas en texto sin formato: en lugar de preocuparse por el hash, algunos de los peores infractores pueden simplemente volcar las contraseñas en forma de texto sin formato en una base de datos. Si dicha base de datos se ve comprometida, sus contraseñas obviamente están comprometidas. No importaría lo fuertes que fueran.
- Hash de las contraseñas sin salarlas : algunos servicios pueden hacer hash de las contraseñas y renunciar allí, optando por no usar sales. Estas bases de datos de contraseñas serían muy vulnerables a las tablas de búsqueda. Un atacante podría generar los hash para muchas contraseñas y luego verificar si existen en la base de datos; podría hacer esto para cada cuenta a la vez si no se usa sal.
- Reutilización de sales : algunos servicios pueden usar una sal, pero pueden reutilizar la misma sal para cada contraseña de cuenta de usuario. Esto no tiene sentido: si se usara la misma sal para cada usuario, dos usuarios con la misma contraseña tendrían el mismo hash.
- Uso de sales cortas : si se utilizan sales de solo unos pocos dígitos, sería posible generar tablas de búsqueda que incorporen todas las sales posibles. Por ejemplo, si se usara un solo dígito como sal, el atacante podría generar fácilmente listas de hashes que incorporaran todas las sal posibles.
Las empresas no siempre le contarán toda la historia, por lo que incluso si dicen que una contraseña fue hash (o hash y salada), es posible que no estén utilizando las mejores prácticas. Sea siempre precavido.
Otras preocupaciones
Es probable que el valor de sal también esté presente en la base de datos de contraseñas. Esto no es tan malo: si se usara un valor de sal único para cada usuario, los atacantes tendrían que gastar enormes cantidades de energía de la CPU para romper todas esas contraseñas.
En la práctica, tanta gente usa contraseñas obvias que probablemente sería fácil determinar las contraseñas de muchas cuentas de usuario. Por ejemplo, si un atacante conoce su hash y conoce su sal, puede verificar fácilmente si está usando algunas de las contraseñas más comunes.
Si un atacante lo tiene claro y quiere descifrar su contraseña, puede hacerlo con fuerza bruta siempre que conozca el valor de la sal, lo que probablemente sepa. Con acceso local y sin conexión a las bases de datos de contraseñas, los atacantes pueden emplear todos los ataques de fuerza bruta que deseen.
También es probable que se filtren otros datos personales cuando se roba una base de datos de contraseñas: nombres de usuario, direcciones de correo electrónico y más. En el caso de la filtración de Yahoo, también se filtraron preguntas y respuestas de seguridad, que, como todos sabemos, facilitan el robo de acceso a la cuenta de alguien.
Ayuda, ¿qué debo hacer?
Independientemente de lo que diga un servicio cuando le roban su base de datos de contraseñas, es mejor asumir que todos los servicios son completamente incompetentes y actuar en consecuencia.
Primero, no reutilice las contraseñas en varios sitios web. Utilice un administrador de contraseñas que genere contraseñas únicas para cada sitio web . Si un atacante logra descubrir que su contraseña para un servicio es “43 ^ tSd% 7uho2 # 3” y solo usa esa contraseña en ese sitio web específico, no ha aprendido nada útil. Si usa la misma contraseña en todas partes, podrían acceder a sus otras cuentas. Así es como las cuentas de muchas personas se «piratean».
Si un servicio se ve comprometido, asegúrese de cambiar la contraseña que usa allí. También debe cambiar la contraseña en otros sitios si la reutiliza allí, pero no debería hacerlo en primer lugar.
También debe considerar el uso de la autenticación de dos factores , que lo protegerá incluso si un atacante conoce su contraseña.
Lo más importante es no reutilizar las contraseñas. Las bases de datos de contraseñas comprometidas no pueden hacerle daño si usa una contraseña única en todas partes, a menos que almacenen algo más importante en la base de datos, como su número de tarjeta de crédito.
Crédito de la imagen: Marc Falardeau en Flickr , Wikimedia Commons