¿Es seguro usar HMAC con una clave pública con el fin de utilizar la sal?

El nombre de usuario (o la identificación del usuario) no es una sal adecuada. Las sales deben ser únicas para cada combinación de nombre de usuario y contraseña, lo que significa que si el usuario cambia la contraseña, la sal también debería cambiar

Las sales deben generarse aleatoriamente al cambiar la contraseña (o cuando el usuario se registra), por ejemplo, leyendo desde /dev/random o alguna función que genere números aleatorios criptográficos. Sobre la longitud de la sal, debe ser lo suficientemente larga para asegurar que nunca se repita

Respuesta corta

No. Consulte: No haga rodar su propia seguridad .

Respuesta pedante

Has mezclado varios términos.

No es un HMAC si la clave es pública

Un HMAC requiere una clave secreta (a veces llamada pimienta) en lugar de una sal, que es pública . De lo contrario no es un HMAC; es solo un hash.

Un uso común de un HMAC es crear una huella digital a prueba de manipulaciones para proporcionar integridad al mensaje. No se utiliza para el almacenamiento de contraseñas.

No creas que estás hablando de un ataque de diccionario

El propósito de usar un hash con sal para almacenar una contraseña no es para mitigar los ataques de diccionario. El propósito es frustrar los ataques que utilizan una tabla de arco iris . La sal no afecta un ataque de diccionario puro; la única mitigación es usar una contraseña que no esté en el diccionario, por ejemplo, al requerir caracteres especiales o contraseñas más largas.

Creo que estás preguntando ...

Creo que podría estar preguntando "¿Está bien utilizar un algoritmo HMAC con una clave pública (en lugar de una función de hashing de contraseña adecuada, como BCrypt ) para almacenar un hash de contraseña?" En ese caso, la respuesta sigue siendo NO . Debe usar los algoritmos de hashing de contraseñas, no otros algoritmos de hashing , para la contraseña Hash, porque tienen características específicas del problema. Por ejemplo, son deliberadamente lentos y / o proporcionan parámetros que le permiten especificar el número de iteraciones requeridas, lo que aumenta la potencia de cómputo requerida para los ataques de diccionario y puede hacerlos mucho más difíciles en comparación con los hashes ordinarios que funcionan con una sola pasada.

¿Está bien usar la ID de usuario como un salt?

Lo siento, no. Causa algunos problemas:

1. Crea un problema si el usuario alguna vez cambia su ID (se debe volver a calcular el hash)
2. Es posible que la ID de usuario no sea lo suficientemente larga como para impedir los ataques
3. El mismo ID de usuario se puede usar para diferentes servicios, lo que facilita al pirata informático saber si también se usó la misma contraseña
4. Hacker podría componer un conjunto de tablas arco iris basadas en una lista de ID de usuarios comunes.

También, vea este artículo decente sobre el tema , que dice:

  

Una buena regla general es usar una sal que tenga el mismo tamaño que la salida de la función hash. Por ejemplo, la salida de SHA256 es de 256 bits (32 bytes), por lo que la sal debe ser de al menos 32 bytes aleatorios.

Es muy inseguro. Su uso propuesto de HMAC, desde un punto de vista de seguridad, es idéntico al el experimento en este video : casi trivial romper en la práctica.

Además de eso, usar el nombre de usuario como una sal es un problema, aunque sea menor. Significa que la misma combinación de nombre de usuario y contraseña en dos sitios diferentes produce la misma etiqueta de verificación, lo que le permite a alguien que obtiene las bases de datos de contraseñas saber que este usuario reutiliza las contraseñas en todos los sitios. Esta es una de las razones por las cuales las sales aleatorias son probablemente las mejores.

Esa es la pregunta incorrecta. Usted está inventando su propio esquema de almacenamiento de contraseña segura. Debes detenerte inmediatamente. Use un buen método vetado como argon2, scrypt, bcrypt o, en el peor de los casos, pbkdf2 con los parámetros ajustados para tomar tanto tiempo de CPU como RAM que pueda pagar y mantenerse al día con las solicitudes.

NO, NO ES SEGURO

Esta respuesta es para resumir los hallazgos de los otros que contribuyeron aquí.

1. HMAC no está diseñado para ser un algoritmo de hash de contraseña . A pesar del hecho de que el algoritmo es muy similar a cómo Linux calcula hashes De las contraseñas en el archivo / etc / shadow , HMAC solo realiza una iteración, mientras que Linux hace cientos o miles de iteraciones, por lo tanto, HMAC carece del requisito de lentitud . Consulte la pregunta de referencia sobre el hashing de contraseñas
2. Use bcrypt u otro algoritmo de hashing de contraseña específico, con un número considerable de iteraciones y suficiente sal.
3. La sal debe tener al menos el tamaño del tamaño del bloque de funciones hash subyacentes
4. El ID de usuario no es una buena sal.
5. La sal se debe cambiar cada vez que se cambie la contraseña.

NO

No hagas esto, es una tontería que todos tengan acceso a la parte pública de un par de claves asimétricas. Esa es la idea.

Nunca se debe revelar una sal a nadie, o puedes usar una tabla RAINBOW para romperla. SHA-1 se cae de esta manera muy fácil.

enlace