¿Deben mantenerse en secreto los nombres de usuario?

Sabiduría convencional re: ataque o enumeración por fuerza bruta

Hay algunas maneras de ver esto. Uno debería comenzar con enlace antes de intentar realmente pensar en ello,

Hay varios grados en los que se revelan las contraseñas. Mi nombre de usuario en Slashdot es conocido por todos los que leen una publicación mía. Todas las personas que se encuentran en la oficina pueden ver mi nombre de usuario en el trabajo, y cualquiera que conozca mi dirección de correo electrónico puede discernir por igual. Nadie debe saber mi número de cuenta bancaria (que es el nombre de usuario de mi banca en línea).

En cada una de esas situaciones, el beneficio de decir específicamente que el nombre de usuario no es válido o que la contraseña no es válida es limitado. Ahora, en ese escenario: si estás en Slashdot, sabes que la cuenta siempre estará ahí para que puedas descifrarla a pesar de todo. Si estás atacando mi trabajo, eso puede revelar si todavía estoy empleado. Contra mis cuentas bancarias o de tarjetas de crédito, esa es la única forma de enumerar las cuentas. Proporciona un objetivo claro.

Soy de la opinión de que, dado que reconocer uno u otro tiene un valor limitado para los sistemas públicos y puede filtrar información acerca de los privados, la autenticación de la contraseña siempre debe tener la forma "¿coinciden el nombre de usuario y la contraseña?" Esa es una pregunta T / F sin pasos intermedios.

New Age Wisdom re: Phishing

Un usuario accede a un sitio web, que puede ser el sitio web incorrecto. Ingresan sus credenciales de inicio de sesión sin prestar atención a la URL (o tal vez realmente se falsifican), y su cuenta está comprometida. Los bancos se han ocupado de esto haciendo de la autenticación un proceso de varios pasos. A esta idea, el interrogador original menciona que muestra una serie de fotos si el nombre de usuario es correcto. Contesto: SIEMPRE hacer que el proceso de autenticación pase por todos los pasos. Puede que jonjacob (jinkleheimerschmidt) no sea un inicio de sesión válido, pero aún debe mostrar una serie de fotos y solicitar una contraseña. Eso le permite reprimir el riesgo de fuga de información e intentar evitar que el phishing ponga en peligro una cuenta de usuario.

Riesgo v. Recompensa

La sabiduría convencional sobre los nombres de usuario y las contraseñas anteriores es simple y agradable para la mayoría, creo. El phishing es una nueva variable, y lidiar con eso cambiará la situación de algunos sistemas. Hay respuestas a su pregunta que pueden no ser discutidas aquí, o incluso pensadas todavía. Sin embargo, sigo creyendo que deberías poder evitar que alguien enumere cuentas en cualquier situación.

Si los usuarios tienen contraseñas complejas o usa seguridad adicional como tokens para forzar la complejidad de un ataque a un nivel "razonable", el aspecto criptográfico debe ser cubierto. Sin embargo, hay que considerar el aspecto de la privacidad: a algunas personas simplemente no les gusta que nadie descubra nada sobre ellos. Recuerde que no puede atender a cada minoría, y diseñe de acuerdo con los requisitos de la comunidad y el negocio.

Cita obligatoria: " La seguridad es siempre una compensación. "

La sugerencia de mantener en secreto los nombres de usuario parece absurda.

Es inevitable que necesite alguna forma de identificar a un usuario de una manera que no comprometa la seguridad de una cuenta. ¿Cómo funcionaría el correo electrónico si su dirección de correo electrónico fuera el token de autenticación? Si tengo problemas para usar algún software, ¿cómo le digo al servicio de asistencia a qué cuenta se relaciona?

  

le permite administrar un sitio bloqueando todas las cuentas donde el bloqueo de la cuenta está habilitado

También le permitiría acceder a un sistema donde no había una contraseña por separado; no es el problema revelar el nombre de usuario, sino la implementación de las reglas de bloqueo.

  

A los usuarios les gusta usar el mismo nombre de usuario y contraseña

Está bien, voy a conceder este. Pero no justifica el postulado. Los usuarios son estúpidos. Superalo. Si desea que piensen que su sitio es seguro, hay muchas investigaciones que demuestran que poner un panorama general de un candado funciona mejor que usar SSL. Si está intentando falsificar tokens secundarios de autenticación que se implementan a través de parciales (como en 'por favor, seleccione los dígitos 3 y 8 de su pin), simplemente proporcione un cuadro de entrada de texto y pídales que le proporcionen todo el contenido.

  

Los datos conocidos públicamente, como el móvil y el correo electrónico, no cuentan para la fortaleza de la autenticación

? pero los números móviles y las direcciones de correo electrónico son nombres de usuario !!!!!!!!

Las contraseñas no son una solución completa para entornos de alta seguridad. Pero tratar de usar un nombre de usuario como autenticador no ayuda a mejorar la seguridad y compromete otras cosas.

Solía hacer una mezcla de seguridad.

Por ejemplo, para la cuenta de correo del usuario:

• ID: [email protected]
• CONTRASEÑA: 1z "1dgG" @ "é ~ #.

Para la cuenta de usuario en la intranet, es así:

• ID: 1501823098 (por lo general, uso su propia ID de su tarjeta de identificación, o genero esa ID si no puedo hacer lo contrario)
• PASSWD: # \ ed "1:!) 3qs

El problema de que las personas conozcan la cuenta de usuario en la intranet (o Internet) es que cualquier pirata informático intentará atacar de forma bruta. Incluso si la contraseña es compleja, el ataque del diccionario y la fuerza bruta tendrán un impacto en su conexión, la disminución del ancho de banda, etc.

Además, tener solo 1 política sobre la cuenta de usuario y la contraseña para toda la aplicación de intranet / internet es como correr solo con casco de pan contra un tornado. ¡Puedes sobrevivir pero es como el suicidio!

Incluso si el usuario se quejará porque tiene que aprender 3 ID de cuenta diferentes y 3 contraseñas diferentes, su trabajo será mucho más fácil, ya que será sencillo aislar 1 cuenta que haya sido hackeada, y el usuario luego de algunos semanas, adáptese a esa política y tendrá un bastión realmente bien protegido.

Bueno, al menos eso es lo que hice en mi trabajo. Incluso ahora, en algún momento los usuarios tienden a olvidar su ID o contraseña, o a escribirlos, pero ese es su problema, hice mi trabajo para garantizar una buena política de seguridad. (Puede darles su ID o restablecer su contraseña si las perdieron).

Espero que esto te ayude.

EDITAR:

  

Tu control real contra esto es la longitud de la contraseña, la complejidad y la política de bloqueo de la cuenta

Tener una buena longitud de contraseña con complejidad tiene un gran defecto, diccionario. Yo uso (para mí) la contraseña con alta complejidad y 26 caracteres de longitud. Incluso si el diccionario no lo encuentra inmediatamente, consumirá una gran cantidad de procesos de red. Y tener una política de bloqueo de cuenta es una buena idea, pero cuando la cuenta está bloqueada, la secuencia de comandos de fuerza bruta intentará con otra cuenta y se repetirá así. Incluso si al menos la cuenta es segura, su red perderá mucho ancho de banda y, en el peor de los casos, toda su cuenta se verá afectada e incluso podría tener un apagón global.

  

Puede mitigar esto al tener un desbloqueo automático después de un período de tiempo (por ejemplo, 5 a 30 minutos), una función de desbloqueo masivo, un retroceso exponencial o una prohibición de IP durante un período de tiempo después de varios intentos incorrectos, selectivo controles anti-automatizados (por ejemplo, Captcha, script Roboo) mostrados después de varios intentos fallidos

Allí, el defecto es el usuario. Bueno, el usuario siempre es el defecto en TI, pero trate de imaginarse a un usuario, que después de 3 semanas de vacaciones (Sucede en mi trabajo con mi N + 2 ... historia real) olvidó su contraseña, lo intentará, bloqueará su cuenta, espera, vuelve a intentarlo, vuelve a estar bloqueado, después de 2 intentos, correrá hacia ti como un jinete mongol que invade Europa. Tendrá que deshabilitar esta regla para él, pero se difundirá el rumor de que hizo una excepción y otros usuarios querrán que usted haga lo mismo con ellos. En el peor de los casos, el usuario no acudirá a usted, sino que utilizará la cuenta de uno de sus colegas (que anota el ID y la contraseña y los mantiene preciosamente debajo de su escritorio).

  

La educación del usuario, un segundo factor de autenticación, la autenticación adaptativa (por ejemplo, la autenticación gradual o graduada basada en la identificación del dispositivo, la ubicación, etc.) serían mejores defensas contra esto

Bueno, estoy totalmente de acuerdo con usted en este punto. Regularmente formo a los usuarios sobre políticas de seguridad, solo para asegurarme de que no olviden lo que está en juego y capacitar a nuevos comerciantes. Pero eso debería ser normalmente en todas las empresas.

  

Veo el nombre de usuario y la identidad y la contraseña como autenticación. Si desea una autenticación más fuerte, haga que la contraseña sea más larga o que requiera 2 contraseñas. Deja la identificación sola

La identificación es puramente amigable para el usuario / administrador. Si desea reforzar la seguridad, hacer que la contraseña sea más larga o requerir 2 contraseñas solo obstaculizará al pirata informático. La forma real (al menos para mí) de reforzar su política, es actualizar su cifrado (hash md5, RSA, etc.). Mi N + 2 solía pensar que es inútil, pero después de una fuga crítica en nuestros servidores de seguridad, ya no piensa así (la fuga fue su culpa, consulte la segunda respuesta para entender ...). Creo que con seguridad nunca se puede tener cuidado.

Después es solo punto de vista. Algunos podrían decir que sus colegas tienen razón, otros podrían decir que usted tiene razón, para mí, creo que ambas partes tienen razón, usted y su colega necesitan encontrar una compensación con la cual trabajar.

Espero que esto haya respondido a tus preguntas.

La respuesta simple es revelar el nombre de usuario que hace que su aplicación sea menos segura.

Cualquier argumento sobre el aumento de la seguridad de otros factores de autenticación es una pista falsa.

Lo que sea que haga para mejorar aún más la seguridad de los otros factores también podría hacerse manteniendo el nombre de usuario oculto. Si esta aplicación es realmente de alto impacto, implementará todas las contramedidas en las que puede pensar si la seguridad del nombre de usuario se concede o no en la puerta.

Sí: la seguridad general es un equilibrio y solo al medir sus costos reales de soporte puede ver si el hecho de revelar el nombre de usuario vale la pena o el riesgo calculado para su reputación y presupuesto.

La pregunta real es por qué incurriría en todos los costos de ingeniería de mantener un campo de nombre de usuario para luego almacenarlo en una cookie o de otro modo regalar ese factor de autenticación.