Algunos sistemas de terceros ofrecen una gestión de sesión explícitamente para este fin.
Por ejemplo, Google puede requerir autenticación de dos factores si los usuarios configuran eso, y para aplicaciones (¿como la suya?) que no son compatibles con TFA, tienen contraseñas específicas de la aplicación o algún tipo de sesión permanente. / p>
Puede haber más de un tipo, por ejemplo, el inicio de sesión de Stack Exchange tiene SE solicitando una pequeña cantidad de datos de Google, pero podrían obtener mucho más si el usuario lo permitiera. Por otro lado, puede haber otras API o posibilidades de sesión a largo plazo que solo requieran que el usuario vuelva a ingresar su contraseña cuando ocurra algo relacionado. (lo cual es raro)
Cada servicio de terceros (Google, Facebook, etc.) tendrá sus propias opciones diferentes aquí.
Si aún determina que permanentemente es necesario almacenar una contraseña , entonces sí, el cifrado bidireccional es el camino a seguir .
AES-128 (o superior) es el algoritmo de cifrado simétrico recomendado para usar. Siempre que la clave se genere utilizando un Generador de números aleatorios criptográficamente seguros (pseudo), entonces no será práctico para el atacante a fuerza bruta. Por lo tanto, el atacante buscará una forma de robar la clave en su lugar.
Suponiendo que sus datos se encuentren en un servidor SQL, simplemente almacenar la clave fuera de la base de datos al menos le brindará cobertura contra los ataques de SQLi. No codifique la clave en el código fuente de su aplicación, sino que, coloque la llave en un archivo separado , de modo que ese código fuente pueda copiarse en un entorno de prueba si es necesario, y un código separado (no -secret) puede usarse para tales entornos.
Sin embargo, esto solo lo protege contra las fugas de código fuente y SQLi. Otros tipos de intrusión podrían permitirle al atacante leer archivos en todo el servidor.
Asegúrese de que su aplicación (y el sistema de autenticación en el que se basa) se ejecute en su propia cuenta de usuario en el sistema operativo y el sistema de archivos. El archivo clave no debe ser legible por otros usuarios (usted sin sudo ) o aplicaciones (por ejemplo, sendmail ) en el sistema de esta manera. (es decir, establezca los permisos de archivo de claves en 600 o 400 para sistemas similares a UNIX)
En general, debe proteger su aplicación y cualquier servicio en este entorno contra todo tipo de ataques. Esta es la primera línea de defensa. Cualquier otra sugerencia aquí es una garantía para ayudar a reducir el impacto de un hack exitoso.
Siempre es posible que haya un error y que una intrusión llegue a la cuenta de usuario confidencial. (el que accede al archivo de claves)
Es posible segregar las cuentas de usuario dentro de tu única aplicación, pero esto se complica.
La salvaguardia final es use la contraseña y la sesión del usuario final para derivar la clave de descifrado . Creo que esta es la solución más segura después de que ha cubierto los puntos anteriores, pero su implementación es compleja y no es compatible con una función de restablecimiento de contraseña autónoma.