Muchas personas han analizado los motivos para no permitir cambios de nombre desde el punto de vista de la seguridad y la comunidad. Sin embargo, hay muchas razones legítimas para permitir cambios de nombre de usuario, incluso si el nombre de usuario está separado del nombre para mostrar , por ejemplo:

• Alguien ha cambiado el nombre de su vida real o el nombre con el que preferirían que lo llamen, debido al matrimonio, a situaciones familiares, a escapar de acoso / acoso / etc, etc.

    

  Incluso en el caso de que sea simplemente un nombre de usuario, tener que usar un nombre antiguo que conlleva un trauma puede promover el trauma. Además, es muy posible que un acosador / acosador conozca las credenciales de inicio de sesión de su objetivo, y poder cambiar ambas partes de la credencial reduce la superficie de ataque; Además, los intentos de monitoreo para iniciar sesión en un nombre de usuario abandonado permiten crear un caso legal contra un agente malo.

• La gente ha decidido avanzar en una transición de género.

    

  Ser forzado a usar el "nombre muerto" de uno, incluso en el contexto de un nombre de usuario privado, también es muy traumático. (Puedo hablar de la experiencia personal en este caso).

• Las personas tienen un nombre de usuario que ya no sienten que les convenga por cualquier motivo.

    

  Esto tiene una menor implicación para los nombres de usuario internos, pero en mi opinión, todavía es mejor errar por el lado de la bondad.

Todos estos son importantes para la comodidad del usuario y, en muchos casos, es probable que las personas simplemente creen una nueva cuenta con el nuevo nombre de todos modos, por lo que también podrían apoyarlo.

Evitar la ingeniería social es ciertamente importante, pero existen enfoques que ayudan a mitigar esto, como varias formas de verificación (como se ve en varias redes sociales), criptografía de clave pública e indicadores de perfil ("el nombre se modificó por última vez hace N meses ; nombre cambiado K veces "). Y, dado que esta pregunta se ha editado para que tenga que ver con nombres de usuarios internos y no con nombres de visualización públicos, esas preocupaciones ni siquiera son pertinentes a la discusión.

Además, tenga en cuenta que muchas de las superficies de ataque proporcionadas por alguien que cambia su nombre de usuario también están presentes para alguien que simplemente está creando una nueva cuenta, y si la opción de cambio de nombre de usuario no está disponible, es probable que el usuario cree una nueva cuenta, posiblemente utilizando la misma contraseña que la anterior y, de lo contrario, hacer cosas que puedan llevar a una seguridad comprometida.

Es una buena idea mantener un registro de auditoría de los cambios de nombre de usuario y no permitir la creación de nuevas cuentas que usen un nombre de usuario usado anteriormente (al menos si el nombre de usuario se usó por última vez en el pasado, por ejemplo, el año), pero no hay razón para que el nombre de usuario deba ser la clave principal utilizada para asociar los datos con la cuenta de usuario en primer lugar, ya que existen propósitos legítimos para un cambio de nombre de usuario y todos los registros de la cuenta se deben normalizar a una ID abstracta abstracta solo en el primer lugar.

Diría que siempre y cuando no puedan cambiar su identificador único. Es decir. pueden cambiar el nombre que muestran, pero ese nombre está vinculado a un número de ID de usuario que no cambia (esto hará que sus DBA también estén más contentos). También me aseguraría de que los usuarios no puedan cambiar su nombre por el nombre antiguo de otro usuario (para ayudar a mitigar el potencial de estafa que Anders está hablando). Por lo tanto, estaría considerando almacenar todos los nombres por los que pasó un usuario en un momento dado.

Podría ser mejor tener una solicitud de cambio de nombre de usuario, para manejar casos legítimos (como el caso del correo electrónico), y no tener un método de usuario automatizable para hacerlo.

  

Actualmente utilizamos su sugerencia con respecto a personas que nos contactan solicitando un cambio, pero no es tan ampliable debido al trabajo manual y nos obliga a pedir respuestas a sus preguntas de seguridad para su verificación.

Eso está definitivamente mal. No solo tiene que hacerlo manualmente, sino que está obligado a dar respuestas de respuesta de seguridad a todas las personas que procesan dichas solicitudes.

Si desea mantener el control, semiautomátelo: deje que el usuario haga todo el trabajo preparatorio, es decir, ingrese el nuevo nombre, escriba su razón (si le importa) y responda la pregunta de seguridad. Ahora, los chicos de la mesa de ayuda solo tienen que conceder o rechazar la solicitud.

En las otras respuestas se han dado muchas razones a favor y en contra de permitir cambios de nombre de usuario. Tenga en cuenta que puede ir por el camino medio: permitir un solo cambio automatizado, por ejemplo, una vez por año. Esto es lo suficientemente generoso para manejar el 99% de las solicitudes, pero lo suficientemente limitante como para evitar la mayoría de los abusos.

Como se mencionó, permitir a los usuarios cambiar fácilmente los nombres de usuario (llamémoslo "mostrar nombre" para desambiguar) hace que sea más fácil para los usuarios esquivar las consecuencias de acosar o estafar a otros usuarios. Si su sitio tiene un aspecto social, tal vez considere si las prohibiciones, bloqueos, informes, historiales de chat, etc. llevarán a cabo un cambio de nombre de usuario (es decir, ¿un usuario sabrá que están hablando con la misma cuenta, aunque el nombre haya cambiado? ).

Otro punto a considerar es el anonimato o problemas de privacidad. Es bastante frecuente que alguien haga una cuenta con su nombre real y luego, por el motivo que sea, se arrepiente de haberle adjuntado su identidad real. A veces, esto se debe a que fueron capturados por acoso escolar, pero a menudo se debe a razones legítimas, así como a compartir datos personales de su vida, o se convierten en víctimas de acoso escolar. Esta pregunta reciente viene a la mente como un ejemplo diferente:

accidentalmente ingresé la contraseña de un sitio web como nombre de usuario para otro sitio web

En este caso, enviar un ticket de servicio para que lo revise un ser humano o permitir un número limitado de cambios en los nombres de las cuentas parece un enfoque razonable.

Estoy un poco sorprendido de que esto no haya sido mencionado. Pero supongo que la razón por la que muchos sitios no le permiten cambiar su nombre de usuario es porque presenta un problema si la información de la cuenta de un usuario es robada ya que el atacante ahora puede cambiar completamente todo en la cuenta.

Sin duda, es más complejo tratar de recuperar una cuenta para un individuo donde sus detalles han sido robados y todo ha sido cambiado por completo. Tener la información común que nunca cambiará facilita que un usuario vuelva a consultar su cuenta en caso de que pierda el acceso a ella.

Creo que algunas de las otras respuestas aquí han brindado mejores soluciones, pero no estoy seguro de que muchas de ellas se refirieran a lo que realmente preguntabas sobre las implicaciones de seguridad de permitir un cambio de nombre de usuario.     

Argumentaría que es mejor no permitir que los usuarios cambien sus nombres de usuario, pero realmente depende de su modelo de amenaza. Aquí están los pros y amp; contras a permitirlo:

Pros:

• Si las credenciales de un usuario se ven comprometidas en otro sitio, permitir que los usuarios cambien su nombre de usuario puede hacer que sea más difícil hacer coincidir las credenciales del sitio comprometido con su sitio, haciendo que sea más difícil realizar un ataque de relleno de credenciales. Tenga en cuenta que el usuario que cambia su contraseña cumple el mismo objetivo.

Contras:

• Como se mencionó anteriormente, hace que sea más fácil para los usuarios realizar ataques de ingeniería social entre ellos en su sitio.
• Ha agregado complejidad a su sitio, lo que a su vez aumenta la cantidad de posibles errores de seguridad. Por ejemplo, si comprueba si hay duplicados, ahora tiene una vulnerabilidad de enumeración de usuarios.

Básicamente, estás equilibrando dos problemas de la competencia con un tercer factor. La primera es la seguridad para los usuarios de tu sitio. Cambiar un nombre de usuario es una forma fácil de engañar a otras personas para estafarles. La segunda es que cambiar un nombre de usuario es una manera fácil de engañar a otras personas para alejarse de ellos.

Las personas que son acosadas prefieren cambiar su nombre de usuario ya que es un indulto inmediato. A las personas que acosan a otros les gustaría cambiarlo como puede obtener con las defensas iniciales. Y el otro factor es que más partes móviles significa más cosas que golpear significa menos seguras.

Tu primer curso de acción debería ser decidir de qué manera te apoyas aquí. ¿Se está enfocando en prevenir a los estafadores o está tratando de hacer que el ambiente sea lo más seguro posible? Teniendo en cuenta que crear un entorno seguro podría significar no automatizar un cambio, y existen otras razones para cambiar un nombre de usuario, tanto bueno como malo. Eso es para que lo averigües en función de lo que sabes de tu sitio. El segundo paso sería determinar si puede o no realizar una implantación segura para esto.

En este punto es un diagrama de flujo. ¿Prefiere automatizarlo, pero no puede hacerlo de forma segura? No lo hagas ¿Tienes algún problema con los estafadores y otros ataques de ingeniería social? No lo hagas ¿Desea facilitar el cambio y puede implementarlo de forma segura? Hazlo.

Observaría que, como han sugerido otros, hacer un seguimiento de los nombres de usuarios es una buena idea, incluso si está oculto y solo está disponible para usted (idealmente oculto si los cambios son por razones de seguridad) y aumentar la verificación de disponibilidad del nombre de usuario hasta las tres últimas. los nombres de usuario en todo el sitio serían útiles (y algo más para asegurar).

Finalmente mencionaste escalabilidad. A medida que aumenta la escala, se vuelve más fácil (más barato) automatizar las cosas que no puede hacer por razones de seguridad y defenderse de los ataques de otra manera, vea Twitter para ver un ejemplo de eso. Si llega a ese punto y luego se automatiza, cuanto antes mejor.

En mi experiencia, permitir un cambio de nombre de usuario donde no se planeó originalmente hace que la auditoría / registro sea un poco más difícil, especialmente en las circunstancias inevitables donde un desarrollador de años atrás decidió agregar el nombre de usuario pero no la clave principal para cada uno. entrada de registro.

Sucede, especialmente cuando contrata desarrolladores aficionados / subcontratados: sus registros se convertirán en basura que tendrá que reconstruir de forma forense mediante la referencia cruzada manual de fechas si sus entradas de registro no asignan el nombre de usuario a la clave principal original en el momento de la actividad.

Por lo tanto, antes de habilitar esto, le recomendaría que revise las soluciones de registro que tenga y se asegure de que estén grabando el paquete junto con / en lugar del nombre de usuario para que pueda hacer un seguimiento de la identidad a través de los cambios de nombre de usuario.

En mi opinión, esto es más una cuestión de estrategia o arquitectura que de seguridad ... Siempre y cuando se asegure de mantener un identificador único interno para cada usuario (por ejemplo, un ID único de DB, eso nunca cambiará, pero que no es necesario mostrarlo en ningún lugar), y un historial de modificaciones por usuario, los usuarios deberían poder modificar sus nombres de usuario o inicio de sesión. Si desea mostrar el historial de modificaciones en la página del usuario, depende del propósito y el uso de su software.

Personalmente, siempre encuentro muy molestos los servicios que imponen ese tipo de restricciones arbitrarias ("no puedes cambiar tu nombre de usuario", "no puedes cambiar tu nombre de usuario", "no puedes reutilizar las contraseñas que ya usaste en el pasado", etc.).

Sin embargo, podemos hacer una diferencia entre 3 casos (más el general):

1. software sin conexión

2. servicio de intranet

3. servicio de internet

4. summary

1 - software sin conexión

En el caso de una pieza de software totalmente fuera de línea, los usuarios siempre deben poder cambiar su inicio de sesión. Aquí todo es local, así que no hay razón para prohibir ningún cambio.

2 - servicio de intranet

En el caso de un servicio de intranet, lo más probable es que esperemos que los usuarios tengan una forma fácil de contactar directamente con un administrador.

Tal vez la forma más segura de cambiar el inicio de sesión podría ser un procedimiento manual. Sin embargo, también es posible garantizar una forma segura de automatizar el procedimiento.

Pero, aún así, en mi humilde opinión, los usuarios deberían poder modificar su inicio de sesión, y el inicio de sesión debe ser totalmente independiente de la ID única del usuario.

3 - servicio de internet

En el caso de un servicio en línea, creo que el inicio de sesión debe siempre ser la dirección de correo electrónico del usuario (o, quizás, en algunos casos, un número de teléfono móvil, tan pronto como sea un Servicio de Internet, esperaría que mi usuario tuviera una dirección de correo electrónico y no recomendaría el uso de un número de teléfono).

En ese caso, seguro, los usuarios deberían poder modificar su dirección de correo electrónico cuando lo deseen y, por lo tanto, su inicio de sesión (es decir, su dirección de correo electrónico).

Por supuesto, en ese caso, debe asegurarse de tener un procedimiento adecuado, para asegurarse de que cuando ocurra la solicitud de modificación, haya un mecanismo que permita confirmar que el solicitante es el propietario de la cuenta (correo electrónico de verificación con enlace de confirmación). que tiene una fecha de vencimiento, digamos 24 horas pero, esto depende de su caso).

4 - resumen

• los usuarios siempre deberían poder modificar su inicio de sesión
• la ID única del usuario siempre debe ser independiente del inicio de sesión
• en el caso de un servicio de Internet, evite "inicio de sesión de nombre de usuario", prefiera "inicio de sesión de dirección de correo electrónico", con un procedimiento de validación / confirmación
• en cualquier caso, podría ser una buena idea hacer un seguimiento del historial de modificaciones ... si lo muestra en un "perfil de usuario" o no, depende de su caso de uso específico.

No veo ninguna respuesta que compruebe la pregunta más importante:

¿El nombre de usuario es un secreto en su sitio o no?

Si el nombre de usuario se muestra en una página de perfil de usuario, o como autor en las publicaciones del foro o si se puede buscar en una lista de miembros, no incluye funciones de seguridad. Por lo tanto, cambiarlo o no no tiene ningún significado para la seguridad.

Si el nombre de usuario es un secreto, por ejemplo, tiene un nombre para mostrar diferente o muestra el nombre completo del usuario, pero usa un nombre corto o un alias para iniciar sesión: si el nombre de usuario es un secreto, entonces la seguridad del atacante debe saberlo tanto el usuario como la contraseña para acceder a una cuenta.

Sin embargo, como los usuarios tienden a reutilizar los nombres de usuario y, en general, no los consideran como secretos de la misma manera que lo hacen con las contraseñas, el nombre de usuario es un secreto débil. Tampoco importa un bit en muchos ataques (MtM, keyloggers, phishing, hacks DB, etc.)

Entonces, incluso si su nombre de usuario es un secreto, las ventajas de uso (que se describen en otras buenas respuestas) superan con creces las consideraciones de seguridad.

Si permite a los usuarios utilizar las direcciones de correo electrónico como nombres de inicio de sesión, debe permitirles cambiar su inicio de sesión:

• Si alguien abandona una organización, es posible que pierda el acceso a esa dirección inmediatamente y que la nueva dirección se asigne a otra persona con la misma rapidez . (Después de todo, tuve que cambiar de ISP sin previo aviso cuando se dieron cuenta de que no podían conectar mi nueva casa; las direcciones de correo electrónico estuvieron disponibles para otras personas el mismo día). Incluso si solo utiliza la dirección como nombre de inicio de sesión y nunca para los correos electrónicos reales, este es un vector significativo e innecesario para los ataques de ingeniería social.
• Si les permites cambiar la dirección de correo electrónico que utilizas para enviar correos electrónicos mientras sigues iniciando sesión con la dirección antigua que es confusa, mala UX, y dará lugar a llamadas de soporte.

Necesitamos ver algunas de las opciones posibles:

¿Por qué querría el usuario cambiar su nombre de usuario?
-personalización
-tienen un acosador

¿Por qué quieres que el usuario cambie su nombre de usuario?
-la versatilidad / personalización trae clientes leales

¿Por qué el usuario no quiere que otros usuarios cambien su nombre de usuario?
-la excusa de OG hipster "yo fui el primer soccerkid96 no puede haber otros"
-No puedo pensar en ninguna otra razón

¿Por qué no quieres que el usuario cambie su nombre de usuario?
¿Algún tipo de fraude de identidad? varias cuentas de phishing nombradas después de xXP0rn $ L @ yerXx, el poseedor del récord mundial de puntaje más alto
-podría utilizarse como una puerta trasera para obtener información o posiblemente una vulnerabilidad para la sobrecarga de la base de datos o DDoSing

Para evitar la mayoría de los problemas no deseados, recomendaría un identificador estático único para todas las cuentas (no relacionado con el nombre de la cuenta pública), pagar por el cambio de nombre de usuario, 1 cambio de nombre de usuario por cada 5000 años, etc.

Hay bastantes puntos a favor y en contra.

Por ejemplo, un usuario puede querer cambiar el nombre para evitar que lo reconozcan, porque se dio cuenta de que buscar en Google su nombre de usuario del sitio A muestra su perfil en el sitio B.

Por otro lado, hay un punto sobre no permitir que se cambie, para que las personas puedan reconocerlo nuevamente en su sitio. Piensa en un foro con un troll conocido. La gente sabe cómo manejarlo y no le presta atención. Hasta que cambia su apodo. Por supuesto, esto no es una protección real ya que puede registrar otro nombre de usuario, pero evita el tráfico cambiando el nombre de cada publicación.

Si el apodo es algún tipo de clave principal, no puede permitir que se cambie. Piense en una dirección de correo electrónico o una identificación de Jabber. Algunos sitios todavía permiten cambiar el nombre y debe tener cuidado al hacerlo. Si considera cambiar su apodo de Twitter, es mejor que registre el nombre anterior para evitar asociarse con el nuevo usuario. Ese es un punto para bloquear el nombre de usuario para su uso futuro después de la eliminación de la cuenta también.

Un nombre de usuario es parte del proceso de inicio de sesión, por lo que cambiarlo puede detener un ataque de fuerza bruta. Dependiendo del sitio, incluso sin que el atacante sepa si la contraseña es incorrecta o si no existe todo el usuario.

Al final, creo que un nombre de usuario debe ser único y, probablemente, no se puede cambiar y bloquear después de la eliminación de la cuenta, pero debería proporcionar una forma de definir un nombre para mostrar que se muestre de manera más prominente que el identificador de la cuenta.

Eche un vistazo a SO, que usa identificadores o ICQ antiguos que usan algún esquema numérico. La gente necesita usar el nombre para mostrar en su lista de contactos, porque ¿quién recuerda todos los UIN de sus amigos?

Finalmente tu decisión no necesita ser definitiva. Siempre puedes cambiar al otro modelo. Hacer que los nombres de usuario fijos cambien no debería ser un gran problema, corregir los nombres de usuario cambiantes probablemente necesitará una explicación para sus usuarios.