¿Iniciar sesión con el correo electrónico es más seguro que un nombre de usuario?

Dales una opción. Por ejemplo, mi dirección de correo electrónico es bastante larga, mientras que generalmente elijo nombres de usuario cortos; puede desarrollar su formulario de inicio de sesión para aceptar ambos.

Los nombres de usuario no son para proteger cuentas, las contraseñas son. No es por ninguna razón que el nombre de usuario es visible cuando se ingresa en el navegador, mientras que la contraseña está oculta. Además, los usuarios a menudo reutilizan los nombres de usuario, lo que, en contraste con la reutilización de la contraseña, no debería ser un problema. Y, por supuesto, las direcciones de correo electrónico fueron y nunca están destinadas a no ser compartidas con nadie.

Pero el problema principal: no almacena nombres de usuario o direcciones de correo electrónico con hash / cifrado, ya que quiere usarlos para otros fines que no sean el inicio de sesión. Si alguien roba la base de datos con sus contraseñas de hash, también tendrá Los nombres de usuario y direcciones de correo electrónico. ¡Se acabó el "beneficio de seguridad"!

Por lo tanto, obligar a los usuarios a iniciar sesión utilizando solo la dirección de correo electrónico (y la contraseña) o solo el nombre de usuario (y la contraseña) no tiene sentido.

Su defensa debe hacer cumplir contraseñas seguras y asegurarse de cifrarlas con una función de hashing de contraseñas seguras. No olvide establecer el costo alto suficiente .

Además, para evitar que un atacante que no robó su base de datos alquile una red bot y contrate contraseñas de usuario débiles, restringe el número de intentos de inicio de sesión por hora por dirección IP. Además, si encuentra una gran cantidad de intentos de inicio de sesión para una cuenta, bloquee los intentos de inicio de sesión desde cualquier dirección IP desde la que no se haya realizado correctamente el inicio de sesión de la cuenta.

Tener un nombre de usuario proporciona más claridad que el correo electrónico, lo que brinda seguridad, ya que Bruteforcer necesitaría el nombre de usuario antes de poder realizar un ataque.

Un correo electrónico no es tan oscuro como un nombre de usuario como correo electrónico. Los usuarios pueden usar su correo electrónico en cada registro de otra cuenta, suscribirse a un boletín informativo o incluso publicarlo en algún lugar para que alguien se comunique con usted. Si un hacker investiga un poco o lo conoce y, de alguna manera, se apoderó de su dirección de correo electrónico a través de la ingeniería social, tendrá mayores posibilidades de realizar un ataque de fuerza bruta o una contraseña de adivinación.

Un nombre de usuario implementa más seguridad de esta manera, ya que ahora el pirata informático necesita saber tanto su nombre de usuario como su contraseña para realizar el ataque. Es más fácil obtener su dirección de correo electrónico con una razón legítima que obtener su nombre de usuario. Si tiene características como "agregar un nombre de usuario a la lista de amigos", en su lugar podría implementar agregar por ID de miembro y no se usa para iniciar sesión.

Una dirección de correo electrónico ofrece comodidad para el usuario, ya que necesitarán memorizar una cosa menos importante, ya que la mayoría de nosotros, que somos dueños y usamos el correo electrónico, a menudo recordamos su dirección de correo electrónico. Seguridad y comodidad siempre es un intercambio entre sí.

También tenga en cuenta que para mantener el nombre de usuario oculto, asegúrese de que no está devolviendo un mensaje como "El nombre de usuario no existe" al iniciar sesión por error. Devuelva algo como "inicio de sesión fallido: compruebe su nombre de usuario / contraseña"

La mayoría de los bancos que conozco no usan la dirección de correo electrónico para la autenticación, preferirían un nombre de usuario, ya que proporciona más oscuridad. Puede considerar el nombre de usuario como otra forma de 'contraseña' en este caso, solo que es una contraseña menos segura, ya que no está cifrada y otras personas pueden verla en texto sin formato mirando por encima de la pantalla.

Hay poco que ganar al tener un nombre de usuario secreto o algo parecido. Siempre que aplique una política de contraseña adecuada, los ataques de fuerza bruta no serán efectivos, independientemente de si el nombre de usuario es público o no. Si un atacante intercepta la contraseña de alguna manera, a través de un keylogger o un rastreo de paquetes, también puede interceptar el nombre de usuario secreto.

Este problema es mejor pensado en términos de usabilidad. ¿Desea que sus usuarios recuerden una dirección de correo electrónico, un apodo, un nombre de inicio de sesión secreto y una contraseña? Mantenlo simple.

Aunque muchos no estarán de acuerdo, mantengo que un nombre de usuario es más seguro para iniciar sesión que una dirección de correo electrónico:

1) No hay ninguna razón para no hash el nombre de usuario en la base de datos de la misma manera que deberías hacerlo con la contraseña, por lo que el argumento de crack de la base de datos es discutible

2) La dirección de correo electrónico de una persona es de conocimiento público. Además, es probable que ya esté en manos de los malos ... su carpeta de correo no deseado debería ser una prueba de ello. Dos secretos son mejores que uno.

3) Se debe alentar a las personas a usar un administrador de contraseñas para que no elijan contraseñas débiles O nombres de usuario débiles. Si se puede recordar fácilmente, ¿qué tan seguro puede ser?

4) Los sitios que desafortunadamente requieren correos electrónicos, ya que los inicios de sesión son una muy buena razón para tener correos electrónicos de "inicio de sesión" específicos del sitio que reenvíen a su correo electrónico real. Y nuevamente, un administrador de contraseñas puede tratar estos nombres de usuario, automatizando la tarea de mantener todo en orden. Además, si no captan el correo electrónico como un campo separado, sabrá con precisión quién filtró su dirección de correo electrónico de inicio de sesión a quién.

5) Un nombre de usuario, debidamente protegido, es potencialmente más confiable, ya que las personas pueden perder el control de una dirección de correo electrónico específica.

Si tiene un uso adecuado de HTTPS y otros mecanismos de seguridad, en términos de seguridad no habrá mucha diferencia. Pero si los nombres de usuario son demasiado complejos, los usuarios pueden intentar escribirlos en notas adhesivas y colocarlos en el escritorio (probablemente con contraseñas). Así que ve con uno menos complejo.

Si puede usar la autenticación de dos factores, eso mejoraría enormemente la seguridad.

Pregunta antigua, pero como la pregunta es sobre seguridad y no conveniencia , siento que a todas estas respuestas les falta un aspecto importante: ataques de enumeración . Estoy de acuerdo en que las contraseñas y / u otro segundo factor es lo que se usa para autenticar a los usuarios como usuario 2428118 mencionado anteriormente y no el nombre de usuario / correo electrónico, por lo que no voy a discutir eso en absoluto. Además, en el caso de una violación de la base de datos, ni el nombre de usuario ni el correo electrónico son más o menos seguros, ya que ambos están almacenados en texto sin formato.

Sin embargo, un aspecto de seguridad que no aborda ninguna de estas preguntas es nombre de usuario / email enumeración. En la seguridad de las aplicaciones, nuestro objetivo es minimizar o eliminar el conocimiento que tiene un pirata informático que les ayudaría a ingresar al sistema. Si pueden determinar el nombre de usuario o el correo electrónico utilizado para una cuenta, esa cuenta es menos segura que una cuenta de la que el hacker no tiene conocimiento.

Si usamos nombres de usuario para la autenticación, necesitamos una forma de decirle a un usuario que su nombre de usuario deseado ya está en uso cuando se registran. Esto puede ser explotado por un hacker para determinar si ya existe un nombre de usuario determinado. Eso es algo malo porque si conocen el nombre de usuario, pueden intentar iniciar sesión con las contraseñas más utilizadas de las violaciones de base de datos anteriores. Estas contraseñas comunes están fácilmente disponibles en línea.

Sin embargo, si en cambio usamos direcciones de correo electrónico para la autenticación, al agregar una nueva cuenta y el correo electrónico ya existe, simplemente envíe un correo electrónico de recuperación de contraseña al usuario en lugar de un nuevo correo electrónico de registro. Sin embargo, en la interfaz de usuario, simplemente diga al usuario que revise su dirección de correo electrónico para obtener más instrucciones, pero no da ninguna indicación de si esa dirección es válida o no.

Correo electrónico

• Hacker puede adivinar basándose en su nombre usando [email protected] u otras direcciones de uso común (por ejemplo, [email protected], [email protected], etc.) o completando un formulario web y utilizando la dirección en el respuesta de correo electrónico para intentar la autenticación. Sin embargo, los usuarios generalmente son libres de elegir cualquier dirección de correo electrónico que quieran, incluso direcciones personales, y los usuarios que inician sesión no necesariamente tienen que estar afiliados o empleados por el sitio web en el que inician sesión, por lo que en este caso no tendrían una @empresa. La dirección de correo electrónico .com se registra en el sitio web company.com.
• Los ataques de enumeración se pueden prevenir.

Nombre de usuario

• A veces se muestra en línea (por ejemplo, "This post was created by {{username}} on {{date}}" ), mientras que los correos electrónicos, con suerte, nunca deben mostrarse en texto sin formato.
• Los ataques de enumeración no se pueden prevenir
• Más vulnerables a los ataques de diccionario, ya que las personas suelen elegir nombres de usuario simples (por ejemplo, su nombre).

Bonificación: Dicho esto, otra forma (más difícil) en que un pirata informático puede determinar si existe un nombre de usuario o correo electrónico en el sistema es intentar iniciar sesión y ver los tiempos de respuesta de la página. Las mejores pautas de seguridad muestran que queremos que nuestras contraseñas se hagan con un hash lento, sin embargo, si no existe un nombre de usuario o correo electrónico en la base de datos, no tendremos que verificar el hash de la contraseña porque no hay un usuario coincidente. Si nuestro hash tarda 100 ms en realizarse y la consulta de la base de datos tarda 5 ms, los tiempos de respuesta para una solicitud de un usuario válido serán, en promedio, 95 ms más lentos que un usuario no válido. La forma de solucionar esto es mediante el hash siempre de la contraseña proporcionada, incluso si el usuario no existe en la base de datos, o si el usuario existe, simplemente verifico el hash en la base de datos.