Para los fines de seguridad , hay alguna diferencia en tener un nombre de usuario secreto generado aleatoriamente de 50 caracteres acompañado de una contraseña secreta generada de manera aleatoria de 50 caracteres, frente a un nombre de usuario secreto generado aleatoriamente de 100 caracteres. sin contraseña?
La principal desventaja de la autenticación de un "token" (o "nombre de usuario") es que para autenticar al usuario debe hacer una de dos cosas:
Creo que depende de cómo se define "nombre de usuario". Por lo general, un nombre de usuario es algo que se deriva del nombre del usuario. Así que es adivinable.
Un nombre de usuario a menudo se muestra en la Aplicación en algún tipo de preferencias de usuario . Así que el nombre de usuario es visible.
Luego, a veces se usa un nombre de usuario para restablecer una contraseña y, por lo tanto, el nombre de usuario puede enviarse por cable, tal vez a través de smtp. Por lo tanto, el nombre de usuario se puede obtener del tráfico.
A veces los usuarios necesitan comunicarse entre sí, por lo que el nombre de usuario se convierte en un dato público.
Sin embargo, si piensa en algún tipo de token de autorización como un nombre de usuario, puede tomar una "cadena" de 100 caracteres para autenticar. ¡Pero no pienses en eso como un "nombre de usuario"!
Estás combinando dos conceptos, identidad y autenticación , en una sola entidad. Entonces estás llamando al resultado "nombre de usuario". Este nombre implica incorrectamente al lector que solo está incorporando una identidad, ocultando el hecho de que debe mantenerse en secreto para asegurar el aspecto de autenticación de la misma. Recuerde que la identidad normalmente no es algo que las personas mantengan en secreto.
"Unguessability" es un atributo importante de un secreto utilizado para la autenticación. Pero la seguridad no viene solo por tener un secreto indiscutible. También viene de personas que manejan adecuadamente ese secreto. Al llamarlo así, no se arriesga a confundir a sus usuarios para que traten este secreto como lo harían con su dirección de correo electrónico.
Este no es un problema teórico, es la base de todos los problemas con el robo de tarjetas de crédito que el mundo sufre hoy en día. Los números de las tarjetas de crédito siempre se asociaron con la identidad, no con la autenticación, pero sirven para ambos propósitos, haciéndolos valiosos para los ladrones.
Para evitar este problema, no llamaría a la cadena de 100 caracteres ni un "nombre de usuario" ni una "contraseña"; en cambio, llamarlo "token" podría ayudar a las personas a entender cómo manejarlo.
Si no tiene otra forma de autenticación en lugar de contraseñas, no tengo idea de por qué uno solo usaría nombres de usuario para autenticar a los usuarios. Eso sería blad.
* También me gustaría agregar que los nombres de usuario y las contraseñas tienen una relación inconexa cuando se trata de seguridad, y solo se usan juntos para autenticar a un usuario.
El aspecto más importante de las contraseñas es el secreto. Si un nombre de usuario es completamente secreto para todos menos para el usuario, entonces no necesita una contraseña. Si un nombre de usuario se comparte con alguien más, entonces usted lo hace.
Además, tener un nombre de usuario secreto sería una pesadilla de UX: la gente no espera que los nombres de usuario sean secretos y no los tratan como tales.
Si por "nombre de usuario" se refiere a un identificador de cuenta largo generado automáticamente que otros usuarios no pueden ver, y cuando no se necesita un correo electrónico / nombre de usuario para recuperar la cuenta, puede tener sentido. Los ejemplos serían Resent / BitTorrent Sync "indentidades" o claves privadas de criptomoneda. Para los propósitos de esta respuesta, llamaremos a este secreto "contraseña", no "nombre de usuario".
De hecho, si algún servicio permite que el nombre de usuario público se use (junto con una contraseña) para autenticar, entonces esencialmente ya está usando solo un secreto, la contraseña, para autenticar.
Si solo tiene una contraseña para la autenticación, ¿qué sucede si un usuario intenta usar una contraseña que ya está usando alguien? No puede advertir al usuario que "esa contraseña ya está en uso". Para evitar este escenario, la aplicación en sí tendría que generar la contraseña larga y única, y a su vez esto probablemente obligaría al uso de un administrador de contraseñas.
Otro problema es la recuperación de la cuenta: es posible que necesite que el usuario asocie su correo electrónico con su cuenta de todos modos para permitir que se restablezca la contraseña. Si este es el caso, también puede utilizar un nombre de usuario y una contraseña para iniciar sesión.
Lea otras preguntas en las etiquetas passwords password-policy password-cracking