Esquema del token de autenticación / inicio de sesión

4

Según esta respuesta, un esquema de token de inicio de sesión válido consistiría en

  1. el nombre de usuario (U)
  2. el tiempo de emisión (T) y
  3. clave secreta K propiedad del servidor solamente

La sugerencia es concatenar los valores de la siguiente manera:

token = U + T + hmac ("sha256", U + T, K)

¿Esto significa que el servidor tendría que dividir el token para validarlo, tomar el nombre de usuario y la hora, reconstruir el hash (con la misma clave) y luego comparar el hash de compilación nuevo con el hash proporcionado en el token? ¿No es un problema enviar el nombre de usuario y la hora en texto sin formato? ¿No tendría más sentido cifrar el ID de usuario y el tiempo también (y descifrarlo para validar el token)?

    
pregunta zersaegen 30.07.2014 - 13:31
fuente

1 respuesta

4

Di, eres el usuario "bob". Inicia sesión con tu contraseña el 2014-07-30H12: 00: 00 y el servidor, usando tu esquema, establece tu token de cookie en:

enc("bob", K)+enc("2014-07-30H12:00:00", K)

Sin embargo, Bob es malicioso. Mientras su jefe, Alice, está lejos de su escritorio, él revisa las cookies de su navegador y descubre su token:

enc("alice", K)+enc("2014-07-30H13:00:00", K)

Bob no necesita saber la clave secreta K en el servidor, ya que el valor de enc("alice", K) nunca cambia, por lo que todo lo que necesita hacer para evitar ser "alice" de usuario en cualquier momento en el futuro es para cambiar su propia cookie para reemplazar la salida de enc("bob", K) con la salida de enc("alice", K) .

El esquema con el hmac sugerido anteriormente no es vulnerable a este ataque. El token devuelto del servidor es algo como esto:

bob$2014-07-30H12:00:00$b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c

Bob puede intentar cambiar "bob" a "alice", pero cuando el servidor realiza el cálculo de validación, el hash sha256 calculado no coincidirá, y será obvio que el nombre de usuario o la marca de tiempo se han alterado. Bob no puede calcular el hash, ya que no conoce la clave secreta utilizada por el servidor.

La operación de validación de split() y hmac() son extremadamente rápidas y requieren microsegundos. Probablemente serán más rápidos que descifrar los tokens. Obviamente, estarías enviando el token a través de un canal seguro, como a través de https usando una cookie segura, por lo que no es necesario cifrar adicionalmente el nombre de usuario y la marca de tiempo además de hmac.

Editado para agregar:

Incluso si usas lo siguiente:

enc("bob"+"$"+"2014-07-30H12:00:00", K)

Esto todavía no es lo suficientemente bueno. Obtener el cifrado justo es extremadamente difícil y es probable que haya problemas en su implementación (todos los tokens emitidos para "alice" empezarán de la misma manera a menos que haga lo correcto con aleatoriedad e inicialización). Dado que el atacante sabrá tanto el texto plano como el criptotexto, hay varios ataques que pueden intentar averiguar cuál es el valor de K, a menos que use el algoritmo correcto con los parámetros de inicialización correctos.

Además, todos los criptogramas buenos siempre incorporan hmac para verificar la integridad de todos modos , por lo que al intentar simplificar el proceso, terminará debilitándolo o haciéndolo más complicado y computacional intensivo.

Simplemente apégate a la recomendación username+timestamp+hmac(sha256, username+timestamp, K) y transfiérelo al cliente a través de un canal seguro. Es un esquema que sabe que funciona bien.

    
respondido por el mricon 30.07.2014 - 15:51
fuente

Lea otras preguntas en las etiquetas