Implementando un token sin estado personalizado

2

Normalmente, usaría JWT cuando se requiere autenticación sin estado, pero estaba pensando en un sistema de token simple. Lo que creará un token mientras autentica a un usuario y luego lo almacena en una tabla SQL con cargas útiles adicionales y fecha de caducidad.

Las cargas útiles incluirán la identificación del usuario y otras informaciones según sea necesario.

Entonces, cuando necesito validar un token, simplemente consultaría en la tabla y verificaría si existe y si está vencido o no.

Eso parece estar bien, pero tengo una pregunta aquí, es decir, si de alguna forma la base de datos está expuesta a un pirata informático, el pirata informático podrá acceder a la cuenta de cada usuario utilizando su token.

Ahora mi pregunta es, ¿qué pasos necesarios podrían tomarse para que esto se pueda prevenir? ¿O es una idea super mala?

    
pregunta rakibtg 31.05.2018 - 21:50
fuente

1 respuesta

3

El patrón básico que describe es básicamente la forma más sencilla de crear un sistema de administración de sesiones con estado. Sus usuarios obtendrían un token de sesión opaco (una cadena aleatoria segura de al menos 128 bits de longitud), generalmente establecido en una cookie de marca segura. Por lo general, luego tendrá una tabla que almacena Sesiones activas, con el token de sesión como la clave principal y las claves externas apuntando a su tabla de Usuarios (más cualquier metadato necesario, como los datos de caducidad de la sesión; de distancia cuando se supone que debe). Esto es, por supuesto, asumiendo que no solo puede almacenar las sesiones en la memoria (quizás son muy longevas, o necesitan ser almacenadas en servidores), y tiene un impacto sustancial en el rendimiento (muchas llamadas de base de datos), por lo general utilizarías mucho caché.

Si desea usar este modelo pero evita que un atacante que lea con éxito su tabla de Sesión se haga pasar por las sesiones activas, puede hacerlo ejecutando cada Token a través de una función hash (como SHA-256 *) antes de almacenarlo. La base de datos (o buscándola en la base de datos). Eso hace que sea posible verificar rápidamente un token determinado en la base de datos, pero hace que sea prácticamente imposible pasar de ver la base de datos a conocer los tokens válidos.

* Está bien usar un hash rápido aquí (a diferencia de las contraseñas), porque la cadena de entrada ya es una entropía demasiado alta para que un atacante la busque por fuerza bruta. De manera similar, no necesita sal (aunque agregar uno no dañará nada excepto algún rendimiento) porque 2 ^ 128 es un número demasiado grande para una tabla de arco iris.

    
respondido por el CBHacking 31.05.2018 - 22:01
fuente

Lea otras preguntas en las etiquetas