Demystifying Web Authentication

Question

Actualmente estoy investigando los protocolos de autenticación de usuario para un sitio web que estoy desarrollando. Me gustaría crear una cookie de autenticación para que los usuarios puedan permanecer conectados entre páginas.

Aquí es mi primera fiesta:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k) 

Donde k es HMAC(user_id|expiry_date, sk) y sk es una clave de 256 bits que sólo conoce el servidor. HMAC es un hash SHA-256. Tenga en cuenta que '|' es un separador, no solo concatenación.

Esto se parece a esto en PHP:

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY); 
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key); 
$cookie = $user_id . '|' . $expiry_time . '|' . $digest; 

puedo ver que es vulnerable a ataques de repetición como se indica en Un Protocolo de galleta segura, pero debería ser resistente a los ataques de Volumen y criptográfica de empalme.

LA PREGUNTA: ¿Estoy en la línea correcta aquí, o hay una gran vulnerabilidad que me he perdido? ¿Hay alguna manera de defenderse contra los ataques de reproducción que funcionan con direcciones IP asignadas dinámicamente y no usan sesiones?

NOTAS

El material más reciente que he leído:
pros y los de autenticación de cliente en la Web también conocido como Fu et al.
(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

Un Protocolo de la galleta Secure aka Liu et al.
(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)
que se expande en el método anterior

endurecidos sin estado cookies de sesión
(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)
que también se expande en el método anterior.

Como el tema es extremadamente complicado, solo estoy buscando respuestas de expertos en seguridad con experiencia real en la creación y el corte de esquemas de autenticación.

Answer 1

Esto está bien en general, he hecho algo similar en varias aplicaciones. No es más susceptible a los ataques de repetición que las ID de sesión que ya existían. Puede proteger los tokens de las fugas para su reproducción mediante SSL, del mismo modo que lo haría con los identificadores de sesión.

sugerencias menores:

• poner un campo de los datos de usuario que se actualiza el cambio de contraseña (tal vez contra la generación de contraseñas, o incluso sólo la sal al azar), e incluyen ese campo en el token y parte firmada Luego, cuando el usuario cambia sus contraseñas, también invalida cualquier otro token robado. Sin esto, está limitado en cuánto tiempo puede razonablemente permitir que un token viva antes de que expire.

• Ponga un identificador de esquema en el token y la parte con signo, para que (a) pueda tener diferentes tipos de token para diferentes propósitos (por ejemplo, uno para auth y uno para protección XSRF), y (b) puede Actualice el mecanismo con una nueva versión sin tener que invalidar todos los tokens antiguos.

• Asegúrese de que user_id nunca se vuelva a utilizar, para evitar que se use un token para obtener acceso a un recurso diferente con la misma ID.

• Delimitación de tubería supone | nunca aparece en ninguno de los valores de campo. Esto probablemente funciona para los valores numéricos que (presumiblemente) se trata, pero es posible que en algún momento necesite un formato más complicado, por ejemplo, pares de nombre/valor codificados en URL.

• El doble HMAC no parece realmente obtener mucho. Tanto la fuerza bruta como el criptoanálisis contra HMAC-SHA256 ya son increíblemente difíciles según la comprensión actual.

Answer 2

1. A menos que sus transacciones/segundo pondrá a su hardware, que serían solamente pasar un hash de la cookie (es decir, dejar de lado el user_id y EXPIRY_DATE - no tiene sentido dar las malas personas más información de la que absolutamente necesario).

2. Podría hacer algunas suposiciones sobre cuál debería ser la próxima dirección IP dinámica, dada la dirección IP dinámica anterior (no tengo los detalles a mano, ¡ay!). Hashing solo la parte invariable de la dirección IP dinámica ayudaría a verificar al usuario incluso cuando su dirección IP cambie. Esto puede o no funcionar, dada la variedad de esquemas de asignación de direcciones IP.

3. Puede obtener información sobre el sistema y hash que también: en Linux, puede uname -a (pero hay capacidades similares disponibles para otros sistemas operativos). Suficiente información del sistema, y ​​es posible que pueda omitir el uso de la dirección IP (parcial) por completo. Esta técnica requerirá algo de experimentación. Utilizar solo la información del sistema normalmente proporcionada por el navegador lo haría más fácil.

4. Debes pensar en cuánto tiempo tus cookies deben permanecer frescas. Si puede vivir con personas que tienen que autenticarse una vez al día, sería más fácil para la codificación de autenticación del sistema que permitir que las personas se autentiquen solo una vez al mes (y así sucesivamente).

Answer 3

¡Considero que este protocolo es muy débil!

1. su session-cookie no es una fuente aleatoria con alta entropía.
2. El servidor debe hacer un cifrado asimétrico en cada página para verificar a un usuario.
3. La seguridad de CUALQUIER usuario solo depende de la seguridad de la clave del servidor sk.

El servidor de claves SK es la parte más vulnerable aquí. Si alguien puede adivinarlo o robarlo, puede iniciar sesión como un usuario específico.

Entonces, si se genera sk para cada sesión y usuario, ¿por qué el hmac? Creo que usará TLS de todos modos, si no, considere su protocolo como roto debido a los ataques de repetición y las escuchas en general.

Si sk se genera para cada usuario, pero no para cada sesión, es similar a una contraseña de 256 bits.

Si sk es idéntico para todos los usuarios, alguien solo tiene que descifrar 256 bits y puede iniciar sesión como lo desee cualquier usuario. Solo tiene que adivinar la identificación y la fecha de exiración.

Eche un vistazo a digest-authentication. Es una autenticación por solicitud, especificada por el rfc2617. Es seguro para ataques de devolución utilizando nonces, enviado en cada solicitud. Es seguro para escuchas utilizando hash. Está integrado en HTTP.