¿Es más seguro tener los campos de nombre de usuario y contraseña en diferentes páginas?

1. Desde una perspectiva de control de seguridad , todo lo que realmente hace es disminuir la capacidad del software de prueba de contraseña automatizado para realizar su tarea de probar varias contraseñas. El sitio espera que un atacante pueda elegir un objetivo "más suave" en lugar de su sitio. Como un control de seguridad real, esta técnica no es particularmente efectiva.
   • También, específicamente para bancos, esta es una de varias industrias aprobaron las "mejoras de seguridad" que requiere la industria bancaria de los Estados Unidos bancos miembros para elegir. En los EE.UU. en 2011, todos los bancos y Las cooperativas de crédito fueron informadas de la nueva política de seguridad cibernética de la Consejo de examen de instituciones financieras federales ( enlace ), junto con las presentaciones de orientación de autenticación ( enlace ). Recuerdo el banco que utilizo al convertir sus páginas de inicio de sesión en 2012 y 2013 para cumplir con los nuevos estándares antes de su auditoría anual, incluido el traslado de la contraseña a una página separada del ID de usuario.
   • Teniendo en cuenta todos los listas de contraseñas robadas, las listas de direcciones de correo electrónico robadas por separado, De hecho, la mayoría de los usuarios usan la misma contraseña en todos los sitios que tienen. cuentas en, y el hecho de que la mayoría de los sitios de forma estúpida (de una seguridad perspectiva) obliga a los ID de usuario a ser direcciones de correo electrónico, hay nuevas tipos de contraseña altamente selectiva de "baja y lenta" en la web Sistemas de sondeo que aprovechan todo lo anterior. Por lo tanto, el sitio espera que al hacer que la secuencia de inicio de sesión sea más lenta para realizar la búsqueda automática de contraseñas, los atacantes se rindan antes.
2. Desde una perspectiva de diseño de la interfaz de usuario de seguridad , este patrón de diseño de la interfaz de usuario ofrece algunas ventajas útiles. Permite que los sitios que lo adoptan agreguen pasos de autenticación condicional. Por ejemplo, un sitio puede ofrecer a sus usuarios la opción de un token de mensaje de texto para crear una autenticación de dos factores. Para aquellos usuarios que proporcionaron un número de teléfono móvil, la secuencia puede ser: page1 = ingresar userid, page2 = ingresar token, page3 = ingresar contraseña. Para aquellos usuarios que no proporcionaron un número de teléfono móvil, es solo page1 = ingresar userid, page2 = ingresar contraseña.
   • Esta plantilla de diseño de interfaz de usuario también permite la conversión gradual de su base de usuarios a una autenticación más nueva y más sólida, tanto durante un período de tiempo como usuario por usuario , que son consideraciones importantes para un sitio con miles o más de usuarios.
   • Otro ejemplo, el banco que uso en 2012 convirtió sus páginas de inicio de sesión para que primero me pidieran una identificación de usuario, luego me pidiera que confirmara una imagen que había seleccionado en mi perfil de un conjunto de imágenes y luego finalmente me pide mi contraseña. en páginas separadas. El hecho de elegir o no una imagen de un conjunto de imágenes realmente agrega alguna efectividad de autenticación es un tema aparte de la pregunta sobre la plantilla de diseño de inicio de sesión de la interfaz de usuario.
   • Otro ejemplo es que algunos bancos decidieron implementar un "Teclado de interfaz de usuario" paraintentarfrustraralosregistradoresdeclaves(elIDdeusuarioseingresaenUnapáginaconuncampodetextodeIUregular,luegoseabreunasegundapáginaconel"Teclado de UI". Uno puede debatir si un teclado en pantalla es seguro o no, pero el patrón de diseño de IU de autenticación configurable y secuencial en páginas separadas permite a los sitios esta libertad para innovar.
   • La mayoría de los sitios no finalizan prematuramente la secuencia de inicio de sesión si se ingresa algo incorrectamente. El usuario final ingresa toda la información en las distintas páginas de la secuencia, y solo al final se entera si la autenticación fue exitosa o no. Algunos sitios salen temprano, lo que crea cierto riesgo residual institucional en términos de detección de validez de cuenta.
   • Los pasos de autenticación específicos que se muestran pueden incluso variar según el ID de usuario en particular, dado lo que ese usuario seleccionó en su perfil. Por lo tanto, los sitios que hacen esto ya no están obligados a ofrecer solo una secuencia de autenticación fija para todos sus usuarios finales.
   • Incluso los sistemas de inicio de sesión más avanzados de este estilo pueden incluso variar los pasos de autenticación para el mismo usuario final que falla la primera autenticación, o que accede desde una computadora / dispositivo desconocido, o desde una dirección IP que está significativamente fuera de - en la zona, o si el software de IDS automatizado del sitio cree que hay un ataque de prueba de contraseña en curso.
   • Por lo tanto, separar la IDENTIFICACIÓN de la AUTENTICACIÓN (también conocido como id. de usuario de la contraseña y otros pasos) en la IU de inicio de sesión le da a los sitios más libertad y flexibilidad para evolucionar sus procesos de inicio de sesión a lo largo del tiempo. Los sitios que cambian sus páginas de inicio de sesión a esta nueva plantilla pueden adaptar o alterar aún más la secuencia de inicio de sesión en el futuro, sin embargo, los usuarios finales no sienten que el proceso de inicio de sesión esté cambiando demasiado.

He visto esto usado por muchas ofertas como una forma de hacer Home Realm Discovery, cuando muchos IDPs están involucrados.

Cuando un usuario escribe su dirección de correo electrónico, la siguiente pantalla será el IDP o, en caso de que haya muchas opciones posibles, una lista de selección, seguida de una redirección.

Otra posibilidad es que esta técnica confunda los administradores de contraseñas o las funciones de "recordar mi contraseña" incorporadas en Chrome. Probablemente hay mejores formas de hacer esto, y si se hace solo por esta razón, puede resultar en teatro de seguridad .

Algunos sitios pueden permitir a los usuarios asociar una imagen o frase no confidencial con su nombre de usuario y mostrarla antes de que el usuario ingrese su contraseña. Dependiendo de los mecanismos utilizados para evitar situaciones de intermediario, este enfoque puede dificultar la tarea de un phisher de crear una página que, dado un nombre de usuario, llamaría rápida y fácilmente la imagen / frase asociada con eso usuario. En ausencia de un código de detección MITM, nada impediría a un phisher poner una pantalla de "nombre de usuario" falsa, enviar el nombre de usuario a la forma del banco y luego enviar la imagen / frase del sistema del banco, pero un banco Los sistemas podrían incorporar diversos mecanismos para intentar prevenir eso. Tal vez la mayor dificultad sea lograr la compatibilidad con el software de "seguridad" que intenta insertarse como un intermediario en las conexiones https: //.

Sospecho que esto no se ha hecho por una verdadera razón de seguridad, en lugar de eso, estos dos escenarios podrían explicarlo:

• Esto es simplemente un artefacto de cómo se desarrolló el sistema en lugar de algo que necesariamente volverían a implementar si estuvieran construyendo el sistema nuevamente hoy.
• Ha sido sugirió en respuestas anteriores que a los bancos les gusta que sus procesos de autenticación sean únicos y más complicados que las cuentas en línea típicas. Esto es para que los usuarios sientan que iniciar sesión en su banco es más seguro que iniciar sesión en, por ejemplo, Facebook.

Se pudo haber hecho para separar la identificación de la cuenta de los pasos de verificación de contraseña, pero si ese es el caso, solo puedo concluir que esto se hizo por algún motivo que no sea de seguridad. Si la identificación positiva de la cuenta se indica al usuario, se creará una vulnerabilidad de enumeración de la cuenta y el sistema será menos seguro en lugar de más.

Algunos sistemas de autenticación tienen un "sello de sitio personal" que debe identificar antes de ingresar su contraseña para evitar el phishing. Sin embargo, estos sistemas generalmente tienen alguna otra forma de autenticación (por ejemplo, el apellido de soltera de su madre) antes de mostrar el Sello para usted: eso evita que se enumeren las cuentas y que los phishers conozcan el sello del sitio sin tener que conocer algunos detalles sobre usted. Sin embargo, no se considera muy efectivo .

ISO 27k y OWASP recomiendan un enfoque de múltiples factores. Pero si solo separa un campo de ID de usuario y un campo de contraseña en páginas separadas, hay algunas cosas a considerar.

1. Este proceso de inicio de sesión no tiene nada que ver con separar la autenticación de la autorización. Solo hay autenticación en forma de reclamo (el nombre de la cuenta) y prueba (la contraseña). Para los sitios normales, la autorización está vinculada a las identidades, por lo que cualquier usuario puede demostrar su identidad automáticamente.

2. Tal proceso de inicio de sesión no es lo que se entiende por ISO u OWASP, porque no hay un proceso multifactor para probar la reclamación, no hay un canal adicional como un servicio de mensajería o huella digital etcétera . En ese sentido, realmente no mejora la seguridad.

3. Este proceso de inicio de sesión tiene ventajas y desventajas, según las expectativas del usuario. Al pedir primero solo el nombre de la cuenta, los usuarios normales no pueden mezclar accidentalmente el nombre de la cuenta con la contraseña. Pero los usuarios más experimentados que usan contraseñas largas y verdaderamente aleatorias que no pueden recordar, experimentarán una verdadera molestia. Debido a que esos usuarios utilizan la función de inicio de sesión automático de los administradores de contraseñas como KeePass, encontrarán que no funcionará cuando los campos estén en páginas separadas. Tienen que iniciar sesión manualmente, ingresando el nombre de cuenta y la contraseña por separado con cada intento de inicio de sesión.

4. Existe un argumento de que tal proceso de inicio de sesión podría ser técnicamente más seguro, porque los desarrolladores pueden tomar otras medidas para frenar los ataques de fuerza bruta. Por otro lado, se puede implementar una forma híbrida por medio de AJAX, de modo que los inicios de sesión automáticos de los administradores de contraseñas todavía funcionen, se puedan usar tokens de CRSF y no se tengan que proporcionar identificadores de sesión antes de que el usuario esté completamente autenticado. En otras palabras, los argumentos técnicos y de UX no necesariamente tienen que depender unos de otros.

5. Es importante recordar que los nombres de cuenta y las contraseñas se compartirán entre los usuarios. Es una práctica común que un solo usuario tenga varias cuentas únicas y / o no únicas para el mismo sistema. La identificación siempre identifica la cuenta , en lugar de un individuo vivo y único. Las medidas de seguridad deben implementarse teniendo en cuenta este hecho de la vida.

6. Muchos sitios comunes usan una dirección de correo para la declaración de identidad. Pero los usuarios pueden cambiar las direcciones de correo electrónico tan rápido como los números de teléfono prepago. Y siempre que los usuarios utilicen varias direcciones, el argumento de que un usuario siempre recordará los correos electrónicos se desvanecerá. Para UX, es una molestia cuando no puede cambiar la dirección de correo electrónico fácilmente a un nombre de cuenta sano. Un nombre de cuenta elegido tendrá un vector de ataque mucho más pequeño porque se conoce menos fácilmente y puede variar de un sistema o sitio a otro. Por lo tanto, mejorará la seguridad del usuario.