Tengo algunas preguntas sobre mi implementación de seguridad de token de portador (JWT para ser específico) en un proyecto de asp.net core 2.0 en el que estoy trabajando. El token de portador se usa cuando la aplicación web frontend se comunica con una API (ambos son controlados por mí y viven en el mismo servidor).
Primero, permítame resumir lo que implementé y mi razonamiento:
Los tokens de acceso se almacenan a través de una cookie segura de solo http
Creo que esto limita la superficie de ataque a solo XSRF (corríjame si me equivoco). Para prevenir contra XSRF, he implementado tokens antiforgery / XSRF.
Los tokens de acceso tienen un número de versión
La tabla Mis usuarios tiene una columna para la versión de token, y este número se incluye cuando se emite un token de acceso para el usuario.
- Si las versiones del token no coinciden durante la autenticación / autorización, se deniega la solicitud y se emite un desafío
- Hay una lógica que actualiza automáticamente la versión del token cuando corresponde (es decir, un administrador bloquea una cuenta, el usuario cambia su correo electrónico o se desconecta, etc.). También se puede cambiar manualmente si es necesario, por ejemplo, si se sabe que se comprometió una cuenta específica o cualquier otro motivo válido para revocar el acceso
- Nota al margen: he implementado una forma de evitar constantes visitas a la base de datos cuando los usuarios activos requieren la verificación del número de versión y pueden elaborarlas si es necesario, pero no creo que se aplique directamente a mis preocupaciones de seguridad en esta pregunta
Sin tokens de actualización y caducidad larga para los tokens de acceso
No uso tokens de actualización en absoluto, y mis tokens de acceso están configurados para que caduquen después de 7 días (a menos que "Recordarme" no esté marcado, en cuyo caso la caducidad se establece en Sesión). Aquí está mi justificación:
- La funcionalidad de la versión del token resuelve el problema de la necesidad de revocar un token de acceso mientras su caducidad sigue siendo válida.
- Incluso con una caducidad muy corta del token de acceso, una cuenta / sesión comprometida podría simplemente usar el token de actualización de mayor duración para adquirir un nuevo token de acceso válido, así que simplemente estoy eliminando al intermediario (corríjame si me equivoco o ingenuo)
Por lo tanto, aquí están mis preguntas específicas (y, para aclarar, no pido opiniones sobre las mejores prácticas y demás, sino respuestas objetivas sobre si la implementación satisface un nivel de seguridad razonable):
- ¿El uso de una cookie de solo http limita la superficie del ataque solo a los ataques XSRF? ¿Y se puede evitar "completamente" el XSRF mediante tokens Antiforgery / XSRF?
- ¿Es un sistema de control de versiones de token una forma válida de garantizar la revocación de acceso adecuada?
- ¿Es razonable renunciar a los tokens de actualización y permitir tiempos de caducidad de token de acceso más prolongados cuando un sistema de control de versiones de token está en uso (y los tokens están protegidos a través de las cookies de http y tácticas de antiforgery)?