security - sesion - ¿Cómo hacer una autenticación sin estado(sin sesión) y sin cookies?

desactivar verificacion en dos pasos facebook (2)

Bob usa una aplicación web para lograr algo. Y:

Su navegador está en dieta, por lo tanto, no admite cookies .
La aplicación web es popular, trata con muchos usuarios en un momento dado, tiene que escalar bien. Siempre que mantener la sesión imponga un límite al número de conexiones simultáneas , y, por supuesto, traerá una penalización de rendimiento no despreciable, nos gustaría tener un sistema sin sesión :)

Algunas notas importantes:

tenemos seguridad en el transporte ( HTTPS y sus mejores amigos);
detrás de las cortinas, la aplicación web delega muchas operaciones a servicios externos , en nombre del usuario actual (esos sistemas reconocen a Bob como uno de sus usuarios), esto significa que tenemos que reenviar las credenciales de Bob .

Ahora, ¿cómo autenticamos a Bob (en todas y cada una de las solicitudes)? ¿Cuál sería una forma razonable de implementar tal cosa?

jugando al tenis con las credenciales a través de campos ocultos de forma HTML ... el balón contiene las credenciales ( nombre de usuario y contraseña ) y las dos raquetas son el navegador y la aplicación web, respectivamente. En otras palabras, podemos transportar datos hacia adelante y hacia atrás a través de campos de formulario en lugar de a través de cookies. En cada solicitud web, el navegador publica las credenciales. Sin embargo, en el caso de una aplicación de una sola página , esto puede parecer jugar squash contra una pared de goma, en lugar de jugar tenis , ya que el formulario web que contiene las credenciales podría mantenerse vivo toda la vida de la página web (y el servidor se configurará para no ofrecer las credenciales).
almacenar el nombre de usuario y la contraseña en el contexto de la página - variables de JavaScript, etc. Se requiere una sola página aquí, en mi humilde opinión.
autenticación cifrada basada en tokens. En este caso, la acción de inicio de sesión daría lugar a la generación de un token de seguridad cifrado (nombre de usuario + contraseña + algo más). Este token se devolverá al cliente y las próximas solicitudes irán acompañadas del token. ¿Esto tiene sentido? Ya tenemos HTTPS ...
otros...
último recurso: ¡no hagas esto, almacena las credenciales en la sesión! La sesión es buena. Con o sin cookies.

¿Algún problema de seguridad / web viene a su mente, con respecto a cualquiera de las ideas descritas anteriormente? Por ejemplo,

Tiempo de espera : podemos conservar una marca de tiempo , junto con las credenciales (marca de tiempo = la hora en que Bob ingresó sus credenciales). Por ejemplo, cuando NOW - timestamp> threshold , podemos rechazar la solicitud.
Protección de secuencias de comandos entre sitios : no debería ser diferente de ninguna manera, ¿verdad?

Muchas gracias por tomarse el tiempo para leer esto :)

Acerca de la opción de inicio de sesión: creo que generalmente también desea admitir sesiones para los invitados.

Por lo tanto, si desea aplicar el inicio de sesión, la opción del token cifrado podría ser buena. También podría ser bueno para la sesión de invitados. En otra dirección, combinaría entre agregar el token a la URL y la opción de tenis.

Tenga en cuenta que enviar credenciales solo en la URL puede ser peligroso. Por ejemplo, puede filtrar el token a través del encabezado HTTP referer o incluso alguien que solo inspecciona su tráfico o mira su computadora.

Otra cosa, incluso si pudiera usar cookies, le recomendaría agregar token aleatorio o verificador aleatorio, para protegerse de los ataques de falsificación de solicitudes cruzadas (CSRF).

Ah, me encantan estas preguntas: mantener una sesión sin sesión.

He visto varias maneras de hacer esto durante mis períodos durante las evaluaciones de la aplicación. Una de las formas más populares es la forma de jugar al tenis que mencionaste, enviando el nombre de usuario y la contraseña en cada solicitud para autenticar al usuario. Esto, en mi opinión, no es seguro, especialmente si la aplicación no es una sola página. Tampoco es escalable, especialmente si desea agregar una autorización a su aplicación además de la autenticación en el futuro (aunque supongo que también podría crear algo en función de los inicios de sesión).

Un mecanismo popular, aunque no completamente sin estado (suponiendo que tenga ejecución de JavaScript) es incrustar la cookie de sesión en el JavaScript. El tipo de seguridad que hay en mí está gritando, pero en realidad podría funcionar: cada solicitud tiene un encabezado X-Authentication-Token o algo así, y lo mapea en una base de datos, un archivo-store en la memoria, etc. en el backend para validar al usuario Este token puede tener un tiempo de espera de la hora especificada, y si se agota el tiempo, el usuario debe iniciar sesión de nuevo. Es bastante escalable: si lo almacena en una base de datos, se ejecuta una sola instrucción SQL y con los índices correctos, debe tomar muy poco tiempo para ejecutarse, incluso con múltiples usuarios simultáneos. Sin embargo, la prueba de carga aquí definitivamente ayudaría. Si leo la pregunta correctamente, este sería su mecanismo de token cifrado, aunque, le sugiero encarecidamente que utilice un token criptográficamente aleatorio de, por ejemplo, 32 caracteres, frente a una combinación de nombre de usuario + contraseña + lo que sea, de esta manera, se mantiene impredecible, pero aún puede asociarlo con la identificación del usuario o algo así.

Sea lo que sea que termine usando, asegúrese de que se le envíe de manera segura. HTTPS lo protege a través del cable, pero no lo protege si filtra el token de sesión a través de la URL (o peor, las credenciales a través de la URL). Recomendaría usar un encabezado, o si eso no es posible, enviar el token a través de una solicitud POST cada vez (esto significaría un campo de formulario oculto en el navegador del usuario). El último enfoque de usar una solicitud POST debería usar defensas CSRF, solo en caso, aunque sospecho que usar el token en sí mismo podría ser una especie de defensa de CSRF.

Por último, pero no menos importante, asegúrese de tener algún mecanismo en el backend para purgar los tokens vencidos. Esta ha sido la ruina de muchas aplicaciones en el pasado: una base de datos de autenticación cada vez mayor que nunca parece desaparecer. Si necesita admitir varios inicios de sesión de usuario, asegúrese de limitar el número o tener un límite de tiempo más corto para cada token. Como dije antes, la prueba de carga puede ser la respuesta a esto.

Hay otras preocupaciones de seguridad que se me ocurren, pero son demasiado amplias como para abordarlas en esta etapa: si se tienen en cuenta todos los casos de uso (y abuso), probablemente se pueda hacer una implementación bastante buena de este sistema.