Tengo una situación en la que no puedo usar una sesión del lado del servidor, pero debo permitir que los usuarios inicien sesión y que su estado de inicio de sesión sea persistente entre consultas.
Al igual que con cualquier cosa que involucre criptografía de cualquier tipo, sé lo fácil que es cometer un error y solo quería un par de ojos extra para ver lo que estoy proponiendo.
u = the unique, numerical user id
s = a global server-side secret composed of a long, random, alpha-numeric string, 64 characters or more
Al iniciar sesión, propongo establecer dos cookies en el cliente.
- El ID de usuario: u
- El token de autenticación: hash (u + s)
En las solicitudes posteriores, el servidor utilizará el valor dado de u y el valor secreto conocido de s para calcular y comparar con el token de autenticación dado. Si coinciden, este debe ser un usuario válido, ¿no?
Un atacante no puede generar un token de autenticación sin conocer el secreto y, por lo tanto, no puede generar un token para la cuenta de usuario de otra persona.
Si las cookies sean relativamente de corta duración, quizás una hora, y proporcione la función de cierre de sesión que destruye las cookies, incluso las computadoras compartidas serían relativamente seguras.
El secreto global s se podría cambiar (quizás por un trabajo cron diario) para proteger contra una fuerza bruta a largo plazo en un par de hash / ID de usuario conocido.
¿Esto suena bien?
Editar:
Al leer eso nuevamente, me doy cuenta de que la introducción de una marca de tiempo sería muy útil. Por lo tanto, una tercera cookie con la marca de tiempo y el hash necesitaría incluir la marca de tiempo, el ID de usuario y el secreto. Entonces, podría establecerse un TTL en el token de autenticación, y la caducidad de la cookie (que de todos modos no es un método de revocación seguro de forma remota) ya no tendrá importancia.