“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, incluido ayer, de Yahoo . Pero, ¿deberíamos realmente tomar estas garantías al pie de la letra?
La realidad es que la base de datos de contraseñas compromete son una preocupación, no importa cómo una empresa intente darle vueltas. 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 deben almacenarse 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 hashes para 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 hash diferentes 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 aplicaran 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 usar hash en 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 hashes para muchas contraseñas y luego verificar si existían 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.
- Usar sales cortas : Si se utilizan sales de unos pocos dígitos, sería posible generar tablas de búsqueda que incorporaran 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 la historia completa, 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. Siempre pecar de cauteloso.
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á utilizando algunas de las contraseñas más comunes.
RELACIONADO: Cómo los atacantes realmente "piratean cuentas" en línea y cómo protegerse
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 recursos ataques de fuerza ellos quieren.
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, lo que, como todos sabemos, facilita 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 habrá aprendido nada útil. Si usa la misma contraseña en todas partes, podrían acceder a sus otras cuentas. Esto es cuántas cuentas de personas son "pirateadas".
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 deberías considerar usando autenticación de dos factores , que lo protegerá incluso si un atacante conoce su contraseña.
RELACIONADO: Por qué debería utilizar un administrador de contraseñas y cómo empezar
Lo más importante es no reutilizar las contraseñas. Las bases de datos de contraseñas comprometidas no pueden perjudicarlo 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.
Credito de imagen: Marc Falardeau en Flickr , Wikimedia Commons
