Salar: ¿Es razonable usar el nombre de usuario?

Question

Estoy debatiendo el uso de nombres de usuario como medio para eliminar contraseñas, en lugar de almacenar una cadena aleatoria junto con los nombres. Mi justificación es que el propósito de la sal es evitar tablas de arcoíris, entonces ¿qué hace que esto sea menos seguro que otro conjunto de datos?

Por ejemplo,

hash(md5(johnny_381@example.com), p4ss\/\/0rD)

vs

hash(md5(some_UUID_value), p4ss\/\/0rD)

¿Hay una verdadera razón yo no podía seguir con el nombre de usuario y simplificar las cosas? La única cosa que mi Web búsqueda dio como resultado era debates en cuanto a cómo debe ser una sal como una contraseña, pero terminó sin ningún razonamiento detrás de él, donde estoy bajo la impresión de que esto es sólo para evitar que algo así como un Caín-y-poder cracker para correr contra ella sin estar en el rango de un millón de años. Al pensar en procesar las limitaciones de la realidad, no creo que esto sea importante si las personas conocen el hash, aún no conocen la contraseña, y se han movido al rango de supercomputadora para aplicar fuerza bruta a cada hash individual.

Podría alguien por favor me ilumine aquí?

Answer 1

Vas a tener problemas, cuando cambia el nombre de usuario (si puede ser cambiado). No hay forma de que pueda actualizar la contraseña hash, porque no almacena la contraseña no saldada y sin hit.

Answer 2

no veo un problema con la utilización del nombre de usuario como el valor de la sal.

Una forma más segura de almacenar contraseñas implica el uso de un valor sal diferente para cada registro de todos modos.

Si mira la tabla aspnet_Membership del proveedor de membresía asp.net, verá que han almacenado los campos password, passwordsalt y username en prácticamente el mismo registro. Entonces, desde esa perspectiva, no existe una diferencia de seguridad al usar el nombre de usuario para el valor de sal.

Tenga en cuenta que algunos sistemas utilizan un valor sal único para todas las contraseñas, y la tienda que en un archivo de configuración. La única diferencia en seguridad aquí es que si obtuvieron acceso a un único valor de sal, entonces pueden construir más fácilmente una tabla arcoiris para descifrar todas las contraseñas a la vez ...

Pero, de nuevo, si tienen acceso a la forma encriptada de las contraseñas, entonces probablemente tendrían acceso al valor de sal almacenado en la tabla del usuario junto con él ... Lo que podría significar que tendrían un tiempo un poco más difícil de descifrar los valores de la contraseña.

Sin embargo, al final del día, creo que casi todas las aplicaciones fallan en el frente del cifrado porque solo cifra lo que aparentemente es uno de los datos menos importantes: la contraseña. Lo que realmente debería ser encriptado es casi todo lo demás.

Después de todo, si tengo acceso a su base de datos, ¿por qué me importaría si la contraseña está encriptada? Ya tengo acceso a las cosas importantes ...

Obviamente, hay otras consideraciones en juego, pero al final del día, no me preocuparía demasiado porque es un problema menor comparado con otros.

Answer 3

Este método se consideró suficientemente seguro para el grupo de trabajo que creó la autenticación resumida HTTP que opera con un hash de la cadena "nombre de usuario: dominio: contraseña".

Creo que estarás bien ya que esta decisión es secreta. Si alguien roba su base de datos y código fuente para ver cómo realmente implementó su hashing, ¿para qué están ingresando para acceder en ese punto? ¿El sitio web que muestra los datos en la base de datos que ya han robado?

En este caso, una sal le compra a su usuario un par de beneficios de seguridad. En primer lugar, si el ladrón tiene valores precalculados (tablas de arcoíris) tendrían que volver a calcularlos para cada usuario para poder realizar su ataque; si el ladrón busca la contraseña de un solo usuario, esto no es una gran ganancia.

En segundo lugar, los valores hash para todos los usuarios siempre serán diferentes, incluso si comparten la misma contraseña, por lo que el ladrón no tendría colisiones hash gratis (un usuario obtiene 300 contraseñas).

Estas dos ventajas ayudan a proteger a los usuarios que pueden usar la misma contraseña en varios sitios, incluso si el ladrón adquiere las bases de datos de otros sitios.

Por lo tanto, aunque una sal para el uso de contraseñas es mejor mantenerla en secreto (lo que en su caso sería la información exacta utilizada para la sal) aún proporciona beneficios incluso si está comprometida.

Answer 4

El salado aleatorio evita la comparación de dos valores hash de contraseña calculados de forma independiente para el mismo nombre de usuario. Sin él, sería posible comprobar si la contraseña de una persona en una máquina coincide con la de otra, o si una contraseña coincide con una que se usó en el pasado, etc., sin tener que tener la contraseña real. También facilitaría en gran medida la búsqueda de criterios como el anterior incluso cuando la contraseña esté disponible (ya que uno podría buscar el hash calculado, en lugar de calcular el hash por separado para cada valor de hash de contraseña anterior).

En cuanto a si tal prevención es algo bueno o malo, quién sabe.

Answer 5

Si utiliza el nombre de usuario como contraseña y hay muchas instancias de su aplicación, las personas pueden crear tablas rainbow para usuarios específicos como "admin" o "system" como es el caso con bases de datos Oracle o con una lista completa de nombres comunes como lo hicieron para WPA (CowPatty)

Será mejor que tomes una sal realmente aleatoria, no es tan difícil y no volverá a atormentarte.

Answer 6

Sé que esta es una pregunta antigua, pero para cualquiera que busque una solución basada en esta pregunta.

Si utiliza una sal derivada (a diferencia de la sal aleatoria), la fuente de sal se debe reforzar mediante el uso de una función de derivación de clave como PBKDF2.

Por lo tanto, si su nombre de usuario es "theunhandledexception" pase eso a través de PBKDF2 para x iteraciones para generar un valor de 32 bit (o lo que sea que necesite).

Realice x pseudoaleatorios (a diferencia de números pares como 1,000) y pase una sal específica del sitio estática al PBKDF2 y hará altamente improbable que su nombre de usuario sal coincida con el sal de nombre de usuario de cualquier otro sitio.