¿ataque anti-reproducción para cookies seguras?

Una estrategia más segura es crear una aplicación en la que es muy difícil obtener el ID de sesión en primer lugar. Establezca los indicadores Secure y HTTPOnly en el valor de la cookie. Elimine las vulnerabilidades de XSS, CSRF y Clickjacking en la aplicación.

He usado mod_auth_tkt , que utiliza un esquema muy similar.

Sugeriría una consideración muy cuidadosa antes del uso de la clave de sesión SSL : la sesión del usuario (aplicación), las conexiones TCP / HTTPS y el ID y la clave de la sesión SSL son cosas distintas. No necesariamente tienen la misma vida.

Además, la reutilización o la reutilización de material criptográfico generalmente está mal visto (aunque no puedo decir que haya definitivamente algo malo en su uso en un HMAC, el problema es determinar lo contrario).

En el caso de un navegador / aplicación web convencional, este tipo de esquema puede tener problemas inmediatamente evidentes, por ejemplo. cuando las pestañas del navegador don No comparto el estado .

Lo que ha autenticado es un "estado" del navegador, atarlo a cualquier otra cosa (estado SSL o dirección IP) es muy complicado. La vinculación con el ID de sesión SSL es más común (aunque tiene un historial de problemas de MSIE). Una de las mejores maneras de lograr esto es mediante el uso de certificados de clientes, no trivial para implementar y administrar, por supuesto.

Vea esto para muchas más consideraciones: enlace y (ahora completo) RFC 6896 Secure Cookie Sessions (borrador vinculado en la respuesta aceptada para La pregunta a la que te vinculas tiene una sección dedicada a los problemas de repetición.