¿Está mejorando el token de autenticación de la API REST sin estado o lo abandona por la persistencia de la base de datos?

Question

¿Está mejorando el token de autenticación de la API REST sin estado o lo abandona por la persistencia de la base de datos?

#1 de Mladen B. (1 votos)
#2 de David (0 votos)

1

Estoy buscando implementar la autenticación REST sin estado en una API. He estado leyendo sobre artículos aquí, y he implementado una idea que funciona, pero esperaba obtener alguna información sobre su seguridad y posibles mejoras.

La autenticación inicial ocurre a través de la Autenticación básica HTTPS. El nombre de usuario y la contraseña se proporcionan en texto simple.
El servidor genera y proporciona un token que se proporciona al cliente, pero no se almacena en la base de datos. Todos los artículos que he leído en tokens de autenticación sugieren que no se almacene el token en sí mismo , sino algún valor que se pueda incluir en otro valor (el nombre de usuario, etc.) para generar el token nuevamente y validarlo, pero pensó que el punto de una API REST era no tener estado, y no almacenaría algún tokens / valores relacionados con la autenticación?
Este token se usa para solicitudes posteriores en lugar de requerir siempre el nombre de usuario / contraseña en los encabezados.

El token

El token se genera mediante:

encrypt(username, salt, hash, expirationDate)

Donde encrypt es reversible usando actualmente un DES Cipher , pero en el futuro posiblemente una clave privada o un recurso almacenado en el servidor que se pueda reemplazar fácilmente sin depender de un valor en el código fuente .

El beneficio es que esto le permite al servidor descifrar el token entrante y comparar el salt / hash con lo que está almacenado en el objeto del modelo User . (Que tiene las propiedades salt y hash almacenadas en la base de datos).

Las preocupaciones que tengo con esto:

Si se conocen la clave privada o la contraseña Cipher , estos tokens se pueden falsificar.
He considerado usar password en lugar de salt y hash , pero no me gustó la idea de que se conoce password si se encuentra la clave privada o la contraseña Cipher .

Entonces: ¿Hay una mejor manera de realizar este tipo de autenticación de token "descifrable"? Y, ¿vale la pena mantener este objetivo "sin estado" de REST, o debería simplemente almacenar alguna versión con hash del token y nombre de usuario (pero no el token en sí mismo) en la base de datos y lanzar el "sin estado ¿"idea fuera de la ventana"?

authentication encryption rest

pregunta Craig Otis 05.10.2014 - 01:36

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication encryption rest

¿Se puede usar shellshock en un sistema con páginas web públicas pero acceso restringido al servidor? Varias personas tienen la misma dirección IP del iPhone

score 1 · Answer 1

Creo que entendiste mal la restricción "sin estado" de REST. De lo que estaba escrito en Dr. La disertación de Fielding , se puede dar una impresión errónea de que sin estado significa que no se debe guardar (del lado del servidor) cualquier información sobre el cliente, lo cual es incorrecto. Lo que se quería decir era que el servidor no debía guardar nada relacionado con la sesión del cliente (estado del cliente, que puede cambiar durante su servicio), que es una cosa diferente.

Por ejemplo, si su servicio web debe admitir a múltiples usuarios, debe mantener la información sobre sus usuarios, junto con sus credenciales, para que pueda validar cada solicitud y confirmar que proviene de un usuario válido de su sistema.

Lo que no debes mantener es el estado en el que se encuentra un usuario, mientras usas tu servicio. Eche un vistazo a esta frase de la disertación:

La escalabilidad se mejora porque no tiene que almacenar el estado entre las solicitudes permiten que el componente del servidor libere rápidamente recursos, y Simplifica aún más la implementación porque el servidor no tiene que administrar el uso de recursos en todas las solicitudes.

Entonces, si almacena el estado de sus clientes en su máquina de servicio, sus límites de almacenamiento pueden alcanzarse rápidamente, con cada nuevo usuario agregado al sistema, sin mencionar el escenario en el que un solo usuario puede tener múltiples solicitudes concurrentes y Tienes que administrar los recursos en cada una de esas solicitudes. Además, si una de sus máquinas de servicio falla, cualquier otra máquina de servicio disponible no podrá simplemente tomar el control de ese cliente y continuar prestándole servicio, ya que el estado de ese cliente, que se mantuvo en la máquina de servicio fallida, se pierde .

En pocas palabras, realmente no necesita sesiones para los servicios REST. Solo asegúrese de que su comunicación sea segura (HTTPS) y puede enviar la información de autenticación básica con cada solicitud. Si está realmente preocupado por la seguridad, intente usar hmac o auth o incluso el certificado por cliente. Pero asegúrese de no almacenar ninguna sesión en sus máquinas de servicio.

Tenga en cuenta que esto no significa que no pueda usar servicios de autenticación externos, que no necesitan ser REST, como los servidores de inicio de sesión único.

score 0 · Answer 2

Esperamos que te refieras a 3DES, ¿o tal vez DES fue un error tipográfico y te refieres a AES? Solo DES puede ser fácilmente roto en estos días.

De todos modos, ¿por qué necesitas que sea descifrable? Un patrón razonable para generar un token de autenticación sería algo así como este pseudocódigo:

raw_token = userid + ':' + expiration_time
sig = HMAC(raw_token, service_key)
token = raw_token + ':' + sig

Luego, cuando se recibe una solicitud, puede verificar el token dividiendo la firma, volviendo a calcular y verificando el HMAC y luego verificando que no haya transcurrido el tiempo de caducidad.

Sí, al igual que usted describe, esto tiene la propiedad de que si la clave se conoce, es posible falsificar tokens. Esto sería inherente a cualquier sistema que use tokens criptográficos para la autenticación, y la única alternativa es el patrón "generar un token aleatorio y almacenarlo también en el lado del servidor".