No entiendo qué tiene de malo el uso de cookies para la autenticación.

9

Estoy escribiendo un servidor de aplicaciones y hay una opción para usar cookies seguras para la autenticación. Así es como parece funcionar:

  1. Usted define una clave secreta de 32 bytes en el servidor
  2. Cuando el usuario inicia sesión, verifica la base de datos para ver si los hash de bcrypt coinciden, y si es así, llama a request.remember(user_id)
  3. En los controladores de ruta que requieren autenticación (y el ID de usuario), desenvuelve el ID de usuario descifrando la cookie y, si es válida, continuará. De lo contrario, devuelve un error Unauthorized .
  4. Si un usuario golpea el controlador de cierre de sesión, solo llamo request.forget() y la cookie se elimina en el cliente.

Todo esto parece funcionar. Entonces, lo que siento curiosidad es ¿por qué no todos hacen esto? Miro a mi alrededor y parece que se habla mucho de JWTs, generando UUID de token de autenticación y almacenándolos en Redis / la base de datos, etc. Entonces, ¿parece que este método no es seguro? ¿Y necesitas almacenar el estado en el servidor?

Si tuviera que adivinar, diría que un problema con este enfoque podría ser que si la cookie se roba de alguna manera (no estoy seguro de cómo se trata de TLS y las cookies son solo de HTTP y seguras si eso importa), entonces el usuario podría ser suplantado por un atacante. Pero creo que esto también se aplicaría a los otros esquemas?

Otro problema que podría ver es que un usuario podría generar aleatoriamente tokens de autenticación hasta que encuentre uno que coincida con un usuario. Pero tampoco estoy seguro de si esto es un problema, ya que me limité a limitar el controlador de autenticación y me imagino que este tipo de cosas llevaría un tiempo. Oh, tal vez podrían hacer 100 cuentas y ver qué aspecto tenía el token de autenticación de cookie cifrado y aplicar fuerza bruta al cliente para averiguar cuál era la clave secreta en el servidor. ¿Y entonces podrían hacerse pasar por usuarios generando tokens de autenticación? Aunque creo que llevaría demasiado tiempo encontrar la clave, ya que tiene 32 bytes.

Supongo que este enfoque no hace que las cookies expiren automáticamente (¿es por eso que no se usa mucho? Pero creo que hay una manera de agregar un encabezado de expiración a las cookies? ¿Eso funcionaría?) Ni siquiera estoy seguro de si Necesito la caducidad de esta aplicación ... Parece que molestaría a los usuarios. ¿Cuánto tiempo duran las sesiones en lugares como Google / Facebook? Siento que siempre he iniciado sesión en esos servicios para siempre.

No lo sé. Siento que me estoy perdiendo mucha información aquí. ¿Hay algún lugar donde pueda encontrar una lista de pros y contras de todos estos enfoques diferentes?

    
pregunta Chron Bag 16.10.2018 - 00:33
fuente

3 respuestas

4

El esquema que describe es potencialmente vulnerable a la falsificación de solicitudes entre sitios (CSRF).

Se podría realizar una solicitud maliciosa en nombre del usuario. Esta solicitud enviaría la cookie que pasaría las comprobaciones de autenticación y realizaría cualquier actividad que el propio usuario pudiera realizar.

enlace

Si observa el enlace anterior al artículo de OWASP en CSRF, enumera específicamente las cookies secretas como una técnica de mitigación no válida.

    
respondido por el Daisetsu 16.10.2018 - 00:56
fuente
3

Suponiendo que está utilizando sus cookies como un identificador de autenticación sin estado, su esquema es básicamente similar al JWT, excepto que se crea con cookies. Las principales diferencias son:

  1. Los JWT generalmente solo están firmados en lugar de encriptados (aunque también puede cifrarlos). Lo que esto significa es que puedes solicitar a servicios de terceros que creen tokens para ti. Esto le permite conectar su aplicación a otros servicios de autenticación o proporcionar un servicio de autenticación para otras aplicaciones.
  2. Las aplicaciones nativas móviles y las cookies pueden crear problemas. Generalmente se puede superar, pero la implementación puede ser mucho más complicada que usar tokens, que solo deben adjuntarse como texto a un encabezado o cuerpo de solicitud y se almacenan fácilmente.
  3. Es más fácil trabajar con JWT, especialmente en entornos de javascript, ya que puedes adjuntar cualquier metadata que quieras a los reclamos y puedes leerlos como lo harías normalmente con JSON. También ayuda a que con su popularidad pueda encontrar soluciones listas para usar para más de los marcos modernos.
  4. Las cookies son vulnerables a la falsificación de solicitudes entre sitios (CSRF), mientras que los tokens dependerán de cómo los almacene (secuencias de comandos entre sitios (XSS) si está en el almacenamiento web, CSRF si decide usar una cookie de almacenamiento).

En resumen, lo que estás sugiriendo es sólido, pero básicamente es lo mismo que a JWT le faltan algunos de los beneficios. Si su sistema no necesita la integración de un tercero, vaya con las cookies, pero asegúrese de protegerlas contra CSRF como lo menciona @Daisetsu.

    
respondido por el AlphaD 16.10.2018 - 06:33
fuente
0

En su mayoría tienes razón. La cookie está encriptada, por lo que el contenido no se puede ver ni alterar. (A menos que se rompa el cifrado). La cookie se envía solo a través de TLS, por lo que no puede ser robada por un MITM. (A menos que su certificado esté comprometido de alguna manera). La cookie está configurada en HTTP-Only, por lo que no puede ser robada por ningún JS malicioso. Desde todos los ángulos que tienen sentido, es seguro.

Tengo una queja con su configuración. Estás utilizando un identificador persistente para el usuario en esa cookie. En el improbable caso de que algo salga mal, el compromiso durará toda la vida útil de su registro de usuario. Genere una cadena aleatoria, guárdela en algún lugar y úsela para hacer referencia a su usuario. De esa manera, está reciclando constantemente lo que identificaría a un usuario, lo que supondría una violación de la duración de la sesión.

Considera también abrir marcos populares y estudiar cómo manejan esto. Puede elegir algunas técnicas útiles para hacer las cosas aún más seguras o eficientes.

En cuanto a JWT y similares, existe una combinación de ellos: el nuevo brillo que la gente quiere usar y una técnica realmente útil para que la autenticación exista en un sistema diferente al que el usuario necesita para autenticar.

Edit: Hice un poco de buceo en Laravel para ver cómo lo hacen. Simplemente almacenan el ID de usuario en la sesión. La sesión es del lado del servidor y por lo tanto segura. Esto lo separa del manejo de la sesión, lo que parece apropiado. El identificador de sesión es una cadena aleatoria de 40 caracteres. Eso se establece como solo HTTP.

    
respondido por el Wika 20.10.2018 - 17:10
fuente

Lea otras preguntas en las etiquetas