Question:
Comment empêcher les correspondances de nom d'utilisateur et de mot de passe lors du changement d'un nom d'utilisateur?
PwdRsch
2016-03-08 01:36:43 UTC
view on stackexchange narkive permalink

Disons que j'ai un système où l'une des exigences de sécurité est d'empêcher les utilisateurs de choisir un mot de passe correspondant à leur nom d'utilisateur. Les noms d'utilisateur ne sont pas sensibles à la casse, mais les mots de passe le sont. Les mots de passe sont stockés par le serveur en utilisant une fonction de hachage sécurisée qui ne peut pas être inversée.

Lorsque le compte est créé, le nom d'utilisateur et le mot de passe sont initialement disponibles en texte clair sur le serveur pour comparaison. Nous pouvons les comparer en mémoire (sans tenir compte de la casse) pour voir s'ils correspondent et demander à l'utilisateur de choisir un mot de passe différent si c'est le cas. Une fois cette vérification effectuée, le mot de passe est haché de manière sécurisée pour le stockage tandis que le nom d'utilisateur est stocké en texte brut. Aucun problème pour répondre à l'exigence ici.

Lorsque l'utilisateur veut changer son mot de passe, ou qu'il est en cours de modification pour lui, le serveur peut récupérer son enregistrement de nom d'utilisateur et le comparer à la valeur de mot de passe nouvellement choisie (encore une fois en ignorant case) pour voir si cela correspond. Aucun problème pour répondre aux exigences ici non plus.

Cependant, le système autorise également les changements de nom d'utilisateur. Au cours de ce processus de changement d'ID, l'utilisateur n'a pas nécessairement fourni son mot de passe en texte clair au serveur. Ils l'ont peut-être fait lors de leur authentification, mais le serveur ne conservera pas ce mot de passe en texte clair au cas où ils décideraient de changer leur nom d'utilisateur. Le mot de passe en clair n'est donc pas disponible pour vérifier la correspondance avec la valeur de nom d'utilisateur nouvellement choisie.

Afin de répondre à nos exigences, le serveur peut utiliser la même fonction de hachage sécurisé pour hacher le nouveau nom d'utilisateur et le comparer au mot de passe haché enregistré. S'ils correspondent, le serveur peut demander à l'utilisateur de choisir un nom d'utilisateur différent. Cependant, puisque le nom d'utilisateur n'est pas sensible à la casse, cette vérification peut échouer lorsqu'elle est vraisemblablement vraie. Si je soumets "PwdRsch1" comme nouveau choix de nom d'utilisateur et que mon mot de passe est "pwdrsch1", le système l'autorisera puisque les hachages ne correspondent pas. Je - ou pire, un attaquant - pourrais ensuite m'authentifier avec succès avec un nom d'utilisateur et un mot de passe correspondants de "pwdrsch1".

Nous pourrions forcer le nom d'utilisateur en minuscules avant le hachage et le vérifier par rapport au mot de passe, mais alors le scénario inverse est possible. Le nom d'utilisateur serait vérifié comme "pwdrsch1" par rapport à un mot de passe de "PwdRsch1" et autorisé car ceux-ci ne correspondent pas. Mais plus tard, je peux m'authentifier avec succès avec un nom d'utilisateur et un mot de passe correspondants de "PwdRsch1".

Quelles options raisonnables ai-je pour réduire ce risque d'un mot de passe correspondant à un nom d'utilisateur qui n'est pas sensible à la casse?

En fonction du hachage, la force brute peut être possible: étant donné un nom d'utilisateur avec des lettres «N» (à l'exclusion des nombres), l'espace de recherche est seulement «2 ^ N».
Permettre aux utilisateurs de changer leur nom d'utilisateur crée clairement des problèmes pour la gestion de vos mots de passe, et avec la plupart des systèmes sur lesquels je travaille, cela entraînerait d'autres complications. Est-ce vraiment si important? IME la meilleure sécurité vient de la simplicité.
Les noms d'affichage et de connexion séparés sont OK.
Lorsque le nom d'utilisateur est modifié, forcez la réinitialisation du mot de passe.
@DeerHunter J'ai aussi pensé à cela, mais je ne l'ai pas fait dans une réponse, car cela pourrait également ne pas être souhaité (le nom est changé pour une raison après tout). Par exemple, une personne divorcée peut ne pas vouloir saisir le nom de famille de son ex à chaque fois qu'elle se connecte. Donc, si vous faites quelque chose comme ça, des identifiants de connexion sans signification seraient mieux (mais probablement pas non plus, car ils sont plus difficiles à rappelles toi).
Pourquoi n'affichez-vous pas simplement un texte en rouge qui dit "Si votre mot de passe est basé sur votre nom d'utilisateur, il y a de fortes chances que quelqu'un le devine et vole vos informations."? Je soupçonne que cela réglera presque tous les cas. La complexité des mots de passe imposée par programme sans tentative d'éduquer les utilisateurs est cette tradition étrange et non productive. C'est l'une des nombreuses raisons pour lesquelles personne ne comprend les techniques de base pour protéger ses données et pourquoi toutes ces exigences et vérifications existent en premier lieu.
@DeerHunter: c'est vrai mais si quelque chose rend les choses plus difficiles. Si le compte a un nom d'affichage et de connexion distinct et que vous implémentez ce type de mesure, vous voudrez vous assurer que le mot de passe ne correspond à aucun d'eux. Ainsi, même si le nom de connexion ne peut pas changer, le fait que le nom d'affichage puisse changer signifie que nous avons encore ce problème à résoudre (ou échouer / refuser de résoudre, selon le cas).
Les commentaires ne sont pas destinés à une discussion approfondie; cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/36752/discussion-on-question-by-pwdrsch-how-to-prevent-username-and-password-matches-w) .
@user19474 en faisant cela, vous risquez de rendre votre système de hachage de mot de passe beaucoup plus faible car un attaquant qui s'empare des hachages peut attaquer d'abord la version minuscule (espace de recherche beaucoup plus petit), puis en tirer les succès et l'appliquer aux versions complètes des hachages .
@PeterGreen, Je ne comprends pas votre critique. Si quelqu'un change son ID de jsmith en jjones et qu'il est obligé de sélectionner un nouveau mot de passe, quelle est la pertinence des minuscules / majuscules?
Si vous considérez qu'un jeton de connexion est une combinaison d'un nom d'utilisateur + mot de passe. Ensuite, tout changement de nom d'utilisateur ou de mot de passe est un changement dans le jeton de connexion. Et nécessite une vérification IE via un jeton de connexion rempli -> le nom d'utilisateur + mot de passe. J'ai du mal à imaginer un monde où les noms d'utilisateur et les mots de passe sont des entités disjointes, ils sont simplement un jeton public et privé qui, ensemble, forment vos informations d'identification.
Huit réponses:
tim
2016-03-08 01:45:53 UTC
view on stackexchange narkive permalink

Le seul moyen judicieux d'obtenir ce que vous voulez est de demander le mot de passe lorsqu'un utilisateur change son nom d'utilisateur. De cette façon, le serveur dispose toujours des informations nécessaires pour effectuer une comparaison précise entre le nom d'utilisateur et le mot de passe lors d'un changement, et éviter les correspondances.

En tant qu'opérations sensibles - telles que la modification des mots de passe, ou dans votre cas les noms d'utilisateur - devraient exiger un mot de passe de toute façon (pour limiter les dommages de XSS), cela ne devrait pas être un problème.

Votre seule autre alternative est d'essayer toutes les combinaisons de cas possibles, de les hacher et de les comparer au hachage stocké lorsqu'un utilisateur change son nom d'utilisateur.

Je conviens que demander le mot de passe semble être la solution la plus judicieuse face aux changements de nom d'utilisateur gérés par l'utilisateur. Cependant, certains systèmes (par exemple Microsoft Active Directory) permettent aux administrateurs de modifier les noms d'utilisateur sans intervention de l'utilisateur. Dans ces situations, l'obligation pour un utilisateur de fournir son mot de passe n'est pas vraiment compatible. Je soupçonne que votre autre suggestion de hachage de toutes les variations peut être la seule option viable pour répondre à l'exigence. Sinon, nous devrons peut-être accepter le risque qu'un nom d'utilisateur modifié par l'administrateur corresponde à un mot de passe.
@PwdRsch pourquoi un administrateur voudrait-il changer les noms d'utilisateur sans intervention de l'utilisateur? Je ne peux pas imaginer un cas d'utilisation légitime.
Je ne suis pas sûr que ce soit une bonne idée @emory. Nous aurions besoin que quelqu'un qui comprenne vraiment la cryptographie derrière les hachages de mots de passe examine cette idée et détermine que le stockage de plusieurs hachages de mots de passe similaires n'aide pas un attaquant s'il parvient à voler les deux hachages. Mon opinion générale est que le stockage des mots de passe est complexe et qu'il est généralement préférable de s'en tenir à ce qui a fait ses preuves.
Je ne veux pas dire que l'utilisateur ne serait pas au courant du changement de nom d'utilisateur, mais simplement qu'il n'effectuerait pas le changement lui-même. Cela se produit dans les situations où une personne se marie et change de nom de famille, puis son nom d'utilisateur est modifié pour correspondre par le personnel de l'entreprise.
@PwdRsch - Peut-être pouvez-vous faire la vérification uname / password à chaque connexion? Ou lors de la première connexion après un changement de nom d'utilisateur? Cela dit, que diriez-vous de ne pas répondre aux exigences dans ces cas extrêmes? Ils ne semblent guère dignes de s'inquiéter.
@NeilSmithline Je soupçonne qu'ignorer ces cas est ce que la plupart des développeurs de systèmes ont choisi de faire, mais j'étais intéressé à entendre d'autres idées.
@emory soulève un bon point. Si l'administrateur modifie le nom d'utilisateur, que faites-vous si votre politique n'est pas respectée? Vous ne changez pas le nom? Utiliser un nom différent - incorrect -? Cela n'a pas de sens. (lorsque l'utilisateur le change lui-même, vous pourriez exiger un changement de mot de passe, mais laisser l'administrateur changer le mot de passe ne semble pas souhaitable; si c'était le cas, vous pourriez simplement rendre un changement de mot de passe obligatoire et ne pas avoir de problème)
@emory Oui, vous pouvez ajouter des exigences / restrictions de caractères pour vous assurer qu'un nom d'utilisateur ne peut jamais être une valeur de mot de passe valide, ou vice versa. N'hésitez pas à développer cela comme une autre réponse à cette question.
@tim Je pense que vous voudriez probablement forcer un changement de mot de passe par l'administrateur dans cette situation. Ou forcez le verrouillage du compte si cela empêche l'utilisateur de se connecter avec son nom d'utilisateur / mot de passe désormais correspondant jusqu'à ce qu'il termine un processus de validation et change son mot de passe. Ce n'est certainement pas idéal du point de vue de l'utilisateur, mais les changements de mot de passe forcés le sont rarement.
@NeilSmithline J'envisagerais d'écrire vos options de vérification des correspondances lors de chaque connexion ou uniquement des connexions après un changement de nom d'utilisateur comme réponse car cela semble raisonnable et je ne veux pas que cela soit simplement enterré dans les commentaires.
Si l'administrateur change le nom d'utilisateur, vous pouvez définir un indicateur indiquant que le mot de passe doit être changé. Un lien est envoyé à l'utilisateur, notifiant le changement. La toute prochaine fois que l'utilisateur se connecte, le mot de passe doit être changé. Dans mon cas, j'essaie toujours de forcer l'utilisation de paraphrases qui sont bien plus longues que les noms d'utilisateur. Mieux encore, abandonnez le mot de passe et utilisez des clés à la place.
@lepe dans un tel cas, si la base de données a été divulguée, on pourrait simplement rechercher l'existence d'un tel drapeau et il y a probablement un haut niveau de mot de passe en texte clair dans le champ du nom d'utilisateur
@emory un administrateur peut vouloir changer le nom d'utilisateur de quelqu'un si son nom change. L'exemple le plus simple est celui où le nom d'utilisateur est composé, par exemple, du nom de famille et de la première initiale. Cela peut changer lorsqu'une personne se marie et doit donc changer de système. Un utilisateur normal peut alors ne pas être en mesure de modifier son mot de passe. De même, les administrateurs peuvent avoir une pile de demandes à traiter, il peut donc ne pas être pratique de les avoir là pour saisir leur mot de passe au moment du changement de nom d'utilisateur.
Tout à fait d'accord avec @tim et emory: il n'y a pas de cas légitime et - en fait - sensé pour que "pas-un-utilisateur-lui-même" change le nom d'utilisateur et le mot de passe du compte. Si un changement de mot de passe * légitime * se produit, vous pouvez demander l'ancien et le nouveau pass. Si vous souhaitez également modifier un nom d'utilisateur - OK, demandez-en un nouveau, le même formulaire de demande de laissez-passer, juste une ligne supplémentaire.
@gabe3886: Plus précisément, il n'y a aucune raison pour laquelle l'administrateur devrait avoir besoin de connaître le mot de passe de l'utilisateur. Faites simplement vérifier au système à chaque tentative de connexion si le nom d'utilisateur et le mot de passe correspondent, et s'ils définissent le mot de passe pour expirer très bientôt (informer l'utilisateur qu'il sera nécessaire de choisir un nouveau mot de passe est probablement mieux que de mettre sur place).
@Dezza oui, mais généralement un tel indicateur interdit aux utilisateurs de se connecter, quel que soit le mot de passe
@Dezza Je comprends votre point de vue. Pourquoi pensez-vous que c'est une chance «élevée»? Je pense qu'il y a une "faible" chance que le nouveau nom d'utilisateur corresponde au mot de passe précédent. Que diriez-vous de ceci: lorsque le nom d'utilisateur est modifié, le mot de passe est défini sur un mot de passe aléatoire (temporaire) qui sera modifié par l'utilisateur lors du clic sur le lien. En plus des nombreuses alternatives pour vérifier le lien de l'utilisateur, vous pouvez inclure le - ancien hachage de mot de passe - hachage comme paramètre dans le lien. De cette façon, vous pouvez demander l'ancien mot de passe pour définir le nouveau sans laisser l'ancien hachage dans la base de données. Comme l'a dit kw4nta, l'utilisateur ne peut pas se connecter lorsque l'indicateur est activé.
Jason
2016-03-08 20:06:21 UTC
view on stackexchange narkive permalink

Aller à contre-courant un peu - ne se soucie pas de savoir si le nom d'utilisateur est changé en une chaîne "sensiblement similaire" comme mot de passe. Avertissez les utilisateurs du danger de sélectionner le même mot de passe et vérifiez la correspondance identique .

Quel que soit le nombre de règles que vous mettez en place, si l'utilisateur est déterminé, il trouvera un moyen de les contourner. Si vous le devez, demandez le mot de passe lors du changement de nom d'utilisateur afin de pouvoir les forcer à utiliser la même casse, ou laissez-le passer et vérifiez la prochaine fois qu'ils se connecteront et forcer un changement d'utilisateur / de passe.

Le seul moment où l'un de ces éléments est important, c'est si vos utilisateurs sont soumis à une attaque ciblée. Si un enfant de script aléatoire (ou un autre opportuniste) obtient la liste des utilisateurs, ils ont des outils bien plus sophistiqués pour casser ces mots de passe que d'essayer de faire correspondre le nom d'utilisateur. L'attaquant ciblé aussi, d'ailleurs, mais il peut commencer par des choses simples qu'il peut lui-même taper sur le clavier. Et si c'est une personne intelligente qui essaie de casser le mot de passe "PwdRsch1", allez-vous vraiment être sûr de vérifier simplement les différences de cas? Et "pwdr5ch1"? "PwdRsch2"? "1hcsRdwP"? Vous pouvez écrire des règles pour n'importe lequel de ces scénarios auxquels vous pouvez penser, mais soit il y en aura un que vous aurez oublié, soit vous rendrez la sélection d'un combo nom d'utilisateur / mot de passe tellement difficile qu'ils finiront simplement par utiliser "P4ssw0rd!" et en finir.

L'éducation est le seul moyen d'amener vos utilisateurs à utiliser des mots de passe véritablement sécurisés, et il y en aura toujours qui ne seront pas conformes.

Je suis d'accord qu'un utilisateur déterminé peut choisir un mot de passe plus faible que nous pourrions le souhaiter, malgré les règles de politique ou d'autres contrôles que nous utilisons pour éviter les mauvais choix. Cependant, je n'ai pas l'impression que cette exigence (comme indiqué) va trop loin. Associez ce contrôle technique à l'éducation comme vous le suggérez et j'espère que nous bénéficierons des avantages de sécurité des deux. Cependant, ce n'est pas parce que la plupart des attaquants feront des suppositions au-delà d'un mot de passe correspondant au nom d'utilisateur que nous ne devrions pas essayer d'appliquer cette règle. Nous devons encore éliminer les fruits à portée de main.
@PwdRsch Je ne suis pas en désaccord, mon point, je suppose, est que vous n'avez pas besoin de * cacher * ce que vous faites à l'utilisateur - en lui demandant explicitement d'entrer son mot de passe lors d'un changement de nom, ou en exécutant le même vérifier la prochaine fois qu'ils se connecteront après qu'un administrateur a changé de nom, améliore en fait l'éducation car cela leur donne une raison de prêter attention. Cela dit, si un administrateur est capable, essentiellement, * accidentellement * de deviner le mot de passe d'un utilisateur lors de la sélection de son nom d'utilisateur, alors c'est une raison de décharger l'éducation sur l'utilisateur * de toute façon * car c'était un mot de passe horriblement choisi.
PyRulez
2016-03-08 10:09:02 UTC
view on stackexchange narkive permalink

Disons que le nom d'utilisateur contient 10 lettres. C'est 1024 combinaisons différentes de majuscules et minuscules. Vérifiez-les tous.

Ne stockez pas le hachage de mot de passe en minuscules. Ce 1024 peut vous sembler gênant, mais c'est la différence entre un jour et trois ans pour un attaquant.

Selon le hachage et le matériel, cela peut prendre environ une minute. Si un administrateur modifie le nom d'utilisateur, cela peut convenir (s'il est clairement indiqué qu'il s'agit d'un processus lent), si un utilisateur le modifie, une minute peut ne pas être acceptable. Cela peut entraîner des problèmes, par exemple les utilisateurs soumettant à nouveau des formulaires et ne sachant pas avec quel nom d'utilisateur ils ont fini, ou les utilisateurs fermant la fenêtre avant de recevoir le message indiquant que leur nouveau nom d'utilisateur n'est pas acceptable.
@tim Il doit être lent. Sinon, un attaquant qui prend le contrôle du serveur ou possède une réplique du serveur pourrait simplement continuer à essayer de changer le nom d'utilisateur jusqu'à ce qu'il trouve le mot de passe (en pratique, il pourrait faire quelque chose de bien meilleur que le serveur). Vous pouvez échanger la vitesse contre l'espace: https://en.wikipedia.org/wiki/Scrypt
Si * vous * (supposé être un pirate de mots de passe non expert) pouvez le forcer brutalement, un attaquant peut faire de même beaucoup plus rapidement. Si vous * êtes * un pirate de mots de passe expert, vous connaissez déjà la futilité de ce que vous faites.
@Jason, vous n'avez pas besoin de connaître le mot de passe, assurez-vous simplement que le nom d'utilisateur n'est pas le mot de passe.
emory
2016-03-08 02:50:56 UTC
view on stackexchange narkive permalink

Vous devez forcer les identifiants et les mots de passe à provenir d'ensembles différents. Dans les commentaires, il apparaît que l'ID utilisateur doit suivre le nom légal de l'utilisateur selon une formule "John Smith" -> "jsmith" et "Jane Doe" -> "jdoe". Ensuite, si Jane épouse John et prend son nom, alors son identifiant doit changer pour quelque chose comme "jsmith2"

Vous pouvez donc stipuler que le premier caractère d'un mot de passe doit être un symbole ou que le mot de passe doit contenir un symbole.

Si les identifiants sont tronqués à 8 caractères, vous pouvez exiger que les mots de passe contiennent au moins 9 caractères.

Vous pouvez prendre le produit cartésien d'une liste de noms de famille et d'une liste de prénoms et utilisez-les comme liste noire pour les mots de passe. Si un employé a un nom qui ne figurait pas sur votre liste, ajoutez-le et à mesure que les gens changent de mot de passe, le problème se résoudra.

Brenda Utthead aurait une objection colorable à votre politique proposée, surtout si les noms d'utilisateur sont utilisés dans la communication publique.
@DamianYerrick Pour être clair, je crois comprendre que l'OP a une exigence stricte que les userids soient dérivés d'une formule à partir de noms juridiques et ne correspondent pas aux mots de passe. Je pense que les utilisateurs devraient pouvoir choisir leur propre userid qui ne doit pas nécessairement ressembler à leur nom légal. L'objection de Brenda a plus à voir avec les exigences d'OP qu'avec ma politique.
@DamianYerrick dans les commentaires, l'OP a déclaré que si Brenda Smith (userid bsmith, password butthead) épousait Rick Utthead (userid rutthead) et prenait le nom d'Utthead, alors l'administrateur devrait changer l'identifiant de Brenda en butthead mais ce serait un problème car maintenant elle L'ID utilisateur et le mot de passe sont identiques.
@DamianYerrick mais si vous pensez que l'ID utilisateur correspondant au mot de passe n'est pas le gros problème dans le scénario de Brenda, alors je suis d'accord.
@DamianYerrick Cisco Systems a fait cela, et a semblé spectaculairement malchanceux avec leurs noms de personnel, comme Chris Rapherty, Simon Hitchin, etc. Je crois qu'ils ont également tronqué leurs noms d'utilisateur à 8 lettres. Beaucoup d'amusement (en dehors de Cisco) s'en est suivi.
Dewi Morgan
2016-03-08 23:14:19 UTC
view on stackexchange narkive permalink

Ce n'est pas une réponse, je la mentionne uniquement pour que les gens ne le fassent pas .

Vous pourriez décider qu'il serait judicieux de stocker, dans en plus du hachage normal de leur mot de passe sensible à la casse, un hachage de leur mot de passe converti en minuscules.

Cela résoudrait certainement votre problème - vous mettez simplement en minuscules le nom d'utilisateur que vous changez, et comparez-le à ce hachage stocké du mot de passe en minuscules.

L'inconvénient évident est que cela va en partie à l'encontre de l'objectif d'un mot de passe haché en premier lieu: rendre les attaques sur votre liste de mots de passe beaucoup plus difficiles. Un attaquant accédant à vos listes de mots de passe hachés pourrait attaquer le hachage en minuscules beaucoup plus faible (2 ^ n fois plus faible) au lieu du hachage sensible à la casse.

Donc, les autres options mentionnées (demander le mot de passe au moment du changement; essayer toutes les permutations de cas si un administrateur le modifie, idéalement dans l'ordre le plus probable en premier) semble de bien meilleurs paris.

C'était l'une des premières réponses proposées comme une option apparemment bonne que l'affiche a ensuite supprimée une fois que les gens ont répondu aux avertissements que vous avez énumérés. ;) Je suis d'accord que les compromis en matière de sécurité ne valent pas vraiment la peine.
@PwdRsch Oh, merci - je ne savais pas. Cette réponse, pour une fois, je serais parfaitement bien de voir obtenir des votes négatifs non commentés :)
@DewiMorgan Vous pourriez le faire CW ... de cette façon vous ne perdriez pas de représentants pour les votes négatifs.
Ooh, merci, @wizzwizz4, Je ne savais pas ça. Terminé! Se sent un peu ... méchant et exploiteur, cependant :(
YLearn
2016-03-09 04:35:40 UTC
view on stackexchange narkive permalink

Quelques bonnes réponses déjà, mais voici une autre manière d'aborder ce problème. Au lieu d'essayer de comparer le nouveau nom d'utilisateur au mot de passe existant, vous pouvez simplement forcer un changement de mot de passe chaque fois qu'un utilisateur change son nom d'utilisateur.

Naturellement, vous voudriez avertir les utilisateurs que changer le nom d'utilisateur nécessitera de changer le mot de passe, mais vous pouvez alors facilement utiliser n'importe quel processus existant pour vérifier les nouveaux mots de passe par rapport aux noms d'utilisateur.

Omar Kooheji
2016-03-10 00:22:36 UTC
view on stackexchange narkive permalink

Bien que la solution la plus sensée ait déjà été mentionnée et acceptée, à savoir demander le mot de passe lors du changement de nom d'utilisateur, car vous devriez le faire de toute façon. Une alternative est de stocker également le hachage du mot de passe minuscule (avec un sel différent?) Et de comparer le nom d'utilisateur tout en minuscules à cela.

NH.
2017-10-24 00:56:17 UTC
view on stackexchange narkive permalink

Le seul moyen d'empêcher les utilisateurs de choisir des mots de passe stupides est de forcer les politiques de génération de mot de passe (par opposition aux politiques de format de mot de passe terriblement courantes).

Maintenant, si vous n'avez pas autant d'autorité sur vos utilisateurs (la plupart des sites Web n'en ont pas), vous devriez au moins leur dire de générer leurs mots de passe avec un gestionnaire de mots de passe (et de générer leur mot de passe principal avec dés), et vous pourrez peut-être rendre difficile la désobéissance à cette politique:

Une façon de le faire est de faire en sorte que votre champ de mot de passe n'accepte pas la saisie au clavier, mais à la place seulement les données ou la machine -données typées (je recommande de vérifier la vitesse à laquelle les caractères sont saisis). Ensuite, vous pouvez faire en sorte que la boîte expliquant la politique de mot de passe soit encadrée en rouge ou quelque chose pour attirer leur attention dessus.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...