De lo que se trata esta respuesta es del almacenamiento del lado del cliente.
La primera premisa es que todo esto ocurre en una sesión SSL, por lo que no será interceptado por terceros. El atacante restante, en su caso, es el propio usuario. En particular, solo el usuario real puede devolver el valor de la cookie al servidor.
Luego, el servidor desea gestionar sesiones , es decir, considerar las solicitudes sucesivas del mismo cliente como parte de una "historia" completa. Esto implica que el servidor debe recordar la información de la sesión de una solicitud a la siguiente.
La memoria del lado del servidor implica dos problemas principales:
-
La cantidad de almacenamiento en el servidor puede crecer bastante. De hecho, las solicitudes sucesivas de un cliente determinado pueden ocurrir con un retraso bastante grande entre (minutos, incluso horas o más). Además, un determinado cliente puede dejar de enviar solicitudes por completo y el servidor no recibirá ninguna advertencia al respecto. Entonces, en un servidor ocupado, estamos hablando de salvar decenas de miles o más de objetos de "información de sesión". Esto puede traducirse en un número no despreciable de megabytes de RAM.
-
Si el servidor es multi-frontends, la información de la sesión del usuario debe compartirse entre los frontends, lo que implica una comunicación adicional, a menudo con una base de datos compartida, que a su vez puede implicar problemas de rendimiento (una base de datos no es tan rápido como la RAM local pura).
Por lo tanto, sería bueno si la información de la sesión del usuario pudiera almacenarse en el propio cliente. De esto se trata este esquema de cookie + encriptación + MAC. El servidor empaqueta lo que quiere recordar sobre una sesión de usuario en un blob que se envía al cliente; entonces es responsabilidad del cliente enviarlo de vuelta con la siguiente solicitud. El servidor no almacena nada en su lado. Esto se adapta muy bien a millones de usuarios y docenas de interfaces, ya que el servidor no tiene que recordar nada. Implica, sin embargo, sus propios retos:
- Dado que los datos se almacenan en el cliente, el cliente puede inspeccionarlos, lo que no es necesariamente algo bueno. El cifrado resuelve eso.
- Dado que los datos se almacenan en el cliente, el cliente puede modificarlos, lo que no es necesariamente algo bueno. MAC resuelve eso.
- Como el servidor no recuerda nada, no puede evitar los ataques de repetición donde el cliente envía nuevamente un valor de cookie antiguo. Incluyendo una fecha (bajo la protección del MAC) mitiga este problema.
- El tamaño de las cookies se limita tradicionalmente a alrededor de 4 kilobytes, por lo que el servidor no podrá hacer que el cliente almacene más datos que eso (bueno, el servidor podría enviar varias cookies, pero volver a ensamblar se vuelve difícil, especialmente si quieres hacerlo de forma segura).
El nombre de usuario, el identificador de sesión SSL o la dirección IP, es solo un identificador no secreto que pretende evitar que diferentes usuarios intercambien sus cookies, voluntariamente o no. En este sentido, la dirección IP no es un buen identificador, porque varios usuarios pueden compartir la misma IP (en el caso de NAT o el uso de un proxy web) y la dirección IP de un usuario determinado pueden cambiar (la IP dinámica no es infrecuente).
Ahora el esquema específico explicado en la respuesta SO puede ser cuestionable; p.ej. aplica el MAC en los datos de texto claro, no en los datos cifrados, que se conoce por tiene problemas potenciales : esto se conoce como" encrypt-and-MAC ". Se pueden evitar los posibles problemas, pero esto requiere un cuidado especial en la implementación, por lo que se debería preferir "cifrar y luego MAC". La reutilización de la misma clave para el cifrado y el MAC también es, en términos generales, un mal movimiento; Aunque parece lo suficientemente seguro cuando el MAC es HMAC y el cifrado usa algún cifrado de bloque, realmente lo preferimos cuando las dos claves están de alguna manera aisladas unas de otras. Una forma moderna y más obviamente segura de hacer cifrado y MAC sería usar uno de los modos de cifrado que han sido diseñados para hacer exactamente eso, por ejemplo. GCM o EAX .
La idea sigue siendo sólida (siempre que todo esto ocurra bajo la protección de SSL). El principal problema restante es lidiar con los ataques de repetición, que, dependiendo de la aplicación, pueden o no ser serios; la inclusión de la fecha en los datos de las cookies permite al servidor aplicar una estrategia de caducidad explícita para controlar este problema.