Comme mentionné, permettre aux utilisateurs de changer facilement de nom d'utilisateur (appelons-le "nom d'affichage" pour lever l'ambiguïté) permet aux utilisateurs d'éviter plus facilement les conséquences du harcèlement ou de l'arnaque d'autres utilisateurs. Si votre site a un aspect social, demandez peut-être si les interdictions, les blocages, les rapports, les historiques de chat, etc. passeront par un changement de nom d'utilisateur (c'est-à-dire qu'un utilisateur sera conscient qu'il parle au même compte, même si le nom a changé? ).

Un autre point à considérer est l'anonymat ou les problèmes de confidentialité. Il est assez fréquent que quelqu'un crée un compte avec son vrai nom et regrette pour une raison quelconque d'y attacher sa véritable identité. Parfois, c'est parce qu'ils ont été pris au piège de l'intimidation, mais c'est souvent pour des raisons légitimes, comme le partage excessif de détails personnels de leur vie, ou ils sont victimes d'intimidation. Cette question récente me vient à l'esprit comme un exemple différent:

J'ai accidentellement entré le mot de passe d'un site Web comme nom d'utilisateur pour un autre site Web

Dans ce cas, l'envoi un ticket de service à examiner par un humain ou autoriser un nombre limité de changements de nom de compte semble être une approche raisonnable.

Nous utilisons actuellement votre suggestion concernant les personnes qui nous contactent pour demander une modification, mais elle n'est pas aussi évolutive en raison du travail manuel et nous oblige à demander des réponses à leurs questions de sécurité pour vérification.

C'est définitivement faux. Non seulement vous devez le faire manuellement, mais vous êtes obligé de donner des réponses de sécurité à tous ceux qui traitent de telles demandes.

Si vous voulez garder le contrôle, alors semi-automatisez-le: laissez l'utilisateur faire tout le travail préparatoire, c'est-à-dire, remplissez le nouveau nom, écrivez leur raison (si vous vous en souciez) et répondez à la question de sécurité. Désormais, les responsables du service d'assistance n'ont plus qu'à accepter ou refuser la demande.

De nombreuses raisons pour et contre l'autorisation des changements de nom d'utilisateur ont été données dans les autres réponses. Notez simplement que vous pouvez opter pour la voie médiane: autoriser un seul changement automatisé, par exemple, une fois par an. Ceci est suffisamment généreux pour traiter 99% des demandes mais suffisamment limitatif pour éviter la plupart des abus.

Je suis un peu surpris que cela n'ait pas été soulevé. Mais je suppose que la raison pour laquelle de nombreux sites ne vous permettent pas de changer votre nom d'utilisateur est que cela pose un problème si les informations du compte d'un utilisateur sont volées, car l'attaquant peut maintenant tout changer complètement sur le compte.

Il Il est sans aucun doute plus complexe de tenter de récupérer le compte d'un individu où ses coordonnées ont été volées et où tout a été entièrement changé. Le fait de disposer de l'information commune qui ne changera jamais permet à un utilisateur de se référer plus facilement à son compte s'il y perdait l'accès.

Je pense que certaines des autres réponses ici ont fourni de meilleures solutions , mais je ne suis pas sûr que beaucoup d'entre eux aient abordé ce que vous demandiez réellement, à savoir les implications de sécurité de l'autorisation d'un changement de nom d'utilisateur.

Je dirais que vous feriez mieux de ne pas autoriser les utilisateurs à changer leur nom d'utilisateur, mais cela dépend vraiment de votre modèle de menace. Voici les avantages pour & de l'autoriser:

Pros :

• Si les informations d'identification d'un utilisateur sont compromises sur un autre site, permettre aux utilisateurs de modifier leur nom d'utilisateur peut le rendre plus difficile de faire correspondre les informations d'identification du site compromis à votre site, ce qui rend plus difficile l'exécution d'une attaque de bourrage d'informations d'identification. Notez que l'utilisateur qui change son mot de passe atteint le même objectif.

Inconvénients:

• Comme mentionné ci-dessus, il est plus facile pour les utilisateurs d'effectuer des activités sociales l'ingénierie d'attaques les unes contre les autres sur votre site.
• Vous avez ajouté de la complexité à votre site, ce qui à son tour augmente le nombre de bogues de sécurité potentiels. Par exemple, si vous recherchez les doublons, vous avez maintenant une vulnérabilité d'énumération d'utilisateurs.

Vous équilibrez essentiellement deux problèmes concurrents, avec un troisième facteur. Le premier est la sécurité des utilisateurs de votre site, changer un nom d'utilisateur est un moyen facile de tromper d'autres personnes afin de les arnaquer. La seconde est que changer un nom d'utilisateur est un moyen facile de tromper d'autres personnes afin de s'éloigner d'eux.

Les personnes harcelées aimeraient plutôt changer leur nom d'utilisateur car c'est un sursis immédiat. Les gens qui harcèlent les autres aimeraient le changer comme vous pouvez le faire par les défenses initiales. Et l'autre facteur est que plus de pièces mobiles signifie plus de choses à frapper signifie moins de sécurité.

Votre premier plan d'action devrait être de décider de quelle manière vous vous penchez ici. Vous concentrez-vous sur la prévention des fraudeurs ou essayez-vous de rendre l'environnement aussi sûr que possible? Garder à l'esprit que créer un environnement sûr peut signifier ne pas automatiser un changement, et il existe d'autres raisons de changer un nom d'utilisateur, à la fois bonnes et mauvaises. C'est à vous de le découvrir en fonction de ce que vous savez de votre site. La deuxième étape serait de déterminer si vous pouvez ou non effectuer une implantation sécurisée pour cela.

À ce stade, c'est un organigramme. Vous préférez l'automatiser, mais vous ne pouvez pas le faire en toute sécurité? Ne fais pas ça. Vous avez un problème avec les escrocs et autres attaques d'ingénierie sociale? Ne fais pas ça. Vous voulez faciliter le changement et pouvez le mettre en œuvre en toute sécurité? Faites-le.

Je note que, comme d'autres l'ont suggéré, garder une trace des noms d'utilisateur est une bonne idée même s'ils sont cachés et disponibles uniquement pour vous (idéalement cachés si les changements sont pour des raisons de sécurité) et augmenter le nom d'utilisateur le contrôle de disponibilité pour durer environ trois noms d'utilisateur sur le site serait utile (et quelque chose d'autre à sécuriser).

Enfin, vous avez mentionné l'évolutivité. À mesure que vous évoluez, il devient plus facile (lire moins cher) d'automatiser les choses que vous ne pouvez pas faire pour des raisons de sécurité et de vous défendre contre les attaques d'une autre manière, voir Twitter pour un exemple de cela. Si vous atteignez ce point, automatisez-vous, le plus tôt sera le mieux.

D'après mon expérience, autoriser un changement de nom d'utilisateur là où il n'était pas prévu à l'origine rend l'audit / la journalisation légèrement plus difficile, en particulier dans le cas inévitable où un développeur d'il y a des années a décidé d'ajouter le nom d'utilisateur mais pas la clé primaire à chacun. entrée de journal.

Cela arrive, en particulier lorsque vous embauchez des développeurs amateurs / externalisés - vos journaux deviendront des déchets que vous devrez reconstruire de manière légale en croisant manuellement les dates si vos entrées de journal ne correspondent pas le nom d'utilisateur de la clé primaire d'origine au moment de l'activité.

Donc, avant d'activer cela, je vous recommande de consulter toutes les solutions de journalisation que vous pourriez avoir et de vous assurer qu'elles enregistrent le pk à côté / au lieu du nom d'utilisateur afin que vous puissiez garder une trace de l'identité à travers les changements de nom d'utilisateur.

À mon avis, c'est plus une question de stratégie ou d'architecture que de sécurité… Tant que vous vous assurez de conserver un identifiant unique en interne pour chaque utilisateur (par exemple, un identifiant unique de base de données, qui ne changera jamais, mais qui n'a pas besoin d'être affiché n'importe où), et un historique des modifications par utilisateur, les utilisateurs devraient pouvoir modifier leurs identifiants ou noms d'utilisateur. Si vous souhaitez afficher l'historique des modifications sur la page de l'utilisateur dépend du but et de l'utilisation de votre logiciel.

Personnellement, je trouve toujours très ennuyeux les services qui imposent ce genre de restrictions arbitraires ("vous ne pouvez pas changez votre nom d'utilisateur "," vous ne pouvez pas changer votre connexion "," vous ne pouvez pas réutiliser les mots de passe que vous avez déjà utilisés dans le passé ", etc.).

Cependant, nous pouvons faire une différence entre 3 cas ( plus le général):

1. logiciel hors ligne

2. service intranet

3. service Internet

4. résumé

1 - logiciel hors ligne

Dans le cas d'un logiciel hors ligne, les utilisateurs doivent toujours pouvoir modifier leur connexion. Tout est local ici donc il n'y a aucune raison d'interdire tout changement.

2 - service intranet

Dans le cas d'un service intranet, nous nous attendons très probablement à ce que les utilisateurs disposent d'un moyen simple de contacter directement un administrateur.

Peut-être le moyen le plus sûr de changer de connexion pourrait alors être une procédure manuelle. Il est également probablement possible de garantir un moyen sûr d'automatiser la procédure.

Mais, à mon humble avis, les utilisateurs devraient pouvoir modifier leur connexion et la connexion devrait être totalement indépendante de l'ID unique de l'utilisateur.

3 - service Internet

Dans le cas d'un service en ligne, je pense que la connexion doit toujours être l'adresse e-mail de l'utilisateur (ou, peut-être, dans certains cas, un numéro de téléphone portable, cependant, dès qu'il s'agit d'un service Internet, je m'attendrais à ce que mon utilisateur ait une adresse e-mail et je ne recommanderais pas l'utilisation d'un numéro de téléphone).

Dans ce cas, bien sûr, les utilisateurs devraient pouvoir modifier leur adresse e-mail quand ils le souhaitent et, par conséquent, leur identifiant (c'est-à-dire leur adresse e-mail).

Bien sûr, dans ce cas, vous devez vous assurer d'avoir une procédure appropriée, pour vous assurer que lorsque la demande de modification se produit, il existe un mécanisme qui permet de confirmer que le demandeur est le propriétaire du compte (email de vérification avec lien de confirmation qui a une date d'expiration, disons 24h mais cela dépend de votre cas).

4 - résumé

• les utilisateurs doivent toujours pouvoir modifier leur connexion
• l'identifiant unique de l'utilisateur doit toujours être indépendant de la connexion
• dans le cas d'un service Internet, éviter "login username", préférer "email address login", avec une procédure de validation / confirmation
• dans tous les cas, il peut être une bonne idée de garder une trace de l'historique des modifications… si vous l'affichez sur un "profil utilisateur" ou non dépend de votre cas d'utilisation spécifique

Je ne vois aucune réponse vérifiant la question la plus importante:

Le nom d'utilisateur est-il secret sur votre site ou non?

Si le nom d'utilisateur est affiché sur un utilisateur page de profil, ou en tant qu'auteur sur les publications du forum ou est consultable dans une liste de membres, il ne comporte aucune fonctionnalité de sécurité. Par conséquent, le changer ou non n'a aucune signification pour la sécurité.

Si le nom d'utilisateur est un secret, par exemple vous avez un nom d'affichage différent, ou affichez le nom complet de l'utilisateur, mais utilisez un nom court ou un alias à des fins de connexion - si le nom d'utilisateur est un secret, cela affecte la sécurité car un attaquant doit connaître à la fois le nom d'utilisateur et le mot de passe pour accéder à un compte.

Cependant, comme les utilisateurs ont tendance à réutiliser les noms d'utilisateur et ne considèrent généralement pas les noms d'utilisateur comme secrets de la même manière qu'ils le font avec les mots de passe, le nom d'utilisateur est un faible secret. Cela n'a pas non plus d'importance dans de nombreuses attaques (MtM, keyloggers, phishing, hacks DB, etc. etc.)

Donc, même si votre nom d'utilisateur est un secret, les avantages en réponses) l'emportent largement sur les considérations de sécurité.

Si vous autorisez les utilisateurs à utiliser des adresses e-mail comme noms de connexion, vous devez leur permettre de modifier leur identifiant:

• Si quelqu'un quitte une organisation, il risque de perdre immédiatement l'accès à cette adresse et la nouvelle adresse peut être attribuée à quelqu'un d'autre tout aussi rapidement . (J'ai dû changer de FAI sans préavis quand ils ont réalisé qu'ils ne pouvaient pas connecter ma nouvelle maison après tout; les adresses e-mail sont devenues disponibles pour les autres le même jour). Même si vous n'utilisez l'adresse que comme nom de connexion et jamais comme pour les e-mails réels, il s'agit d'un vecteur important et inutile d'attaques d'ingénierie sociale.
• Si vous leur permettez de modifier l'adresse e-mail que vous utilisez pour l'envoi d'e-mails pendant se connectant toujours avec l'ancienne adresse qui est déroutante, mauvaise UX, et conduira à des appels d'assistance.

Il y a pas mal de points pour et contre.

Par exemple, un utilisateur peut vouloir changer le nom pour éviter d'être reconnu car il a remarqué que googler son nom d'utilisateur sur le site A montre son profil sur site B.

D'un autre côté, il y a un point à ne pas autoriser à le changer, afin que les gens puissent le reconnaître à nouveau sur votre site. Pensez à un forum avec un troll bien connu. Les gens savent comment le gérer et ne lui accordent aucune attention. Jusqu'à ce qu'il change de surnom. Bien sûr, ce n'est pas une vraie protection car il peut enregistrer un autre nom d'utilisateur, mais cela évite les abus en changeant le nom de chaque message.

Si le surnom est une sorte de clé primaire, vous ne pouvez pas autoriser le changement il. Pensez à une adresse e-mail ou à un identifiant jabber. Certains sites vous permettent toujours de changer le nom et vous devez faire attention à le faire. Si vous envisagez de changer votre pseudo Twitter, vous feriez mieux d'enregistrer l'ancien nom par la suite pour éviter d'être associé au nouvel utilisateur. C'est un point pour verrouiller le nom d'utilisateur pour une utilisation future après la suppression du compte.

Un nom d'utilisateur fait partie du processus de connexion, donc le changer peut arrêter une attaque par force brute. En fonction du site même sans que l'attaquant sache si le mot de passe est erroné ou si tout l'utilisateur n'existe pas.

En fin de compte, je penserais que le nom d'utilisateur devrait être unique et probablement non modifiable et verrouillé après suppression de compte, mais vous devez fournir un moyen de définir un nom d'affichage qui est affiché plus en évidence que le descripteur de compte.

Jetez un œil à SO, qui utilise des identifiants ou un bon vieux ICQ qui utilise un schéma de numérotation. Les gens doivent utiliser le nom d'affichage dans leur liste de contacts, car qui se souvient de tous les UIN de ses amis?

Enfin, votre décision n'a pas besoin d'être définitive. Vous pouvez toujours passer à l'autre modèle. Rendre les noms d'utilisateur fixes modifiables ne devrait pas être un problème, réparer les noms d'utilisateurs qui étaient modifiables nécessitera probablement une explication pour vos utilisateurs.

Nous devons examiner certaines des options possibles:

Pourquoi l'utilisateur voudrait-il changer son nom d'utilisateur?
-personnalisation
-ils ont un harceleur

Pourquoi voudriez-vous que l'utilisateur change son nom d'utilisateur?
-la polyvalence / personnalisation attire des clients fidèles

Pourquoi l'utilisateur ne voudrait-il pas que les autres utilisateurs changent leur nom d'utilisateur?
-the OG hipster excuse "j'ai été le premier soccerkid96 il ne peut y en avoir d'autres"
-je ne vois vraiment aucune autre raison

Pourquoi ne voudriez-vous pas que l'utilisateur change son nom d'utilisateur?
-some sort de fraude d'identité? plusieurs comptes de phishing nommés d'après xXP0rn $ L @ yerXx, détenteur du record du monde le plus élevé
- pourraient être utilisés comme porte dérobée pour obtenir des informations ou éventuellement comme une vulnérabilité pour la surcharge de la base de données ou le DDoSing

Pour éviter la plupart des problèmes indésirables, Je recommanderais un identifiant statique unique pour tous les comptes (sans rapport avec le nom du compte public), payer pour le changement de nom d'utilisateur, 1 changement de nom d'utilisateur tous les 5000 ans, etc.