¿Debo implementar mi propio hash de contraseña local?

Lo que describe es uno de los dos métodos principales utilizados por los productos de "bóvedas de contraseña". Tales productos intentan hacer que sea más fácil para usted (el usuario humano) "recordar" las contraseñas específicas del sitio, a la vez que mantiene la propiedad importante, que es la especificidad de las contraseñas: una contraseña para cada sitio, por lo que una violación de un sitio no pone en peligro sus cuentas en otros sitios.

Los dos métodos principales son:

1. Intente "derivar" (a través de funciones hash o construcciones similares) una contraseña específica del sitio de una contraseña maestra; el nombre del sitio se usa como parámetro adicional, para asegurarse de que cada sitio tenga su propia contraseña.

2. Genere contraseñas aleatorias para cada sitio y almacénelas localmente (en el cliente), cifradas con una "contraseña maestra".

En ambos casos, necesita software del lado del cliente, ya que no se conoce ningún método para lograr la unidireccional requerida para la especificidad adecuada con solo capacidades del cerebro humano (consulte esta pregunta anterior ). Dicho software puede ser una aplicación local, algún script, una extensión del navegador ...

Su propuesta se relaciona con el método "tipo 1" (derivación de la contraseña maestra). La esperanza habitual es que el método de "tipo 1" permita prescindir del almacenamiento local. Desafortunadamente, esto falla en dos cuentas:

• Como ha notado, las reglas de contraseña exigidas por varios sitios son incompatibles entre sí, por lo que no puede generar contraseñas que puedan ajustarse a todos los sitios posibles. Por lo tanto, algo en su sistema debe recordar las reglas de cada sitio específico, para que la contraseña del sitio pueda volver a calcularse correctamente.

• Algunos sitios exigen cambios de contraseña a intervalos más o menos regulares. Una derivación de contraseña sin almacenamiento no puede hacer frente a un cambio de contraseña.

Las bóvedas de contraseña "Tipo 1" aún tienen valor, ya que el almacenamiento local requerido no necesita ser confidencial, ya que no incluye nada que dependa de la contraseña maestra ( sí incluye información sobre todos los sitios sin embargo, en el que tiene cuentas, y eso puede ser un problema de privacidad). Por otro lado, cada contraseña específica del sitio puede usarse para un ataque de diccionario sin conexión en su contraseña maestra, lo que puede ser un problema.

Las bóvedas de contraseña "tipo 2" son más flexibles y, por lo tanto, son más comunes (por ejemplo, KeePass ). Algunos de ellos se juntan con un almacenamiento centralizado (vea 1Password ) para que pueda acceder a sus contraseñas desde todos sus dispositivos. Un punto realmente bueno de las bóvedas "tipo 2" es que las contraseñas específicas del sitio, generadas aleatoriamente, no (en un sentido matemático sólido) filtran información sobre su contraseña maestra o contraseñas para otros sitios.

    

Un par de problemas que veo con ese enfoque:

• Probablemente quieras seguir adelante y eliminar el hash (incluso si es solo con el nombre del sitio).
• Si alguna vez intentas iniciar sesión desde otra computadora, necesitarás tener tu programa hash disponible. Alternativamente, puede usar un hash que puede obtener de un sitio web, pero luego está enviando su contraseña a un dominio que no es de confianza.
• Deberá asignar la salida del hash a esas restricciones arbitrarias, por lo que deberá conocer el esquema por sitio cada vez que inicie sesión. Por ejemplo, un sitio puede requerir caracteres especiales mientras que otro puede prohibir ellos.

He recomendado esta estrategia en el pasado y creo que parece ser sólida aparte de los elementos que mencioné anteriormente; Espero ver los consejos de otros sobre el tema.

    

Si acaba de usar un hash de su contraseña, su contraseña de hash se convertiría en su nueva contraseña de facto. Si se usa en más de un sitio, es similar a reutilizar su contraseña normal, aunque es de esperar que sea más difícil de adivinar o forzar la fuerza bruta.

En la práctica, desea mezclar una sal (para proteger de las tablas del arco iris) y el nombre del sitio web (para proteger de la reutilización) en el proceso de hash, pero luego encuentra otro problema (además de los mencionados por otros): los sitios comparten la base de datos de usuarios, ya que en realidad son ejecutados por la misma compañía o son simplemente un nombre diferente o frontent para el mismo servicio.

Es mejor usar solo un administrador de contraseñas, imo.