Hay un punto interesante en tu pregunta:
Pensé en guardar su contraseña en su computadora y en obtener la página web para enviarla. Sin embargo, no creo que eso los haga sentir más seguros.
¿Desea que los usuarios estén seguros o se sientan seguros? Eso no es lo mismo.
Si almacena la contraseña en su servidor, usted se hace responsable de ello. Hay algunos trucos que se pueden usar para reducir los riesgos de fugas, pero los riesgos seguirán existiendo. Por ejemplo, si almacena los correos electrónicos en forma encriptada en la base de datos, entonces el software del servidor tendrá que descifrarlos antes de usarlos, por lo que el servidor debe conocer la clave de descifrado, pero esa clave no debe ser conocida a la base de datos ; podría almacenarse en un archivo y descifrarlo en el servidor ( no con capacidades criptográficas basadas en SQL ofrecidas por la base de datos). Esto puede proporcionar cierta protección contra los ataques de inyección de SQL. Es un baile delicado: si el servidor puede acceder a las contraseñas almacenadas solo , el volcado de todo el contenido del servidor (por ejemplo, una imagen completa del disco duro) también debe otorgar acceso; Cualquier clave de cifrado debe estar allí. El cifrado, en ese caso, es una apuesta a la idea de que los ataques serán parciales : un atacante volcará el contenido de la base de datos, no todo el disco.
Un mejor sistema puede tener este aspecto:
- Para cada usuario u , se genera una clave simétrica aleatoria Ku .
- La contraseña de correo electrónico para el usuario u está cifrada con Ku ; eso es lo que se almacena en el servidor.
-
Ku NO se almacena en el servidor, sino en el cliente.
- Al conectarse, Ku se envía desde el cliente al servidor. El servidor lo usa para recuperar la contraseña del correo electrónico, solo en RAM; la contraseña desencriptada y Ku , nunca se escriben en archivos o bases de datos.
Almacenamiento de un valor secreto específico del cliente en el cliente, enviado de vuelta al servidor: es una cookie HTTP. Asegúrate de marcarlo como Secure and HttpOnly , y usar HTTPS para todas las conexiones.
Con ese sistema:
- La contraseña del correo electrónico no se almacena en el sistema cliente y, por lo tanto, no se pondrá en riesgo cuando el teléfono inteligente del usuario es robado.
- El almacenamiento permanente del servidor (archivos, base de datos) no permite la recuperación de la contraseña. Un atacante que roba todo el sistema (toma las máquinas y se ejecuta) no podrá obtener las contraseñas, independientemente de la potencia informática que dedique a las tareas (suponiendo que el cifrado se realizó correctamente, por supuesto. ) (Esto contrasta con el hashing de contraseñas, donde las contraseñas débiles aún se pueden descifrar, a un costo).
Sin embargo:
- Si su servidor es secuestrado "en silencio", el atacante podrá observar las contraseñas cuando se ponga en uso. Esto es inevitable en su sistema. La única forma de evitarlo sería un sistema de emisión de tickets a la Kerberos , utilizado por el correo electrónico el servidor y el sistema cliente , siendo su servidor una simple retransmisión para el ticket de Kerberos; pero el servidor de correo electrónico normal no hace Kerberos, y tampoco lo hacen los sistemas cliente (en particular cuando "cliente" es algo de Javascript en una página web).
- Si el usuario pierde sus cookies (por ejemplo, cambia de su teléfono a su computadora de escritorio y no tiene un sistema de sincronización entre los dos), se pierde Ku y el usuario debe volver a ingresar su contraseña de correo electrónico.
El último punto es, de nuevo, inherente. Si su servidor no almacena datos suficientes para recuperar la contraseña del correo electrónico sin la ayuda del usuario, entonces ... el servidor no puede recuperar la contraseña del correo electrónico sin la ayuda del usuario. Si el usuario también está indefenso, se pierden los datos.