Descifrando secretos multiusuario en una aplicación web multiusuario

En lugar de utilizar el sistema de sesión para realizar un seguimiento de la clave, es posible que desee probar una alternativa.

Asigne a su usuario una cookie segura de tiempo limitado, de dominio limitado y de ruta de acceso con un "secreto de descifrado" recién aleatorio que genere al verificar las credenciales del usuario en el grupo empresarial.

Si la contraseña es válida, antes de que finalice el proceso de inicio de sesión, descifre la clave privada con la contraseña y vuelva a cifrarla con el "secreto de descifrado". Almacene la clave privada reencrypted en la sesión. Su usuario ahora será dirigido a su página de correo web normalmente, y las variables utilizadas en la fase de inicio de sesión se perderán.

Ahora, cada vez que el usuario navega por su sitio de correo web, enviará constantemente el "secreto de descifrado" como una cookie. Eso puede ser usado por su script del lado del servidor, junto con la clave privada cifrada, para descifrar cualquier correo electrónico, si es necesario.

Aún así, como @Vitaly menationed, no estás obteniendo una ignorancia perfecta en el lado del servidor. Un administrador de sistemas no autorizado podría, si realmente quisiera, capturar las cookies instalando y dirigiendo a un usuario a una página específica. También podría capturar los paquetes HTTP, especialmente si aún no están cifrados con TLS (lo que haría que la mayoría de esto sea inútil). También puede inspeccionar la memoria del servidor. También puede obtener la contraseña con cualquiera de estos métodos, ya que está dentro del servidor.

Sin embargo, este esquema garantiza que el secreto de descifrado no se almacenará en el servidor y no requiere ningún descifrado del lado del cliente, de la misma manera que las contraseñas normalmente no se almacenan en su base de datos. Requeriría que el administrador del sistema haga un esfuerzo real para leer los correos electrónicos, es decir, no se podría encontrar la clave privada. Y eso puede ser lo suficientemente bueno para su modelo de amenaza.

  

El único problema es: al leer los archivos de sesión, los administradores de sistemas aún pueden descifrar los mensajes de los usuarios registrados. ¿Hay algún protocolo para resolver esto?

Usted está pidiendo lo imposible: un sistema que proporcionaría a los usuarios servicios de descifrado y cifrado sin tener conocimiento de cómo lo hace, en cualquier momento (de lo contrario, ¡los administradores de sistemas también podrán descifrar los mensajes!).

Tienes que decidir en quién confías y en qué grado, porque debes confiar en alguien: al final, es el hardware el que ejecuta tu código, no tú mismo.

El mayor riesgo de almacenar el lado clave del cliente es un ataque XSS.

La seguridad de su aplicación depende en gran medida de que usted lo impida con éxito. Esto podría resultar particularmente difícil ya que un atacante presumiblemente tiene mucho margen de maniobra para elaborar un mensaje, ya que los correos electrónicos tienen una amplia variedad de caracteres y codificaciones permitidos.

Hago bastante desarrollo de .net y la cantidad de veces que veo una pregunta en stackoverflow como "¿Cómo puedo mostrar el contenido html proporcionado por el usuario en mi sitio web" con una respuesta como "Use @Html.Raw() " es increíble? La mayoría de los frameworks web tienen excelentes mecanismos de escape para prevenir ataques XSS, sin embargo, muchos desarrolladores no están al tanto de ellos o de cuándo los pasan por alto.

No estoy diciendo que no pueda mostrar correctamente un correo electrónico en formato html en una página web sin analizar posibles ataques, solo que sería muy fácil cometer un error.

En general, creo que almacenar la clave localmente me pondría bastante nervioso debido al contenido probable del mensaje y al hecho de que cualquier atacante solo tiene que enviar un correo electrónico a un usuario para inyectar un código.

Habiendo dicho eso, la clave de descifrado solo es útil si tiene acceso al contenido cifrado, y un ataque XSS dirigido contra su sitio web probablemente podría leer todos los mensajes de un usuario de todos modos.