it-swarm-es.com

¿Por qué nos autenticamos solicitando al usuario que ingrese el nombre de usuario y la contraseña? ¿Solo basta con solicitar la contraseña?

No sé por qué nos autenticamos solicitando al usuario que ingrese el nombre de usuario y la contraseña. En mi modelo mental, solo basta con solicitar la contraseña.

La razon es la siguiente:

Suponga que hay x caracteres válidos para usar.

Caso 1 (solicitud de nombre de usuario y contraseña)

Deje que la longitud del nombre de usuario y la contraseña sea n/2 caracteres cada uno. Dado que el nombre de usuario está expuesto al público, la probabilidad de éxito para romper la contraseña es uno sobre x ^ (n/2).

Caso 2 (solicitud de contraseña solamente)

Deje que la longitud de la contraseña sea de n caracteres. La probabilidad de éxito para romper la contraseña es de uno sobre x ^ n.

¿Por qué nos autenticamos solicitando al usuario que ingrese el nombre de usuario y la contraseña? ¿Solo basta con solicitar la contraseña?

Editar 1

Para el caso 1: el nombre de usuario es único.

Para el caso 2: la contraseña es única.

13
LaTeX

Creo que el problema radica en exigir que las contraseñas sean únicas. Si ingresé mi contraseña deseada y me dijiste 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 querido.

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

Mientras lo hace, hash y sal esa contraseña.

40
Justin C

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

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 esa identidad reclamada (es decir, autenticación).

Consulte también Diferencia entre autenticación e identificación [Perspectiva de seguridad y criptografía]

19
AviD

Tanto el usuario como el administrador se benefician de un nombre de usuario, normalmente único, que no es un secreto, que pueden utilizar libremente para hacer referencia a la cuenta. Si el nombre de usuario no es único, puede asociarse 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 de eso, como han señalado otros, requerir solo una contraseña única también es problemático cuando es el único identificador y hay una colisión.

10
nealmcb

El objetivo 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? Por eso también hay un nombre de usuario.

Y dado que 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, yo solo tengo que saber eso y puedo iniciar sesión. Si también hay un nombre de usuario, la contraseña por sí sola no lo registra correctamente.

5
Andreas Arnold

Todavía no puedo comentar: (

Sus probabilidades de encontrar una contraseña son definitivamente incorrectas.

ejemplo:

tiene 8 usuarios y cada contraseña tiene una longitud de 64 bits (8 caracteres estándar, sin sal de ninguna manera).

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 tendrá que ejecutar su algoritmo 8 veces (una 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 tanto, el segundo caso tiene más posibilidades de obtener la contraseña, si hay más de un usuario.

5
Sigtran

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

  • Si usa solo una contraseña, el 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 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 mayor.

Ejemplo: Supongamos que asumimos que cada contraseña se elige uniformemente al azar de 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 logrará ingresar al sitio después 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 asumiendo que el atacante conoce el nombre de usuario de todos, el atacante tendrá que intentarlo aproximadamente 1,000,000,000 (mil millones) de veces antes de ingresar al sitio, en promedio. (En realidad, la mitad de eso, pero lo que sea).

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

Además, los comentarios de @Justin C 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 un nombre de usuario y una contraseña es mucho más sólido.

4
D.W.

En teoría, @Sigtran tiene razón en que tener un nombre de usuario siempre es mejor, por regla general, cuanto más ofuscación, más seguridad :) En la implementación, en situaciones en las que no necesita UUID o privilegios de usuario específicos, realmente no necesita un nombre de usuario (algo así como un repositorio general al que acceden varias personas). En esos escenarios, requerir una contraseña larga y compleja (alfanumérica + caracteres especiales) y luego ponerla en sal es el camino a seguir.

1
mrnap

La razón por la que necesita tanto un nombre de usuario como una contraseña es para poder buscar la sal única de ese usuario antes de aplicar hash y verificar la contraseña.

Un esquema típico y seguro tiene una tabla de usuario con al menos 3 columnas: nombre de usuario, sal, contraseña. La contraseña hash 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 hash. La autenticación implica buscar al usuario por nombre de usuario, agregar su sal única a su contraseña, hacer un hash del resultado y verificar que coincida con el hash de la contraseña en la base de datos.

Si simplemente aplica un hash a la contraseña y la almacena en la base de datos, un atacante que obtenga acceso a su tabla de usuarios puede descubrir algunas de las contraseñas comunes usando una tabla Rainbow (lista de contraseñas comunes). Es decir, toman la lista de contraseñas comunes, las codifican todas y ven si alguna de ellas coincide con la contraseña almacenada en su base de datos. Si cada usuario tiene una sal única, entonces tendrían que agregar esa sal a todas las contraseñas en la tabla Rainbow, luego aplicar un hash a todas, solo para ver si encuentran una coincidencia para ese usuario. Luego, tienen que repetir esto para todos los usuarios de su tabla. Esto aumenta enormemente el cálculo necesario para encontrar una contraseña coincidente en una tabla de usuario robada.

0
JMB