hashed nombre de usuario y contraseña en ¿Recordarme token?

6

MVC Framework Symfony utiliza el siguiente método para crear una cookie recordarme:

/**
 * Generates a hash for the cookie to ensure it is not being tempered with.
 *
 * @param string $class
 * @param string $username The username
 * @param int    $expires  The Unix timestamp when the cookie expires
 * @param string $password The encoded password
 *
 * @return string
 */
protected function generateCookieHash($class, $username, $expires, $password)
{
    return hash_hmac('sha256', $class.$username.$expires.$password, $this->getKey());
}

Entonces, usan una cadena de la clase de usuario, seguida del nombre de usuario, luego una marca de tiempo y luego la contraseña del usuario. Se sala con una clave que nunca cambia y es igual para todos los usuarios en todo el sistema.

Ahora aquí está mi problema con esto: ¿Por qué poner la contraseña en la cookie? Aunque es la contraseña con hash y salada (con otra sal, única para cada usuario), ¿no es un riesgo innecesario?

¿O estoy siendo paranoico aquí?

Además, con ese hash, parece que lo único único es la marca de tiempo de caducidad. Parece que sería posible copiar algunas cookies antiguas y crear una nueva para un ataque de repetición, ¿no?

Actualizar

La cookie resultante está codificada en base64 y su contenido decodificado es:

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

El primer elemento es la clase de usuario. El Segundo Parámetro debería ser el nombre de usuario codificado en base64, pero esto es lo que obtengo, así que supongo que es el ID de usuario. Intentaré descubrir cómo funciona eso también. El tercer parámetro es la marca de tiempo "caduca", por lo que ni siquiera tiene que adivinar eso. El cuarto parámetro es dicho hash de cookie.

    
pregunta Andresch Serj 01.08.2016 - 11:18
fuente

3 respuestas

2

Este mecanismo es para que cuando el usuario cambie su contraseña, todas las sesiones de "recordarme" se invaliden.

Las dos características clave de este mecanismo con respecto a la seguridad son:

  • Que la contraseña no se puede determinar a partir del hash en la cookie, si el atacante logra acceder a la cookie de alguna manera.
  • Que el atacante no puede recrear la cookie "recordarme" usando otros datos para obtener acceso desde otra máquina.

A primera vista, porque la cookie contiene un hash de la contraseña

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

puede parecer que un atacante podría violar la fuerza bruta o "adivinar la contraseña" para averiguar si una contraseña probada genera el mismo hash (4to parámetro arriba). Sin embargo, como se trata de un hash con clave (HMAC en este caso), el atacante no tendrá la clave para ejecutar dicho ataque en el valor de la cookie.

Con respecto al segundo punto, esto también es difícil de lograr para un atacante por las mismas razones. Como la clave del hash es desconocida, será casi imposible que un atacante vuelva a crear la cookie "recordarme" incluso si se conocen el ID de usuario, la clase y la caducidad.

    
respondido por el SilverlightFox 02.08.2016 - 09:24
fuente
1
  

...   Ahora aquí está mi problema con esto: ¿Por qué poner la contraseña en la cookie? Aunque es la contraseña con hash y salada (con otra sal, única para cada usuario), ¿no es un riesgo innecesario?

La evaluación de riesgos se realiza caso por caso, por lo que no podemos decir si es aceptable o no sin más detalles sobre dónde se está utilizando (y eso no es una pregunta para EE).

Como se señaló en la razón por la cual la contraseña actual (en cualquier forma) es parte del token de hash utilizado para agregar entropía y vincular la contraseña con el token.

Por lo tanto, un token similar para una contraseña diferente no funcionará. Esto permite que el sistema "cierre la sesión automáticamente" a cualquier persona cuando cambie la contraseña, sin hacer explícitamente un cierre de sesión y rastrear todos los tokens de "recordarme".

La contraseña en sí debe estar en su forma de hash (posiblemente con sal), ya que nunca debemos almacenar contraseñas que no se hayan roto.

  

¿O estoy siendo paranoico aquí?

Sí, pero ¿es eso algo malo? ... ¿Qué dicen las voces?

  

Además, con ese hash, parece que lo único único es la marca de tiempo de caducidad. Parece que sería posible copiar algunas cookies antiguas y crear una nueva para un ataque de repetición, ¿no?

Bueno, no. como atacante, necesitaría el nombre de usuario y la contraseña para recrear un hash para obtener un token de ataque "válido". tiene mayores problemas si el atacante tiene el nombre de usuario y la contraseña.

    
respondido por el LvB 01.08.2016 - 13:41
fuente
0

La única razón que puedo ver para agregar el parámetro de contraseña en el hash generado, es que cuando el usuario cambia su contraseña, las otras sesiones persistentes en otras computadoras se terminarán automáticamente. Esta también es una buena práctica para forzar la autenticación con una nueva contraseña.

    
respondido por el elsadek 01.08.2016 - 12:13
fuente

Lea otras preguntas en las etiquetas