¿Por qué nos autenticamos solicitando a un usuario que ingrese el nombre de usuario y la contraseña? ¿Es suficiente pedir la contraseña?

Creo que el problema es que las contraseñas sean únicas. Si ingresé la contraseña deseada y me dijo que no puedo usarla, ya está en uso, entonces sé que puedo iniciar sesión en una cuenta de personas al azar con la contraseña que hubiera deseado.

Por lo tanto, necesita un nombre de usuario, que es único y que todos puedan conocer. Luego tienes una contraseña personal, que no es necesariamente única, lo que hace que sea aún más difícil de adivinar.

Mientras estés en ello, hash y salta esa contraseña.

Ya hay buenas respuestas aquí, pero aún falta el concepto básico:

  

La identificación y la autenticación no son lo mismo.

En pocas palabras, estos son dos requisitos separados, y no deben confundirse.
Un nombre de usuario proporciona identificación y una contraseña le permite verificar la identidad reclamada (es decir, la autenticación).

Ver también Diferencia entre autenticación e identificación [Crypto y perspectiva de seguridad]

Tanto el usuario como el administrador se benefician de un nombre de usuario, generalmente único, que no es un secreto, que pueden usar libremente para referirse a la cuenta. Si el nombre de usuario no es único, se puede asociar con una dirección de correo electrónico u otra identificación de contacto única. De esta manera, un usuario puede restablecer su contraseña y obtener una nueva, o cambiar su contraseña sin cambiar su cuenta.

Además, como lo señalan otros, requerir solo una contraseña única también es problemático cuando es el único identificador y hay una colisión.

El punto del nombre de usuario es identificar al usuario. Si solo solicita una contraseña, varias personas (lamentablemente) tendrán la contraseña 123456 o la contraseña. ¿Cómo se identifica ahora, qué usuario con esa contraseña está intentando iniciar sesión? Es por eso que también hay un nombre de usuario.

Y como la contraseña no debe guardarse en texto sin formato, no debe verificar que la contraseña sea única.

El otro punto que se pierde en el caso 2: solo necesito encontrar una contraseña que alguien usó, y no quién la usó realmente. Entonces, si una persona usa la contraseña 123456, solo tengo que saber eso y puedo iniciar sesión. Si también hay un nombre de usuario, la contraseña sola no inicia sesión correctamente.

Todavía no puedo comentar :(

Sus probabilidades de encontrar una contraseña son definitivamente erróneas.

ejemplo:

tienes 8 usuarios & cada contraseña tiene una longitud de 64 bits (8 caracteres estándar, sin sal en modo alguno).

Para el caso dos:

Un atacante tendrá que ejecutar su algoritmo para romper la contraseña solo una vez para obtener los 8 usuarios (trabajo total en el peor de los casos = 64 bits, 32 bits en promedio)

Para el caso uno:

Para romper todas las contraseñas, un atacante deberá ejecutar su algoritmo 8 veces (una vez para cada usuario), lo que obviamente es más trabajo (por ejemplo, trabajo total en el peor de los casos = 67 bits, 33-34 bits en promedio)

La probabilidad de romper la contraseña debe ser:

Para el caso uno:

1 / (2 ^ bitsUsedForPassword)

Para el caso dos:

numberOfUsers / (2 ^ bitsUsedForPassword)

por lo tanto, el segundo caso tiene más posibilidades de obtener la contraseña, si hay más de un usuario.

Definitivamente, tener un nombre de usuario y una contraseña es más seguro. Supongamos que su sitio tiene un millón de usuarios:

• Si usa solo una contraseña, entonces un atacante solo tiene que adivinar una de las millones de contraseñas válidas para ingresar al sitio.

• Si usa un nombre de usuario y una contraseña, entonces el atacante debe crear un nombre de usuario válido y la contraseña correcta para ese nombre de usuario (no solo cualquier contraseña en el sitio). Eso es mucho más difícil para el atacante.

Requerir un nombre de usuario y una contraseña proporciona una seguridad mucho mejor.

Ejemplo: Supongamos que suponemos que cada contraseña se elige de manera uniforme y aleatoria entre un conjunto de mil millones de posibilidades, por ejemplo, es un número aleatorio de 9 dígitos. (Sí, sé que es una suposición poco realista, por lo que este ejemplo será una simplificación, pero los resultados similares se aplican a suposiciones más realistas).

• Si el sitio solo requiere una contraseña válida para iniciar sesión, entonces un atacante que ingrese números aleatorios de 9 dígitos podrá ingresar al sitio luego de aproximadamente 1000 intentos, en promedio.

• Si el sitio requiere un nombre de usuario válido y su contraseña correspondiente para iniciar sesión, incluso suponiendo que el atacante sepa el nombre de usuario de todos, el atacante tendrá que probar aproximadamente 1,000,000,000 (mil millones) de veces antes de ingresar al sitio promedio. (En realidad, la mitad de eso, pero como sea).

Puedes ver que la diferencia en la seguridad es dramática.

Además, los comentarios de @Justin C's y @nealmcb proporcionan razones ortogonales adicionales para requerir un nombre de usuario y una contraseña. Cualquiera de estas razones sería suficiente; en conjunto, el caso de requerir tanto un nombre de usuario como una contraseña es mucho más sólido.

En teoría, @Sigtran tiene razón en que tener un nombre de usuario siempre es mejor, por regla general, cuanto más confuso es, más seguridad :) En la implementación, en situaciones en las que no necesita UUID o privilegios de usuario específicos, realmente no lo hace. t necesita un nombre de usuario (algo así como un depósito general al que acceden varias personas). En esos escenarios, se requiere una contraseña larga y compleja (caracteres alfanuméricos + especiales) y, a continuación, incluirla es el camino a seguir.

La razón por la que necesita tanto un nombre de usuario como una contraseña es para que pueda buscar el archivo salt de ese usuario antes de marcar y verificar la contraseña.

Un esquema seguro típico tiene una tabla de usuario con al menos 3 columnas: nombre de usuario, salt, passwordhash. El passwordhash es la contraseña del usuario con su sal única (una combinación aleatoria y única de caracteres) agregada, luego se ejecuta a través de su algoritmo de hash. La autenticación implica buscar al usuario por nombre de usuario, agregar su sal única a su contraseña, mezclar el resultado y verificar que coincida con el hash de contraseña en la base de datos.

Si simplemente hash la contraseña y la almacenas en la base de datos, un atacante que obtiene acceso a tu tabla de usuarios puede descubrir algunas de las contraseñas comunes utilizando una tabla de arco iris (lista de contraseñas comunes). Es decir, toman la lista de contraseñas comunes, las procesan todas y observan si alguna de ellas coincide con la contraseña almacenada en su base de datos. Si cada usuario tiene un salt único, entonces tendría que agregar ese salt a cada contraseña en la tabla del arco iris, luego hash todos ellos, solo para ver si encuentran una coincidencia para ese usuario. Luego tienen que repetir esto para cada usuario en su tabla. Esto aumenta enormemente el cálculo necesario para encontrar una contraseña coincidente en una tabla de usuarios robada.

O puede omitir todo el argumento utilizando Open ID. Todo lo que el usuario necesita es un ID de inicio de sesión o URL y el resto es atendido por el proveedor. :)