En los formularios de inicio de sesión de dos pasos, ¿por qué es el nombre de inicio de sesión y no la contraseña que se solicita primero?

Una sola contraseña no es necesariamente verificable por sí misma. En particular, si el servidor hace las cosas correctamente, entonces no almacena las contraseñas en sí mismas, sino la salida de un función de hashing de contraseña calculada sobre la contraseña. Una función de hash de contraseñas (en lugar de una mera función de hash) incluye algunas funciones adicionales, que incluyen un salt (por muy buenas razones relacionadas con la seguridad). La verificación de una contraseña requiere el conocimiento de la sal correspondiente. Dado que la sal es específica de la instancia (el punto de la sal es que los usuarios distintos tienen sus propias sales), se requiere la identidad del usuario (la identidad del usuario se usa como una clave de indexación para la sal).

Por una parte, el servidor no sabría si la contraseña sola coincide con alguna cuenta.

En un sistema seguro, las contraseñas se escriben y luego se procesan.

En una demostración simplista, supongamos que tengo tres usuarios:

Username  Password
bob       foobar
alice     foobar
maggie    foobar

Cuando se establecen estas contraseñas, se agrega un salt y se genera un hash:

Username  Salt      Value to hash     Hash result
bob       ABCDEF    ABCDEFfoobar      778f9aab91717e420e447d7e4cdd84f1
alice     123456    123456foobar      17e9191daecc5b8be26779209769b275
maggie    ZXCVBN    ZXCVBNfoobar      527cb07b112559cf9c1aff19d28074fa

Como puede ver, el propósito de la sal es que no se almacenan dos contraseñas iguales, aunque la contraseña pueda coincidir. Este es un paso de seguridad importante que se debe tomar para evitar que las tablas arco iris se usen en una lista de contraseñas extraídas.

Esto hace que sea imposible determinar a qué cuenta se está conectando solo con una contraseña, ya que no se conoce el uso de la sal. Esto se debe a que el nombre de usuario se usa como una clave para la búsqueda, y sin que se proporcione al servidor, la contraseña ingresada en el paso uno no puede coincidir sin probar cada hash en la tabla de usuarios hasta que se encuentre una coincidencia. En un sistema configurado correctamente, esto sería demasiado lento, porque está usando un algoritmo lento (consulte la nota al pie de página).

Además, sería una fuga masiva de información de seguridad si el sistema le informara que otra persona estaba usando su contraseña.

_{El ejemplo anterior es solo para fines ilustrativos y utiliza MD5. Nunca utilice MD5 para hash de contraseñas: use bcrypt, scrypt o pbkdf2.}

¿No estás preguntando básicamente "¿Hay alguna razón para que no tengamos contraseñas públicas y nombres de usuario privados?"

Ambos son solo cadenas de texto. Su idea de hacer cumplir contraseñas únicas es simplemente decir que los nombres de usuario son únicos. La etiqueta que apliques a un cuadro de texto no importa. Llamamos a la cadena que es privada una contraseña y la única nombre de usuario o ID de usuario porque es única.

Desde el punto de vista de seguridad y véanlo en el orden normal de inicio de sesión / contraseña: si exigiera que ambos ambos fueran únicos, abriría un ataque en la base de datos, ya que todas las contraseñas verificadas se verificarían contra todos los usuarios de la base de datos porque ha requerido que sus contraseñas sean únicas . Así que los dos únicos no funcionan. Ambos no únicos no funcionan porque no sabe a qué cuenta se está accediendo. Así que eso deja solo tener una cadena única. Si está creando una única cadena de texto única, también puede hacer que sea un dato público y verificar eso primero (y llamamos a estos datos Inicio de sesión / ID / Nombre de usuario).

Imaginemos una analogía ...

Soy un mensajero enviado por mi rey para enviar un mensaje a un castillo en el Valle de los Castillos. Sé cómo es el castillo al que quiero ir y me dieron una frase de contraseña para decirle a la guardia que me permitiera entrar al castillo.

Tengo dos opciones para hacer esto:

1. Como sin duda esperaría, la forma convencional de hacerlo es ir al castillo al que me enviaron y luego decirles la frase de contraseña que se debe ingresar. Esto es primero usando mi información pública (el castillo , visible para cualquier persona que quiera verlo) para iniciar sesión con mi información privada (la frase de contraseña).

2. Pero hay una forma inversa de hacer esto. Puedo obtener una bocina y gritar mi contraseña en todo el valle para que el público la escuche. Desde que el castillo que intento visitar ha escuchado mi contraseña (junto con todos los otros castillos y los residentes infames del valle), el castillo que estoy visitando debería saber esperarme.

   Luego procedo a caballo hasta el castillo correcto y cruzo su puente levadizo abierto. ¡Pero dejarían entrar a cualquiera a través de este puente levadizo abierto! Ahora que mi información privada ha sido compartida con el mundo, cualquiera puede viajar entre los castillos y entrar al que tiene la puerta abierta.

   Si no estoy aquí para gritar esto en un cuerno, los residentes del valle podrían pararse en la cima de una colina con su propio cuerno, gritando alboroto en todo el valle hasta que escuchen el ruido de un puente levadizo abriéndose; sabiendo que adivinaron una frase de contraseña correctamente, simplemente deben viajar entre los castillos hasta que encuentren una que esté abierta.

La primera opción es cómo se hace normalmente. No hay razón para cambiar esa convención. La alternativa es posible, pero al compartir su información privada primero, hace que sea mucho más fácil adivinar la contraseña de todos a la vez antes de autenticar con información pública, es decir, ir a cada castillo o probar a todos los públicos. nombres de cuentas Con miles de castillos en este valle o cuentas en un sitio web, es muy probable que alguien adivine una contraseña fácil y luego sea mucho más fácil simplemente asociarla con uno de los pocos miles de castillos o nombres de cuentas públicas.

Google no tiene que ingresar su correo electrónico primero por ningún motivo de seguridad. Le permite ingresar su correo electrónico / nombre de usuario, por lo que si inicia sesión en un dominio de trabajo o educación que desea tener su propia página de destino para SSO / SAML

Si primero solicita la contraseña, debe mantener el valor "secreto" en algún estado mientras espera el nombre de usuario. Con una aplicación web, normalmente necesitaría hacer ese almacenamiento de alguna manera para que un nuevo proceso pueda leer el valor, ya que el nombre de usuario aparecería en una segunda solicitud. Eso aumenta la ventana de oportunidad para que se revele la cadena de la contraseña, tanto en términos de tiempo como de formas de obtener los datos.

Al solicitar el nombre de usuario primero, la verificación de la contraseña que utiliza hashing con sal (o no) ya puede tener acceso a todo lo necesario para verificar la contraseña de inmediato, y el sistema solo necesita tener la contraseña disponible por un mínimo de tiempo. En general, es mejor tener datos confidenciales disponibles en el menor tiempo posible.

Y es convención. Al solicitar la contraseña primero, terminará capacitando a los usuarios para que escriban accidentalmente su contraseña en los campos de nombre de usuario en otros lugares, lo que probablemente resultará en la divulgación a través de registros.

No hagas eso. :)

Para agregar en; el mecanismo de identificación frente a la autenticación / verificación se decide al desarrollar la aplicación. La identificación es 1: muchas , la verificación / autenticación es 1: 1

    1:1 - match against one pre-selected result set;

    1:many - match against all results in the DB

Los nombres de usuario como gmail son únicos. Esto no es obligatorio para todas las aplicaciones, pero seguro que facilita la vida del algoritmo de verificación en lugar del algoritmo de identificación.

Considere el nombre de usuario popular y luego la autenticación de contraseña para gmail:

1. ingresa el nombre de usuario;

   gmail coincide con el nombre de usuario único con todos los demás nombres de usuario únicos; Si coincide, ingrese la contraseña; No coinciden, no hay acceso.

2. Introduce la contraseña.

   gmail solo hace coincidir el 1 nombre de usuario con la 1 contraseña almacenada en cualquier formato; No hay coincidencia, la autenticación falló. Sí coinciden, acceda a su correo.

IMHO bastante sencillo.

Tomando el otro lado, identificación (1: muchos), el proceso de coincidencia de gmail sería así:

1. ingrese la contraseña; y como @SilverlightFox indicó claramente, muchas cuentas pueden tener la misma contraseña.

   matching algorithm matches password to ALL usernames registered in gmail database.
   

   Un conjunto de resultados demasiado conservador puede ser 10 nombres de usuario.

2. Introduzca el nombre de usuario;

Si los nombres de usuario son únicos o pueden ser iguales, decidirá cuánto tiempo de más se ejecutará el proceso de autenticación y cuántas coincidencias se encontrarán. Si hay más de 1 coincidencia, tendremos que implementar la autenticación de inicio de sesión en 3 pasos.

La autenticación en dos pasos hace la vida más fácil para el desarrollador y el algoritmo.

En el caso de Google y la mayor parte de la configuración de autenticación dividida, el sistema básicamente utiliza la identificación del usuario para identificar el riesgo asociado y determinar el proceso de inicio de sesión adecuado que debe ejecutar para el usuario.

En la mayoría de estas situaciones, la identificación de usuario ingresada por persona es solo una entrada que se está considerando. Junto con él, mucha información adicional (como la dirección IP desde la que está accediendo, el dispositivo que está utilizando el usuario - se genera una firma de dispositivo y se transmite junto con la identificación del usuario) a un motor de determinación de riesgos (en la mayoría de los bancos pero no siempre se puede utilizar) que puede proporcionar un proceso de inicio de sesión sugerido. Además de que el sistema verifica la política de inicio de sesión asociada con el usuario (es decir, si tiene multifactor habilitado, por ejemplo). Según la determinación final, la mayoría de las veces solo puede obtener una pantalla de contraseña simple, pero en algunos casos se le puede solicitar un proceso de autenticación múltiple (por ejemplo, OTP basado en teléfono, etc.).