Al suscribirte a un servicio, tienes muchas posibilidades de obtener "Este nombre ya está en uso, elige otro", o algo parecido.

En el sistema que propones, esto te dirá que el código de acceso está en uso. ¡Genial, abre un nuevo navegador e inicia sesión con este código de acceso! Acaba de secuestrar la cuenta de otra persona.

Puedes encontrar cualquier número de códigos de acceso existentes, solo intentando cambiar los tuyos.

Además, ¿qué sucede si olvidó su código de acceso? Esto se puede mitigar si el sistema conoce su dirección de correo electrónico y puede enviarle un nuevo código de acceso, pero entonces estaría cerca de una autenticación de dos entradas; También puede utilizar su correo electrónico para iniciar sesión.

Nombre de usuario es un identificador , una etiqueta que indica qué usuario es usted e identifica qué recursos le pertenecen (o se refieren a usted).

La contraseña es un autenticador , una forma de demostrar que se le permite asumir esa identidad de usuario.

Los nombres de usuario no pueden ser secretos, ya que un sistema de información necesita este conocimiento de manera clara, para etiquetar los recursos y autorizar el uso de los mismos. Las contraseñas deben ser secretas, incluso para el servicio y sus operadores , es por eso que las contraseñas almacenadas se incluyen con una función unidireccional.

Por "recursos" arriba, estoy siendo deliberadamente inclusivo. Para un inicio de sesión de usuario, puede ser archivos y procesos; como usuario de la base de datos, tiene tablas y otros objetos de base de datos; para un sitio web, pueden ser sus publicaciones y puntos de reputación.

Lo usamos en algunos casos.

Un ejemplo es la compartir mediante un enlace de los documentos de Google. El enlace contiene una clave de acceso o ID de documento que tiene una longitud de 45 caracteres alfanuméricos. Esto es lo suficientemente largo como para garantizar la singularidad y dificultar la fuerza bruta.

Este sistema de autenticación de una sola entrada sería interesante, pero existen algunos problemas de seguridad:

El obstáculo clave es el requisito de singularidad. Para que los diferentes usuarios puedan iniciar sesión en sus respectivas cuentas, las credenciales de inicio de sesión (generalmente, nombre de usuario + contraseña) deben ser únicas. En teoría, esto significa que en un sistema típico de doble entrada, los nombres de usuario no necesariamente tienen que ser únicos siempre que no haya dos usuarios que compartan el mismo nombre de usuario y contraseña. El problema es que en un sistema de una sola entrada, la única credencial disponible es la contraseña única, lo que significa que cada usuario debería tener una contraseña diferente que la otra, y esto introduce una serie de vulnerabilidades:

1. Podría suponer que en cualquier servicio suficientemente popular, alguien utiliza una cantidad de contraseñas obvias. Con solo intentar iniciar sesión con contraseñas como "contraseña", "12345" y "Beatles", es probable que pueda acceder al menos a unas pocas cuentas.
2. Como lo menciona S.L. Barth, cualquiera podría encontrar las contraseñas existentes simplemente intentando cambiar su contraseña hasta que se encuentren con un mensaje de "contraseña ya usada". Debido a que las contraseñas tienen que ser únicas, deberías evitar que un usuario elija una contraseña existente, lo que revela que la contraseña ya está en uso.
3. Ataques de diccionario: esto es básicamente la suma lógica de los puntos 1 y 2. Si crea una cuenta y luego hace que un script intente cambiar la contraseña usando un diccionario de contraseñas, registre cada contraseña "ya en uso" que se ejecuta. a lo largo del camino, podría crear rápida y fácilmente una lista de miles o incluso millones de contraseñas existentes, que es todo lo que necesita para ingresar en todas esas cuentas.

Tenga en cuenta que una ventaja interesante además de que salga de esto es que, si bien sería muy fácil dividirse en cualquier número de cuentas al azar (como se describió anteriormente), sería mucho más difícil entrar en cualquier cuenta en un ataque dirigido. Debido a que las contraseñas tendrían que ser únicas, terminaría con contraseñas más complejas en un sistema de una sola entrada que en los sistemas de doble entrada de hoy en día, y no habría un nombre de usuario que pudiera usar para apuntar a un usuario en particular, por lo que la única manera dividirse en una cuenta de destino sería forzar su entrada en todas de las cuentas hasta que obtenga la cuenta que está buscando. Además, sería más difícil confirmar que la cuenta en la que inició sesión es la que está buscando, porque no puede usar el nombre de usuario como prueba de identidad. Ese es un efecto de seguridad muy interesante, así que bravo.

El nombre de usuario es un id, y nunca debe cambiar (*). Las mejores prácticas de seguridad recomiendan cambiar la contraseña regularmente y cada vez que se haya comprometido.

Como esas 2 partes tienen un tiempo de vida diferente, es mejor mantenerlas separadas.

(*) De hecho, hay casos de uso que requieren un cambio en un nombre de usuario, por ejemplo, cuando hay una fusión entre dos entidades y dos usuarios diferentes utilizan el mismo nombre de usuario. Pero la vida útil de un nombre de usuario debe ser mucho más larga que la de una contraseña

Moda de contraseña en su mayoría

y en el pasado habría requerido requisitos adicionales de almacenamiento / procesamiento mucho más baratos ahora.

No hay ninguna razón técnica importante para ello

Un usuario podría iniciar sesión simplemente usando una contraseña segura como "9so48dsf67 $ h9e6ghfoubyf2gfuDywbnefo8g2H3fg2fkngsd6_g3ty7g63gs74g" y el servidor podría coincidir automáticamente con la identidad relevante y asumir con seguridad que era correcto.

Esto es efectivamente lo que hacen Google Docs, etc. al generar una URL de documento compartida.

Simplemente lo usan para acceder al documento que no, para la identificación.

es decir,

No conocen su identidad (no hay nombre de usuario)

Pero la url autentica (es válida en su base de datos)

y también le otorga automáticamente autorización (para ver o editar ese documento)

El sistema podría manejar fácilmente las contraseñas cambiantes / perdidas, los "apodos", las direcciones de correo electrónico, etc.

La gente está MUY acostumbrada a elegir sus propias contraseñas más cortas y menos seguras, lo que haría que este enfoque sea demasiado inseguro para ser práctico

Las personas también están muy acostumbradas al método de "inicio de sesión" + "contraseña" y necesitarían una capacitación significativa para comprender y confiar en una alternativa.

Wikipedia dice lo siguiente acerca de la autenticación:

  

En contraste con la identificación que se refiere al acto de declarar o indicar de otro modo una reclamación que supuestamente atestigua la identidad de una persona o cosa, la autenticación es el proceso de confirmación real de esa identidad .

_{(el énfasis es mío)}

En el mundo real imagina que vas al banco:

1. Usted: Hola, me llamo John Doe y me gustaría abrir una cuenta.
2. Empleado: ¿Me puede proporcionar algún tipo de prueba de su identidad?
3. Usted: (Proporciona una tarjeta de identificación o licencia de conducir)

En el punto uno, te identificaste como John Doe y en el punto tres probaste esa identidad de una manera en que el banco confía. En el mundo real, su identidad fue generalmente decidida por sus padres hace mucho tiempo cuando eligieron su nombre.

En el mundo en línea, los sitios que utilizan el proceso tradicional de registro de dos entradas, le permiten elegir su identidad y también la forma en que prueba esa identidad .

Es cierto que podría intentar fusionar tanto la identidad como la prueba en el mismo dato real, pero ¿existe realmente algún beneficio ? El usuario nombre más otra pieza de datos para usar como prueba ya es comprendido por todos, ya que de alguna manera coincide con la vida real. Además, también hace que la implementación subyacente sea mucho más sencilla, como se indicó en otras respuestas y comentarios.

También es cierto que estar obligado a crear siempre una identidad y una prueba en cada sitio en línea al que visita es algo aburrido . Especialmente teniendo en cuenta que la parte de identidad debe ser única dentro de ese sitio y que eres un adoptante tardío, lo que significa que ya se han seleccionado todas las identidades geniales.

Inicialmente, esto se resolvió aceptando su dirección de correo electrónico como la identidad, de esta manera, el usuario no necesita pensar en ello y la singularidad aún está asegurada.

Sin embargo, algunos incluso van un paso más allá e intentan simplificar aún más el proceso permitiendo lo que se conoce como autenticación sin contraseña. Lo interesante aquí es que no es necesario crear ni una nueva identidad ni una nueva contraseña para probar la identidad.

Un ejemplo de esto es la implementación Auth0 de la autenticación sin contraseña que permite a un usuario autenticarse en un sitio ya sea a través de un enlace proporcionado a través de su dirección de correo electrónico o código de una sola vez proporcionado a través de un SMS .

  

Las conexiones sin contraseña en Auth0 permiten a los usuarios iniciar sesión sin la necesidad de recordar una contraseña. Esto mejora la experiencia del usuario , especialmente en aplicaciones móviles, ya que los usuarios solo necesitarán una dirección de correo electrónico o un número de teléfono para registrarse en su aplicación.

     

Sin contraseñas, su aplicación no tendrá que implementar un procedimiento de restablecimiento de contraseña y los usuarios evitan la práctica insegura de usar la misma contraseña para muchos propósitos .

_{(el énfasis es mío)}

Desde la perspectiva del usuario, esto es muy sencillo de realizar y desde la perspectiva del sitio con este tipo de autenticación, es posible que aún sea posible identificar a los usuarios recurrentes al hacer coincidir su dirección de correo electrónico o número de teléfono.

Si lo piensas, esto es simplemente simplificar lo que solían hacer muchos usuarios. Yo, por ejemplo, admito que muchas veces que quería autenticarme en un sitio nuevo solo usaría mi dirección de correo electrónico y una contraseña aleatoria que nunca recordaría y, en la eventualidad de que mi navegador perdiera la sesión o la contraseña almacenada, lo haría. solo restablece la contraseña.

_{Divulgación : trabajo en Auth0.}

La autenticación basada en certificados PKI es algo así como un ID de usuario y contraseña en uno.

firmar la clave pública

PKI

Esto no es realmente factible con las contraseñas. Esto es factible con cualquier esquema donde la clave / secreto / credencial / token / lo que sea se almacene en la computadora de un cliente y no dentro del cerebro humano.

¿Enrollado? Cambie exactamente lo mismo: si tiene una clave / secreto / credencial / token suficientemente aleatorio y suficientemente complicado, ni siquiera tiene sentido pedirle a un humano un nombre de usuario , un apodo, un GUID, cualquier otra identificación para una autenticación diaria. El software les dirá todo esto.

Si su software no acepta las cuentas de suckpuppet . (Algunos son bienvenidos. Por ejemplo, ssh está contento con "sockpuppets", cuentas diferentes utilizadas por un humano; solicita el nombre de la cuenta incluso si proporciona una clave RSA. Sockpuppet RSA claves privadas sentadas una junto a otra en el mismo dispositivo serían complicación innecesaria, no más seguridad.) Pedir un apodo es la forma más sencilla de admitir sockpuppets.

"Suficientemente complicada" implica que nunca esperamos una colisión . Implica que nunca esperamos una necesidad de saltear . Implica que el humano promedio no puede recordarlo . Y esto implica que no necesitamos los bits adicionales de complejidad de parte del humano recordando el nombre de usuario.

Reinicio de cuenta

El único problema se restablece después de perder la clave o después de que se comprometa. Significa un dispositivo perdido o comprometido. Aquí necesitamos usar una autenticación más segura (también posiblemente una más problemática). ¿Necesitas usuario para recordar su apodo aquí? Si le pide a la usuaria solo el apellido de soltera de una madre, la colisión es casi segura. Eso no significa que necesite un apodo, ¡significa que la autenticación del apellido es demasiado débil! Todos los ataques serían sobre el apellido de soltera de las madres pobres. Pero es probable que deba solicitar algún identificador global fuera de la aplicación, probablemente un número de teléfono móvil para la verificación de SMS (esto excluye la amenaza de que un atacante controle su teléfono móvil).

El esquema alternativo es la verificación por correo electrónico, que también requiere un identificador global fuera de la aplicación (esto excluye la amenaza de que un atacante controle cualquier dispositivo, por lo que es muy débil en esta configuración).

Observe que, en la mayoría de los casos, los humanos no necesitan recordar su identificador global, pero a veces necesitan ir a revisarlo e ingresarlo manualmente.

El esquema alternativo es la verificación en papel precompartida: pídale al usuario que ingrese la contraseña número 04 de la tarjeta en papel que se le envió por correo cuando abrieron una cuenta. Es un caso cuando me parece útil aumentar con una autenticación de "secreto trivial", de modo que casi cualquier persona que obtenga una carta no restablezca el acceso solo por diversión o por pura curiosidad. Podría ser "¿qué código postal usamos para enviar este documento?", Podría ser el temido apellido de soltera, pero también podría usar un apodo.

Contraseñas recordadas por humanos

La contraseña, o un breve texto secreto que podría ser recordado por un ser humano, es un esquema inferior que hace mucho tiempo que está atrasado. Los costos innecesarios asociados incluyen:

• página "por favor, inicie sesión"
• problema "este apodo está ocupado"
• problema "esta contraseña es demasiado débil"
• necesidad de una sal del lado del servidor (actualizar el secreto débil a uno verdaderamente aleatorio para contrarrestar las tablas del arco iris)
• KeePass y bases de datos similares: solución demasiado complicada para un problema simple de obtener un esquema adecuado para funcionar sobre las solicitudes de inicio de sesión anteriores

Todo esto desaparece con el esquema de clave almacenado en la máquina (simétrico o asimétrico, este último sugerido).

No lo usamos porque no es práctico.

Imagina que tienes una gran base de datos de usuarios, por ejemplo, 8 mil millones, porque todos en la tierra usan tu sitio web. Alguien acaba de entregarte su única clave de entrada. ¿Cómo sabes si están en la base de datos?

No puede simplemente almacenar las claves y buscarlas, ya que son básicamente contraseñas de texto simple, y almacenar las contraseñas en texto simple es malo. No se puede simplemente pegar unos cientos de veces con md5 , ya que serías vulnerable a las tablas de arco iris. Necesitas usar un algoritmo de hashing de contraseña adecuado como bcrypt con un gran salt aleatorio.

Ahora tienes una clave y una gran tabla de sales, y necesitas averiguar cuál va con esta clave. Pero si pudiera buscar la sal, ¡podría haber buscado la clave de hash en primer lugar! Estás atascado.

Su única opción es marcar la clave con todos los 8 mil millones de sales, luego buscar en la base de datos 8 mil millones de veces (una vez para cada clave). Mucha gente sugiere que establezca el hash para tomar alrededor de 1/10 de segundo. Imagina que: 8 mil millones de hashes a 1/10 de segundo tardarían 25 años en iniciar sesión.

A menos que sus usuarios sean especialmente pacientes, necesitará una gran cantidad de computadoras para calcular todos esos hashes en paralelo, lo que cuesta mucho dinero, lo que sus clientes deberán pagar, lo que hace que la competencia se vea más atractiva. De lo contrario, tendrá que reducir el factor de trabajo para que los hashes sean fáciles de calcular (y, por extensión, de los atacantes). O tal vez desarrolle hardware especializado que tenga el mismo efecto que reducir el factor de trabajo, ya que puede apostar que los atacantes también lo comprarán.

Todo eso se hace de manera conveniente al hacer que el usuario ingrese un nombre en su lugar. El nombre no es secreto, por lo que se puede almacenar como texto sin formato en la base de datos. Luego, la base de datos puede ordenar sus tablas por nombre para que el servidor pueda buscar de manera eficiente el salt que va con la contraseña del usuario.

Es por eso que probablemente siempre tengamos nombres de usuario de alguna forma u otra: necesitamos una clave de búsqueda para que el proceso de inicio de sesión sea eficiente, y las demandas de las contraseñas de sal y hash hacen que cualquier contraseña, como un mal candidato, sea una mala candidata para la tarea.