¿Por qué las personas no tienen nombres de usuario de hash y sal antes de almacenarlos?

Si bien lo que dice Terry es cierto, a veces los sistemas de inicio de sesión en realidad incluyen el nombre de usuario (pero sin sal). Tienen que elegir un nombre de inicio de sesión y un nombre para mostrar. El nombre de inicio de sesión se almacena como hash (sin sal porque es necesario poder buscarlo) y la contraseña está incluida. El nombre para mostrar es diferente de su nombre de inicio de sesión (porque también debe mantenerse en secreto) y se muestra donde sea necesario.

Incluso cuando un atacante ve su nombre, no podrá adjuntarlo a su nombre de inicio de sesión. Aunque digo que puede ser salado, en realidad no hay necesidad de esto. La parte más importante es mantenerlo en secreto. Si la base de datos se ve comprometida, cosas como su dirección de correo electrónico o nombre seguirán estando allí para que el atacante las use si quiere organizar nuevos ataques en sus otras cuentas.

¿Ves esa cosa allí arriba donde muestra tu nombre de usuario? No pueden hacer eso si el nombre de usuario se almacena con hash ahora, ¿verdad?

Una palabra, usabilidad.

En general, los nombres de usuario no se consideran seguros, son identidad, no autenticación. Es bueno no revelar qué nombres de usuario son válidos, pero sería peor si tuvieras una colisión. Aún puedes solucionar esto buscando en todos los nombres de usuario coincidentes para un hash de contraseña que coincida, pero eso es un poco complicado.

De manera realista, si tiene una buena seguridad de contraseña y límites en los intentos de inicio de sesión, una lista completa de nombres de usuario ofrece poco valor práctico a un atacante. Su principal beneficio sería el phishing, pero si su correspondencia oficial contiene información, entonces esa información no se puede cifrar y la obtendrían si comprometieran su base de datos de todos modos.

También, usabilidad como dijo Terry. Es mucho más fácil encontrar su cuenta si pueden ver los nombres de usuario. No gana lo suficiente al intentar asegurar un identificador para justificarlo en la mayoría de los contextos.

Si bien otros han señalado que hay pocas ventajas (si es que las hay), no me importaría su afirmación de que no existen inconvenientes. Si almacena solo el nombre de usuario con hash, entonces buscar el nombre de usuario es fácil. Si almacena un nombre de usuario hasted y hash, la búsqueda se vuelve un poco más problemática.

Supongamos que si construimos una tabla SQL que contiene nombres de usuario y contraseñas (con hash) e indiquemos al servidor SQL que indexe la columna de nombre de usuario, hará algún tipo de búsqueda binaria o algún otro tipo de magia. Podríamos tener una tabla que se parece a:

Username  |  Password
test      |  j9lnvqjAuhNJs

(Este es el hash crypt (3) de la vieja escuela Unix solo por simplicidad y brevedad.)

Si almacena sus nombres de usuario en texto sin formato, la recuperación de la contraseña (hash) para un usuario es una simple llamada a SQL. Supongamos que desea validar las credenciales de un usuario que escribió el nombre de usuario test :

SELECT password FROM users WHERE username='test';

Suficientemente simple. Ahora, si almacenáramos los nombres de usuario en el mismo formato que las contraseñas, nuestra tabla terminará con este aspecto:

Username       |  Password
M1CAtvzDdJDGU  |  j9lnvqjAuhNJs

Ahora, cuando un usuario escribe su nombre de usuario de test , ¿cómo valida la contraseña? Una búsqueda binaria es inútil aquí, ya que ni siquiera sabe la sal que utilizó para almacenar el nombre de usuario. En su lugar, debe recorrer cada nombre de usuario en la base de datos, crypt ing el nombre de usuario dado con el salt para ese nombre de usuario y compararlo con el nombre de usuario almacenado (con hash) para ver si coincide. ¡Yuch!

¿Supongamos que tomó algunas buenas precauciones y usó un hash lento agradable como bcrypt en lugar de la vieja cripta Unix? Doble yuch!

Como puede imaginar, hay algunos inconvenientes serios al almacenar un nombre de usuario hash con sal en lugar de solo texto sin formato.

Creo que la razón más probable es que el hash de los nombres de usuario junto con la contraseña no ofrece ninguna protección adicional.

Alentamos a los usuarios a crear contraseñas difíciles y complejas, haciendo que sean más difíciles de descifrar. Cualquier base de datos de nombres de usuario con hash se puede descifrar en minutos con un diccionario básico ... a menos que solicite que sus nombres de usuario tengan al menos 6 caracteres alfanuméricos;)

Si hasteado el nombre de usuario y has introducido el nombre de usuario, ¿cómo sabría el sistema que las cuentas nuevas tenían un nombre de usuario único, sin iterar todos los registros existentes y mezclar el nuevo nombre de usuario con cada sal individual?

Tu idea es noble y la pregunta interesante. Ahora, creo que tampoco no pensó en la facilidad de uso al plantear la pregunta o se perdió el punto de hashing (o tal vez mal escrito 'cifrado').

El hash es irreversible, a menos que tengas supercomputadoras para hacer fuerza bruta o tablas de arco iris para intentar buscar hashes. Por lo tanto, la facilidad de uso iría cuesta abajo si tuviera que marcar los nombres de usuario / correos electrónicos utilizados para los inicios de sesión. Sin embargo, si uno fuera a "cifrar" lo mismo usando una clave predefinida en el programa (el que verifica el nombre de usuario), entonces podría ser un poco seguro. Sin embargo, una vez más, una clave de cifrado almacenada directamente en un programa es tan buena como ninguna clave. Estas son las razones principales por las que los nombres de usuario no están cifrados o encriptados.

Esta idea coincide con dos tácticas: 1) Seguridad por oscuridad, 2) Mitigación adicional de ataques de tiempo (si utiliza una función de comparación de tiempo seguro). No puede usar una sal única para hacer esto de manera efectiva, pero es una buena idea. Esto permitiría separar la tabla que contiene información de inicio de sesión de la que contiene información de "persona". Luego, dos tablas, persona (podría contener direcciones de correo electrónico de texto sin formato) y usuario (podría tener un nombre de usuario con hash {site wide salted} y una contraseña con hash y con sal única). Buscar al usuario por nombre de usuario con hash no es un problema.

Creo que esta es una excelente idea. Según lo expresado por Anthony Rutledge; esto puede proporcionar seguridad a través de la oscuridad / ofuscación y si utiliza una función de derivación de claves, como PBKDF2, supongo que hay una mayor dificultad, en órdenes de magnitud, para un posible atacante que intenta comprometer una base de datos robada.

Por ejemplo, un ataque de fuerza bruta fuera de línea en una base de datos robada requeriría encontrar colisiones de hash tanto para el nombre de usuario como para la contraseña, a pesar del hecho de que la distribución del nombre de usuario en el método, como mencioné anteriormente, haría que se identificara colisiones de nombre de usuario discutibles.

Esto significa que los atacantes tendrían que apropiarse de su máquina y también identificar y comprender su código fuente, ya que la sal no existiría en ningún lugar dentro de su base de datos. Agrega múltiples capas de defensa adicional, sin agregar mucho, si es que lo hay, un aumento significativo en la carga computacional para la aplicación web.

En lo que respecta a problemas con el hash: el nombre de usuario puede incluirse con un hash propietario del servidor, basado en el nombre de usuario / correo electrónico real.

Eso significaría que la sal es conocida, aunque programáticamente. Y el script que calcula y devuelve la sal puede residir en la máquina en una forma fuera de banda, en relación con el servicio web, de modo que cualquier método para generar la sal podría ser inaccesible desde cualquier punto de entrada orientado hacia la web.