He estado pensando en esto un poco debido al hecho de que nunca debes almacenar las contraseñas de los usuarios en texto plano. por lo que he encontrado una posible solución para usted.
Cuando un usuario se registre para recibir un nuevo "servicio" en su cuenta (por ejemplo, agrega gmail o yahoo, etc.), lo que tendrá que hacer es:
-
Pídale nuevamente al usuario la contraseña de su sitio (y valídelo)
-
Vuelva a descifrar su contraseña con un nuevo salt aleatorio (que debe almacenar) (con un algoritmo hash diferente al que usa para su almacén de contraseña principal) ¡NO ALMACEN ESTO! de ahora en adelante me referiré a esto como KEY_A
-
genera una clave dsa o rsa con contraseña con KEY_A como la contraseña para el archivo de claves. Se utilizará como clave de acceso para el siguiente paso
-
Use un método de cifrado seguro (tal vez mcrypt si está en php ya que está integrado) y almacene su contraseña 'encriptada'
-
Cuando un usuario inicia sesión y se crea una nueva sesión, vuelve a usar su contraseña con el mismo método utilizado en el paso # 2, Cifrala con una clave que se deriva de algo que es único para su sesión pero no se almacena (Digamos que user_agent + session_start_time + su dirección IP + una sal específica del usuario). Almacene este valor encriptado en una cookie http_only, borre dicha cookie al cerrar sesión, obligue a que inicie sesión nuevamente si la cookie no está presente.
Ahora tiene un método para almacenar su gmail / hotmail / etc. credenciales de una manera en la que no tiene una forma directa de saber cómo descifrarlas sin la contraseña que usan para su servicio.
Es muy probable que también sea prudente asegurarse de no almacenar algunos de los componentes utilizados para cifrar la cookie (por lo tanto, al menos deshabilite el registro del agente de usuario en la configuración del servidor web)
Ahora para realizar un inicio de sesión de iMap (o algo similar. simplemente tendría que descifrar la cookie http_only del paso 5 para obtener KEY_A, use KEY_A para desbloquear la clave RSA / DSA, luego use la clave desbloqueada para descifre la contraseña a su servicio, luego realice la transacción iMap, y solo para volver a cero paranoico (en php puede simplemente llamar unset ()) las variables que contienen su contraseña de texto simple, KEY_A, y su tecla rsa / dsa desbloqueada línea de código después de que ya no sean necesarios.
Además de esto, asegúrese de que su servicio DNS también esté configurado de manera segura. (forzar DNS-SEC, tal vez incluso configurar la resolución de DNS de los servidores web a través de una interfaz de red de servicio y no la visible por la web y realizar la resolución del DNS a través de una dirección IP visible "no relacionada" diferente.) Asegúrese de que su https Los certificados están completamente actualizados.
Debido a que enviará de manera efectiva las contraseñas privadas de los usuarios a través de la web, lo último que desea es que alguien inunde la dirección IP de su servidor web con el redireccionamiento de paquetes de resolución de DNS de udp. Se han creado con el propósito de oler las contraseñas.
El único inconveniente de este método (en el que puedo pensar) es que cuando el usuario cambia la contraseña de su servicio, tendrá que volver a ingresarla a todos los demás proveedores de correo electrónico que se hayan registrado. (porque la contraseña cifrada almacenada ya no será válida).
Y por último, pero no menos importante (supongo que esto se hará, pero no tengo forma de estar seguro). ¡elimine el código de depuración ALL relacionado con estas rutinas antes de ponerlo en funcionamiento! p>
La clave completa para esto es garantizar que KEY_A no se pueda derivar de nada que usted almacene (así que no haga un atajo simplemente al volver a marcar el hash de su contraseña, haga el hash de una manera diferente, con un salt diferente).