que - salt hash password c#

Sal y hash, ¿por qué no usar el nombre de usuario?

Question

Debo confesar que soy en gran parte ignorante en la mayoría de los problemas de seguridad de alta tecnología relevantes para las aplicaciones web, pero hay una cosa que al menos pensé que podía hacer porque es una pregunta directa con (con suerte) una respuesta concreta.

Tome este sitio web: http://www.15seconds.com/issue/000217.htm

Se nota un poco que almacenan el valor de sal en la tabla, entiendo los principios y las matemáticas detrás de usar una sal, pero me pregunto esto:

• ¿Por qué no solo usaron el nombre de usuario como un valor de sal en lugar de generar uno?

Answer 1

Debido a que los nombres de usuario tienen una entropía menor que una sal aleatoria, por lo que distribuyen sus valores hash menos de lo que lo hace una sal adecuada.

No es que el ejemplo en esa página sea muy espectacular de todos modos. Siempre acabo de generar un GUID y usar eso.

Sospecho que todo se reduce en lo que respecta a la seguridad de la vida real, e incluso cantidades bastante pequeñas de sal por usuario marcan una gran diferencia para la seguridad, con pequeñas mejoras a medida que la sal se vuelve más compleja.

Answer 2

El objetivo de la sal es ser único. La sal está destinada a evitar el costo compartido de ataque, es decir, un atacante que intenta atacar dos contraseñas hash por menos del doble del costo de atacar a uno.

Una solución para garantizar la singularidad es generar una sal aleatoria en un espacio lo suficientemente amplio. Por lo tanto, obtener el doble de sal para dos instancias de contraseñas distintas es lo suficientemente improbable como para que no suceda en la práctica.

El nombre de usuario no es adecuadamente único:

• El nombre de usuario no cambia cuando el usuario cambia su contraseña. Un atacante que vea la antigua contraseña hash y la nueva contraseña hash puede atacar a ambos a un costo inferior al doble del costo de atacar a uno.
• En un momento dado, los nombres de los usuarios son únicos en todo el sistema, no en todo el mundo. Hay muchos "bob" s por ahí (en un sistema Unix, considere "root"). El uso del nombre de usuario puede permitir que un atacante ataque varios sistemas simultáneamente.

La entropía de sal no es realmente importante, excepto en la medida en que asegura la singularidad en una configuración de generación aleatoria.

Answer 3

Qué tal si:

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

Eso aparentemente

1. tiene la ventaja de no tener que almacenar la sal, ya que puede calcularse dinámicamente,

2. sin dejar de tener buena entropía (basada en hash en lugar de texto plano), y

3. proporciona una sal que es tan larga como un hash criptográfico, por ejemplo, 128-512 bits?

Un problema sería si el sistema permite que dos usuarios tengan el nombre de usuario y la contraseña (sin embargo, esto no ocurriría con el correo electrónico), ¿pero hay algún otro problema con este esquema?