La diferencia de seguridad estará principalmente en los detalles de la implementación. Fundamentalmente, ambos enfoques son los mismos: almacena un blob de datos que no tiene sentido para el cliente en el cliente para preservar algún estado entre las solicitudes. La diferencia es que las cookies de identificación de sesión no tienen significado en sí mismas porque no representan ninguna información significativa, mientras que la cookie cifrada no tiene sentido porque el cliente no posee la capacidad de descifrar los datos.
Las cookies cifradas son fundamentalmente más complejas: tienen un tamaño mayor, requieren un algoritmo complejo, requieren que el algoritmo se implemente correctamente, contienen datos reales y, por lo tanto, vale la pena atacarlas, requieren la administración de un llave secreta. También son más difíciles de revocar debido a su naturaleza descentralizada.
Las cookies de identificación de sesión son simples: una identificación aleatoria sin sentido simplemente se refiere a los datos almacenados en otro lugar. La única vulnerabilidad * es la capacidad de diagnóstico, que es bastante fácil de prevenir al aumentar la longitud y la rotación y caducidad de las identificaciones. No tengo idea de por qué almacenar los identificadores de sesión / datos en una base de datos sería una mala idea de ninguna manera; Mientras la base de datos sea segura, no hay problema allí. Si su almacén de datos es propenso a ataques, tiene problemas más grandes que donde se almacenan los datos de su sesión.
(* Aparte del secuestro directo, que es la misma vulnerabilidad para todas las cookies, y fallas específicas de la implementación como aceptar identificadores de sesión indefinidos, etc.)
Teniendo en cuenta eso, debe decidir si el aumento de la superficie de ataque de las cookies cifradas vale los beneficios de los servidores sin estado y si confía en la implementación del cifrado. Para una alta escalabilidad, lo estudiaría seriamente, para servicios a pequeña escala lo mantendría lo más simple posible.