HMACs que tienen la misma clave y mensaje

Question

HMACs que tienen la misma clave y mensaje

#1 de CodesInChaos (2 votos)

1

Estoy usando HMACSHA256 para generar el hash de la contraseña y almacenarlo. El objetivo aquí es simplemente autenticar a los usuarios, es decir, guardar sus contraseñas de hash y validar a los usuarios cuando sea necesario utilizando las contraseñas de hash

// salt is a guid we store seperately, its the id of the user
byte[] GetHash(byte[] password, byte[] salt) 
{
    byte[] saltAndPassword = salt.Concat(password).ToArray();

    var hmac = HMACSHA256();  
    hmac.Key = password;
    var hash = hmac.ComputeHash(saltAndPassword);
    return hash;
}

observe que la clave es la contraseña y que el hash se genera en salt + contraseña

¿podemos tener la contraseña como la clave para hash la contraseña de salt +, eso será parte de la seguridad? Al usar HMACSHA256, ¿necesariamente tenemos que tener una administración de claves para poder usar claves separadas en lugar de contraseñas?

también, ¿las claves tienen que ser únicas en HMACSHA256?

Sé que la gente suele sugerir funciones lentas como - PBKDF2, Scrypt, etc.

¿pero es seguro usar HMACSHA256 también? ¿La gente realmente usa un hmac para hashear y almacenar contraseñas? ¿Cuál sería el enfoque recomendado para el hashing y el almacenamiento de contraseñas (si todo lo que tiene son contraseñas y sales únicas)?

disculpas por el desfile de preguntas :) gracias de antemano

Edit

No pude encontrar una manera de comentar ni la pregunta ni la respuesta (stackexchange requiere que tenga un representante de 50). Así que estoy publicando mi comentario aquí:

@CodesInChaos hola, gracias por tu respuesta.

HMAC (contraseña, salt + contraseña)

Esto es tonto pero inofensivo. 1) Utiliza un valor de longitud variable como clave.   HMAC tiene algunas > propiedades extrañas al hacer eso. 2) ¿Por qué introducir el   contraseña dos veces?

Hmm, ¿deberíamos hacer algo al respecto? ¿Para que sea un valor de longitud constante (cualquier recomendación)?

Pienso que el hash (sal + contraseña) siempre es mejor que el hash (contraseña) // ¿el único propósito de salar?

pero por lo que veo en su respuesta, HMACSHA256 hace algo similar con la clave que se suministra.

Si usa HMAC para las contraseñas de hash, yo usaría la contraseña como mensaje y la sal como clave > Esto coincide con HKDF-Extracto.

pero, en nuestro caso, la sal es el ID de usuario, están expuestos, ¿está bien usar la sal como clave que es fácil de conocer?

passwords authentication hash hmac

pregunta user67609 03.02.2015 - 11:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords authentication hash hmac

Mantener las firmas válidas incluso después de que la clave privada haya sido comprometida ¿Cómo se considera que SHA1 y MD5 no protegen contra colisiones?

score 2 · Answer 1

Sé que la gente a menudo sugiere funciones lentas como - PBKDF2, Scrypt, etc.

Escúchalos. Use scrypt, bcrypt o PBKDF2. Estas funciones están diseñadas para la contraseña de hashing. Consulte ¿Cómo hash seguro las contraseñas? para obtener más información. Este es el enfoque recomendado para las contraseñas de hash.

¿pero es seguro usar HMACSHA256 también?

Es rápido = > La fuerza bruta es más barata = > es más débil que un hash lento.

Un hash rápido solo es aceptable si sabes que solo se usarán contraseñas seguras (por ejemplo, más de 80 bits de entropía). En la práctica, esto significa que no permite las contraseñas elegidas por el usuario y las genera utilizando una computadora. En este punto, están más cerca de las claves que de las contraseñas típicas.

¿Las claves tienen que ser únicas en HMACSHA256?

Cuando se usan como MAC, las claves no necesitan ser únicas. Lo estás utilizando como un hash de contraseña, por lo que no hay una clave secreta. Las sales deben ser únicas para evitar ataques de múltiples objetivos, pero las colisiones ocasionales no hacen mucho daño.

// Salt es una guía que almacenamos por separado, es el ID del usuario

Esto significa que la sal se reutilizará cuando el usuario cambie su contraseña. No es ideal, pero tampoco es un gran problema.

HMAC (contraseña, salt + contraseña)

Esto es tonto pero inofensivo. 1) Utiliza un valor de longitud variable como clave. HMAC tiene algunas propiedades extrañas al hacer eso. 2) ¿Por qué introducir la contraseña dos veces?

Si usa HMAC (salt, contraseña) para las contraseñas de hash, yo usaría la contraseña como mensaje y el salt como clave. Esto coincide con HKDF-Extracto.

Hmm, ¿deberíamos hacer algo al respecto? ¿Para que sea un valor de longitud constante (cualquier recomendación)?

Si usa la sal como clave y la contraseña como mensaje, la clave tiene una longitud fija. Pero como estas propiedades no tienen mucho impacto práctico, tampoco se preocupe demasiado si su longitud es variable.

Pensé que el hash (sal + contraseña) siempre es mejor que el hash (contraseña) // ¿el único propósito de la sal?

pero por lo que veo en su respuesta, HMACSHA256 hace algo similar con la clave suministrada.

Dado que HMAC ya combina clave y mensaje, no es necesario que incluyas la contraseña en ambos.

pero, en nuestro caso, la sal es el ID de usuario, están expuestos, ¿está bien usar la sal como clave que es fácil de saber?

Sí, usar una sal pública como entrada clave para HMAC está bien. Debe hacer suposiciones más firmes sobre HMAC que "Es un PRF", pero está bien.