Lo que está proponiendo es muy peligroso y en contra de las mejores prácticas de seguridad. Un problema con esto es que los usuarios tienden a reutilizar las mismas contraseñas en diferentes servicios. Esto significa que una contraseña filtrada puede hacer que muchas de sus cuentas queden vulnerables. (Por ejemplo, hack reciente de Mark Zuckerberg ). Esto se combina con el hecho de que los contenidos de la base de datos a veces se filtran debido a fallas como la inyección de SQL.
Para ayudar a proteger a estos reusadores de contraseñas, los sitios web deben esforzarse mucho para proteger los valores de las contraseñas, ya que una violación hace que muchos sitios sean vulnerables.
Esto significa solo almacenar contraseñas en un formato seguro, no reversible. Puede leer sobre la ciencia en ¿Cómo hash seguro de contraseñas? , pero Probablemente sea bueno si usa bcrypt con sus parámetros predeterminados.
Si se estaba integrando con un sitio de terceros que solo era compatible con la autenticación de nombre de usuario / contraseña y ese sitio no estaba dispuesto a proporcionar un mecanismo de autenticación seguro, tal vez tendría sentido almacenar las contraseñas para el sitio remoto (deberían estar encriptadas de manera segura). cuando no esté en uso). Pero es el propietario del sitio remoto, así que haga lo correcto y admita un mejor modelo de inicio de sesión que las contraseñas.
Algunas estrategias posibles son:
- OAuth (quizás a través de OpenID ), SAML 2 u otro sistema existente que admita el inicio de sesión único.
- Al utilizar autenticación mutua SSL , site2 podría generar certificados de cliente al registrarse y pasarlos a site1. Luego, una violación de la base de datos de site1 solo expone los certificados y no las contraseñas de los usuarios (recuerde que usan las mismas contraseñas para otros sitios).
-
personificación (¿quizás alguien pueda agregar una mejor referencia en los comentarios?) funciona si hay una confianza sólida modelo entre site1 y site2. Básicamente, si los sitios tienen los mismos autores e implementadores, usted podría permitir que site1 le diga a site2 que simplemente simule que está siendo llamado por
JoeUser sin ninguna credencial. Site1 tendría que autenticarse de forma segura en site2 para asegurarse de que los usuarios malintencionados no puedan usar esta función.
- Haga que el usuario escriba su contraseña de site2 en site1 siempre que la necesite.
Estoy seguro de que hay más soluciones, pero almacenar contraseñas en un formato reversible (por ejemplo: cifrado) no es una buena práctica. Y el almacenamiento de contraseñas como texto claro es imperdonable.