¿Es una buena práctica almacenar información sobre una subclave dentro de un hash?

Question

¿Es una buena práctica almacenar información sobre una subclave dentro de un hash?

#1 de Maarten Bodewes (2 votos)

1

Recientemente escribí una pequeña biblioteca de javascript que te permite verificar los hashes de contraseña del servidor de identidad en nodeJS. Mientras realizaba la investigación, aprendí que el tipo de hash, las iteraciones y la longitud de sal se codifican agregando bytes adicionales al hash final que se proporciona en base64 posteriormente.

Específicamente, el orden es siempre el mismo y al leer los 25 bytes iniciales de datos, aprende todo sobre cómo se codificó la subclave. Aquí hay un ejemplo que incluye el ejemplo de inserción.

this.writeNetworkByteOrder(outputBytes, 1, 1);
this.writeNetworkByteOrder(outputBytes, 5, 10000);
this.writeNetworkByteOrder(outputBytes, 9, salt.length);

function() writeNetworkByteOrder(buffer, offset, value){
            buffer[offset + 0] = value >> 0;
            buffer[offset + 1] = value >> 8;
            buffer[offset + 2] = value >> 16;
            buffer[offset + 3] = value >> 24;
}

¿Es esta práctica común? ¿Debo intentar evitar el uso de la contraseña predeterminada que se proporciona con el servidor de identidad? ¿Cuánto se da al conocer esta información?

Por qué esto no es un duplicado

Mi pregunta es específicamente sobre la codificación que ocurre en el hash resultante. Este es el hash base64 que es el resultado de la operación del servidor de identidad. Siempre que sepa que el hash es base64 puede leer fácilmente el tipo de cifrado, las iteraciones y la longitud de sal directamente desde él. Quiero saber cómo o si esto es seguro y si se considera una buena práctica de seguridad.

passwords authentication hash cryptography

pregunta li x 17.04.2018 - 17:06

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords authentication hash cryptography

¿Por qué TLS no firma ciphersuite? ¿Cómo se puede encontrar una cadena cuyo hash MD5 tiene un prefijo específico?

score 2 · Accepted Answer

TL; DR sí, cuando se trata de proteger la contraseña en el servidor, es seguro almacenar los parámetros de configuración, como el recuento de iteraciones y el tamaño de sal / sal en el servidor. Como se mencionó en la sesión de chat, es común hacerlo, por ejemplo. bcrypt, utilizando un formato de texto diferente.

La pregunta es si es seguro almacenar los parámetros de configuración del algoritmo, no solo el algoritmo. Y sí, esto es seguro. Los parámetros de configuración no proporcionan ninguna información sobre la contraseña utilizada, por lo que almacenarlos con el salt (y posiblemente el hash de contraseña, para la verificación de la contraseña) no filtra ninguna información confidencial a un atacante.

Y al igual que el principio de Kerckhoffs se aplica al algoritmo, también es válido para este tipo de parámetros de configuración . Afortunadamente, si se cambian estos parámetros, la verificación de la contraseña simplemente fallará.

La codificación

Base 64 no desempeña un papel en la determinación de la seguridad, por lo que queda fuera de esta respuesta.

Para otras funciones / parámetros de configuración, el parámetro puede necesitar protección adicional. Por ejemplo, el tamaño de una etiqueta de autenticación en cifrado autenticado (o HMAC simple) no debe ser alterado por un adversario. Esto podría ser un problema en la negociación del protocolo.

Del mismo modo, si la cuenta de iteración / factor de trabajo se comunica a un cliente (para descarga parcial de la obra, por ejemplo), es posible que desee proteger la cuenta de iteraciones contra el cambio. Pero este tipo de parámetros generalmente solo están disponibles en el servidor y las contraseñas / hashes que se envían generalmente están protegidas por una conexión TLS que debería estar usando .

Personalmente prefiero simplemente almacenar una única versión en lugar de los parámetros explícitos. Los parámetros son específicos de una versión (codificada), por lo que no tengo que analizar / validar ninguna información que no sea la versión. Esto es menos dinámico que almacenarlos por separado, pero a menudo la complejidad es tanto un problema como la rigidez.