Usabilidad y tokens CSRF

(esta pregunta podría ser más adecuada para el sitio de experiencia del usuario )

Cambie el mensaje de error a "Necesitamos que vuelva a iniciar sesión porque estuvo inactivo durante más de XX minutos". Se resolvió el problema.

Hágale saber al usuario cuánto tiempo tienen exactamente , porque si tienen que enviar un formulario complejo, deben saber que necesitarán recopilar la información que necesiten y preparar el texto que deban. entrada dentro de un tiempo establecido. Aún mejor, supervise en qué formularios las sesiones tienden a restablecerse y use esa información para determinar si debe admitir sesiones más duraderas.

En ocasiones, los usuarios pueden hacer que un token caduque antes de iniciar sesión , según lo señalado. En ese caso, una formulación que sea lo suficientemente genérica para cubrir ambos casos de uso eliminará la necesidad de que intente probar cómo se veía la sesión antes de que expirara. Aún debe abordar la confusión que un mensaje de este tipo puede causar a los usuarios que no iniciaron sesión anteriormente (es posible que su modelo mental no se ajuste a la idea de que los formularios individuales caducan en lugar de las sesiones reales).

Puede hacerlo agregando el enlace "obtener más información" o "más detalles" en su mensaje de error. Al hacer clic en ese enlace se puede mostrar un párrafo adicional que explica (sucintamente, ¡y en prosa muy simple!) Que los formularios de inicio de sesión web caducan después de XX minutos por razones de seguridad, y el usuario estuvo inactivo durante demasiado tiempo. Aún tendrá que asegurarse de que los usuarios sin JS puedan ver texto adicional.

En este punto, también podría implementar su idea de servir un token CSRF nuevo a través de AJAX cuando el usuario ha estado inactivo durante el tiempo suficiente ...

Editar: algunos servicios muestran directamente un temporizador que indica durante cuánto tiempo será válida la página actual. Podría ir tan lejos como para implementar dicho temporizador en una página de inicio de sesión independiente. Esto al menos preparará a los usuarios con la idea de que la página ha caducado / caducará, y puede ser especialmente útil si la página debe se actualiza por completo cuando el temporizador caduque. Dicho esto, el enfoque adecuado sigue siendo no invalidar nunca la página de inicio de sesión existente.

Siempre ha habido un intercambio entre UI y seguridad. Por lo que sé, los tokens de CSRF en la página de inicio de sesión son para proteger contra ataques de fuerza bruta, que también podrían lograrse por otros medios como la verificación de Captcha. También se puede abusar, si es posible, para hacer que las víctimas inicien sesión en la cuenta del atacante y hagan algunas cosas desagradables, pero supongo que es raro.

Lo mejor, creo, es actualizar el token con uno nuevo automáticamente tan pronto como caduque. La implementación de un token CSRF simple que permanece estático durante un período de tiempo no sirve para nada.