¿Sería esto un flujo de autenticación seguro?

2

Considere el siguiente flujo de autenticación.

  • El usuario envía su nombre de usuario y una contraseña cifrada RSA
  • La contraseña se descifra y se revisa con una sal (y posiblemente una pimienta) y se verifica
  • Si el hash coincide, se genera un GUID como un token y el token recibe un TTL y una fecha de caducidad y se devuelve al usuario. Además, se guarda la dirección IP de la persona que llama
  • Ese nombre de usuario con el token se usa para cualquier interacción futura con la base de datos (cada vez que se usa el token se extiende su fecha de caducidad). Solo la IP que creó el token puede usar el token.
  • El inicio de sesión desde una nueva IP debe verificarse primero mediante una segunda forma de autenticación (por ejemplo, un código enviado al correo electrónico de los usuarios)

¿Cuáles son las preocupaciones de seguridad de este sistema de autenticación?

Siento que un sistema de este tipo usaría tokens incorrectamente, ya que según lo que he leído, parece que el propósito de los tokens es la autorización y no la autenticación. Siento que el único beneficio de usar el token es que se puede usar una contraseña para iniciar sesión en cualquier momento y el token finalmente caduca, por lo que si caduca, al final será inútil.

Una de mis preocupaciones sería si alguien está constantemente escuchando e interceptando el token, lo que esencialmente significa que podría usarlo para acceder a la base de datos siempre que haya un token activo (y se pueda actualizar indefinidamente un token para mantenerlo activo). Esta es la razón por la que la dirección IP se almacenaría y el acceso solo se otorgaría a esa dirección IP. Esto minimizaría el riesgo de mal uso de la ficha.

En general, un token no puede devolverse cifrado, ¿cómo puede alguien evitar que un token sea interceptado y mal utilizado?

    
pregunta yitzih 21.03.2017 - 15:38
fuente

1 respuesta

2

Un par de cosas que vale la pena mencionar:

  • Cambio de IP: probablemente más a menudo de lo que espera
  • Estás jodido, sin importar qué suceda si alguien es capaz de escuchar
  • Cualquier código ejecutado en el navegador puede omitirse si alguien está escuchando

Lo que estás describiendo es lo que se conoce como token de portador: quien lleve el token tiene el poder del token. Así es exactamente como funcionan la mayoría de los sitios web, excepto que a menudo solo llaman cookies de sesión.

Hay un par de cosas que puedes hacer para proteger este token.

  1. Exigir el uso de HTTPS mediante un certificado de confianza real: todo esto es un ejercicio inútil si no usa HTTPS.
  2. Habilite Seguridad de transporte estricta de HTTP ; esto indicará al navegador que todas las solicitudes al sitio deben estar a través de HTTPS, y por lo tanto, cualquier persona en el medio probablemente se notará debido a un certificado no válido. Sin embargo, esto tiene una eficacia limitada porque un atacante puede quitar el encabezado HSTS antes de que el navegador lo vea.
  3. Considere fijación de clave pública ; esto hará que sea más difícil para alguien usar un certificado confiable pero falso mientras se hace un MiTM. Esto es extremadamente efectivo si está utilizando una aplicación que no es de navegador porque puede controlar la validación del canal.

Si aún te preocupa que alguien intercepte la solicitud, entonces necesitas algo como un certificado de cliente, para poder realizar la autenticación mutua. Esto garantizará la protección contra la intercepción porque el intercambio de claves puede solo ocurrir entre partes confiables.

    
respondido por el Steve 21.03.2017 - 16:04
fuente

Lea otras preguntas en las etiquetas