Es un token de sesión suficiente para aplicaciones críticas

Esto es demasiado largo para un comentario a la respuesta de Silvers, pero usa información del enlace que publicó y responde a mi pregunta de manera muy específica.

  

Vincular el ID de sesión a otras propiedades de usuario

     

Con el objetivo de detectar (y, en algunos escenarios, proteger   en contra) de los malos comportamientos de los usuarios y el secuestro de sesiones, es altamente   se recomienda vincular el ID de sesión a otras propiedades de usuario o cliente,   como la dirección IP del cliente, User-Agent o digital-based-based   certificado. Si la aplicación web detecta algún cambio o anomalía.   entre estas diferentes propiedades en medio de un establecido   sesión, este es un muy buen indicador de la manipulación de la sesión y   intentos de secuestro, y este simple hecho se puede utilizar para alertar y / o   terminar la sesión sospechosa.

     

Aunque las aplicaciones web no pueden utilizar estas propiedades para   Defienden confiadamente contra ataques de sesión, aumentan significativamente   Las capacidades de detección (y protección) de la aplicación web. Sin embargo,   un atacante experto puede pasar por alto estos controles reutilizando la misma IP   Dirección asignada al usuario víctima al compartir la misma red (muy   comunes en entornos NAT, como puntos de acceso Wi-Fi) o utilizando el mismo   proxy web de salida (muy común en entornos corporativos), o por   modificando manualmente su User-Agent para ver exactamente como los usuarios víctimas   lo hace.

Esto resalta lo que es un tipo de mensaje mixto. Por un lado, se sugiere que la información del usuario se almacene y se verifique de forma cruzada para detectar intentos de piratería claros, pero se admite que un atacante experto puede falsificar esta información.

Entonces, tendrías que llegar a una conclusión si quieres protegerte contra piratas informáticos expertos y quién no lo hace, que estas verificaciones cruzadas y al mismo tiempo hacerte sentir mejor no te ofrecerán más protección.

Si usa cookies para almacenar los ID de sesión, asegúrese de que esté configurado en una cookie con el atributo Secure y HttpOnly. Restrinja los atributos del dominio y la ruta tanto como sea posible. Asegúrese de que ninguna aplicación web que no sea de confianza esté alojada en un dominio relacionado que pueda lanzar un ataque de fijación de sesión. Establecer un tiempo de caducidad razonable para la sesión. Sirva todas sus páginas a través de HTTPS ya que el contenido mixto puede filtrar su ID de sesión. Intente limitar las bibliotecas de JavaScript cargadas externamente para minimizar la superficie de ataque.

Algunos servidores de aplicaciones como Tomcat le permiten usar las ID de sesión SSL en lugar de las ID de sesión almacenadas en cookies. Estas ID de sesión SSL están mejor protegidas, pero debería poder compartir la sesión SSL en varios servidores en su caso.

Se pueden encontrar muchos más consejos aquí: Hoja de referencia para la administración de sesiones

EDITAR:

No están trabajando en la vinculación de tokens como los ID de sesión a un cliente a través de la clave pública-privada y la firma. Lea el borrador aquí . Pasará un tiempo antes de que lo adopten los principales proveedores de navegadores, pero en lo que respecta a la vinculación de un ID de sesión a un cliente, esto parece resolver todos los problemas. Por supuesto, hay una cierta sobrecarga de generación y firma de claves y necesita el soporte del cliente para que esto funcione.

Debes asegurarte de que

• tienes una información de autenticación, tu token, por ejemplo,
• esta información de autenticación no se puede adivinar: el token debe tener, entre otros, una entropía y una atomicidad suficientes (un token se genera de forma independiente de los demás, es decir, saber un token no ayuda a conocer el siguiente)
• esta información de autenticación no se puede manipular mientras está en tránsito: use HTTPS

Si desea restringir aún más quién puede autenticarse, use los certificados del lado del cliente (ya que de todos modos usará HTTPS): es probable que se amplíen mejor que el filtrado de IP.

Como mencionas, los tokens son lo suficientemente buenos para Google y otros grandes jugadores. Por lo tanto, también son lo suficientemente buenos para mí.

Los tokens de sesión solo son útiles cuando se transmiten a través de un protocolo seguro (como https:// ). Los tokens de sesión sin un protocolo seguro se pueden robar fácilmente.