Por qué debería preocuparse siempre que se pierda la base de datos de contraseñas de un servicio

“Nuestra base de datos de contraseñas fue robada ayer. Pero no se preocupe: sus contraseñas fueron encriptadas ". Regularmente vemos declaraciones como esta en línea, incluso ayer, de Yahoo. Pero deberíamos realmente tomar estas garantías a su valor nominal?

La realidad es que la base de datos de contraseñas compromete son una preocupación, no importa cómo una empresa puede tratar de hacerla girar. 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

Aquí es cómo las empresas deben almacenar las contraseñas en un mundo ideal: 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 parece más a "4jfh75to4sud7gh93247g ...". Cuando ingresa su contraseña para iniciar sesión, el servicio genera un hash y comprueba 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 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 hashes que coinciden con las contraseñas. Los hashes pueden ser comparados con la base de datos. Por ejemplo, un atacante sabría el hash para "password1" y luego vería si alguna cuenta en la base de datos está usando ese hash. Si lo son, el atacante sabe que su contraseña es "password1".

Para evitar esto, los servicios deben "saltear" sus hashes. En lugar de crear un hash a partir de la propia contraseña, agregan una cadena aleatoria al principio o al final de la contraseña antes de incluirla. En otras palabras, un usuario ingresaría la contraseña "contraseña" y el servicio agregaría el salt y el hash a una contraseña que se parece más a "password35s2dg". Cada cuenta de usuario debe tener su propio salt, y esto garantizaría que cada cuenta de usuario tendría un valor hash diferente para su contraseña en la base de datos. Incluso si varias cuentas utilizan la contraseña "contraseña1", tendrían diferentes hashes debido a los diferentes valores de sal. Esto derrotaría a un atacante que intentara calcular previamente los hashes para las 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 llevaría mucho más tiempo de cálculo y memoria..

Es por eso que los servicios a menudo dicen no preocuparse. Un servicio que utiliza procedimientos de seguridad adecuados debe indicar que utilizaron hashes de contraseña con sal. Si simplemente dicen que las contraseñas están "hash", es más preocupante. LinkedIn hirió sus contraseñas, por ejemplo, pero no las saltaron, así que fue un gran problema cuando LinkedIn perdió 6.5 millones de contraseñas hash en 2012.

Malas prácticas de contraseña

Esto no es lo más difícil de implementar, pero muchos sitios web aún pueden arruinarlo de varias maneras:

Almacenamiento de contraseñas en texto sin formato: En lugar de molestarse con el hash, algunos de los peores infractores pueden simplemente descargar las contraseñas en texto sin formato en una base de datos. Si tal base de datos está comprometida, sus contraseñas obviamente están comprometidas. No importaría lo fuertes que fueran.
Hashing las contraseñas sin saltarlas: Algunos servicios pueden codificar las contraseñas y ceder allí, optando por no usar sales. Dichas 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ían hacer esto para cada cuenta a la vez si no se usaba Salt..
Reutilizando sales: Algunos servicios pueden usar un salt, pero pueden reutilizar el mismo salt para cada contraseña de cuenta de usuario. Esto no tiene sentido: si se utilizara la misma sal para cada usuario, dos usuarios con la misma contraseña tendrían el mismo hash.
Usando sales cortas: Si se usan sales de solo unos pocos dígitos, sería posible generar tablas de búsqueda que incorporen cada sal posible. Por ejemplo, si se utilizara un solo dígito como sal, el atacante podría generar fácilmente listas de hashes que incorporaban todas las sal posibles.

Las empresas no siempre le contarán toda la historia, por lo que incluso si dicen que una contraseña se ha descifrado (o se ha eliminado y eliminado), es posible que no utilicen las mejores prácticas. Siempre errar por el lado de la precaución..

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 utilizara un valor de sal único para cada usuario, los atacantes tendrían que gastar enormes cantidades de energía de la CPU rompiendo todas esas contraseñas.

En la práctica, muchas personas usan 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 su sal, ellos pueden verificar fácilmente si está usando algunas de las contraseñas más comunes.

Si un atacante lo tiene para usted y quiere descifrar su contraseña, puede hacerlo con fuerza bruta siempre y cuando sepan el valor de sal, lo que probablemente sí saben. Con el 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 fuga de Yahoo, las preguntas y respuestas de seguridad también se filtraron, lo que, como todos sabemos, facilita el acceso a la cuenta de alguien..

Ayuda, ¿Qué debo hacer??

Lo que diga un servicio cuando se roba su base de datos de contraseñas, es mejor asumir que cada servicio es completamente incompetente y actuar en consecuencia.

Primero, no reutilice las contraseñas en múltiples sitios web. Use 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 usted solo usa esa contraseña en ese sitio web específico, no han 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 debe hacerlo en primer lugar.

También debe considerar el uso de la autenticación de dos factores, que lo protegerá incluso si un atacante aprende su contraseña..

Lo más importante es no reutilizar 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 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