Seguridad de API basada en token sobre repetidas solicitudes de nombre de usuario / contraseña

2

¿Cuáles son los beneficios de seguridad sobre un modelo de seguridad API basado en token en lugar de enviar el nombre de usuario & contraseña cada vez?

El proceso del enfoque basado en token es:

  1. Enviar una solicitud de 'inicio de sesión' con nombre de usuario y contraseña
  2. Recibir un token
  3. Use el token en lugar del nombre de usuario / contraseña para todas las solicitudes posteriores

Los beneficios de un sistema basado en token (según este enlace ) son:

  • Escalabilidad
  • Tecnología débilmente acoplada
  • compatible con dispositivos móviles

Sin embargo, no estoy seguro de por qué estas ventajas son específicas de un enfoque basado en token en lugar de enviar el nombre de usuario / contraseña cada vez. ¿No es tan fácil agregar servidores web posteriores a un clúster de cualquier manera? La verificación de la contraseña todavía se realiza en ambos casos, ¿por lo que el lado del cliente está acoplado de forma tan simple?

¿Ventajas? ¿Es simplemente que el nombre de usuario y la contraseña no necesitan ser 'verificados' cada vez que podemos hacer una búsqueda más simple basada en una lista de claves de sesión? Si bien esta es una mejora del rendimiento, agrega una mayor complejidad en la aplicación cliente, y otras complejidades si hay un tiempo de espera en el token en el que el cliente tendría que verificar si el token sigue siendo válido.

¿Desventajas? ¿Las desventajas con un nombre de usuario / contraseña se envían con cada solicitud que, con más y más transmisiones de estos datos, es más probable que puedan descubrirse? Si es así, ¿no es HTTPS lo suficientemente robusto para contrarrestar esta amenaza?

EDITAR: He leído este duplicado potencial: ¿Por qué usar un token de autenticación en lugar del nombre de usuario / contraseña por solicitud?  pero no estoy muy seguro de por qué el punto # 2 dice que el nombre de usuario / contraseña se almacenará como una cookie. ¿Por qué la máquina cliente mantendría el nombre de usuario / contraseña como una cookie y no la incluiría en el contenido de la publicación?

    
pregunta JLo 20.02.2017 - 11:26
fuente

2 respuestas

1
  

¿Por qué el equipo cliente mantendría el nombre de usuario / contraseña como una cookie y no lo incluiría en el contenido de la publicación?

Manteniendo el nombre de usuario / contraseña (o token para ese asunto) en un contenido de la publicación, localStorage o sessionStorage expone este contenido a un ataque XSS. Consulte este artículo . Aunque el artículo trata sobre un token, el mismo principio se aplica a cualquier credencial (incluido el nombre de usuario / contraseña). Algunas referencias más sobre este aquí . Si almacena dicha información en una cookie httpOnly, el contenido no está disponible para JavaScript y, por lo tanto, teóricamente es inmune a un ataque XSS. Una vez que tiene sus credenciales en una cookie, está abierto a un ataque CSRF y necesita manejarlo.

La respuesta a tu pregunta vinculada es correcta.

Yo agregaría otro beneficio para el token: vencimiento. Si se roban las credenciales de nombre de usuario / contraseña, puede ser difícil detectarlas. Los tokens caducarán en algún momento y el usuario tendrá que volver a iniciar sesión para que se le permita uno nuevo. Esto limita el período de tiempo en el que se puede usar un token robado para autenticarse en el servidor. En el caso de las credenciales de nombre de usuario / contraseña, no existe tal límite o es mayor (la política de caducidad de la contraseña suele ser de un mes o más, donde un token puede configurarse para que caduque en minutos o días)

    
respondido por el Marko Vodopija 21.02.2017 - 17:25
fuente
0

Nombre de usuario / Contraseña

  • No es una buena idea enviar credenciales con cada solicitud de API. A pesar de que está enviando credenciales a través de ssl / tls (¡no proporciona un túnel seguro de extremo a extremo, vulnerabilidades conocidas!), Existen altas posibilidades de que el cliente sea víctima de ataques MITM (nivel de LAN / Wifi, nivel de ISP, nivel de país, nivel de país) .

  • El nombre de usuario (nombre, correo electrónico) / Contraseña (no demasiado complejo) es fácil de adivinar. Definitivamente no querrá que sus usuarios ingresen la contraseña de más de 21 caracteres, ¿verdad? para una mejor experiencia de usuario!

Token Based

  • 1 token (con tiempo de caducidad hasta el cierre de sesión del usuario) es el mismo que el nombre de usuario / contraseña

  • Debe intentar implementar el esquema de token de acceso / actualización de Oauth, JWT o personalizado. Este enfoque en sí mismo no proporcionará más seguridad si lo está implementando incorrectamente.

Con tokens, puede proporcionar a los usuarios una transparencia de administración de sesión más flexible.

Ej: -

  • Matar sesión remota (expirar token!)
  • Renovar sesión actual (renovar el token de acceso a través del token de actualización)
  • Mantenga un registro de todas las sesiones activas
  • El token (Random + length) no es fácil de fuerza bruta.

No hablaré de escalabilidad y otros beneficios aquí. Pero sí, puede escalar su servicio con el enfoque basado en token :-) Abra em up para el consumo de terceros.

    
respondido por el Priyal 20.02.2017 - 16:01
fuente

Lea otras preguntas en las etiquetas