Pas directement lié, mais motivé par Pwned Passwords Validator, car nous examinons actuellement une validation des mots de passe plus stricte.
Discourse ne semble pas bloquer un mot de passe comme myusername123 ou 4myusername pour le nom d’utilisateur myusername.
Je n’ai trouvé aucune discussion antérieure sur ce type spécifique de mot de passe faible. Cela a-t-il déjà été pris en compte ?
Je suis d’accord pour ajouter une vérification lorsque les utilisateurs choisissent un mot de passe : « le mot de passe ne doit pas contenir le nom d’utilisateur en minuscules ». Cela me semble raisonnable.
Nous vérifions déjà que password = username, mais je ne suis pas très fan des tests de sous-chaîne, surtout pour les noms d’utilisateur courts. Et si votre nom d’utilisateur est « Ed » et que votre mot de passe est une chaîne aléatoire qui contient par hasard « ed »…
Utiliser un score de similarité comme la distance de Levenshtein pour rejeter si levenshtein(username, password) < 6 ? Ou même quelque chose pour détecter aussi les permutations, comme ceci :
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
Cela semble couvrir les abus les plus graves, sans empêcher « Ed » de s’inscrire avec un mot de passe long et agréable, et c’est facile à expliquer précisément : « votre nom d’utilisateur et votre mot de passe sont trop similaires ». Je n’ai pas recherché de cas limites indésirables, mais je n’en vois aucun pour le moment.
Tweet connexe d’aujourd’hui :
L’envers de la médaille de règles de plus en plus nombreuses, c’est qu’il devient plus facile de forcer les mots de passe par force brute.
Clairement, aucun mot de passe ne devrait contenir la lettre z répétée 10 fois s’il fait 15 caractères ou moins.
Clairement, aucun mot de passe ne devrait contenir le mot « password ». S’il fait moins de 12 caractères.
Deux mots du dictionnaire l’un à la suite de l’autre, c’est clairement une erreur…
Et ainsi de suite. L’espace de recherche des mots de passe se réduit donc.
C’est un vrai casse-tête. J’ai changé d’avis depuis hier après y avoir réfléchi. Je suis de l’avis de @codinghorror : je ne pense pas qu’il y ait quoi que ce soit à faire ici.
« Il est difficile d’établir de bonnes règles, donc nous ne devrions pas en établir » ?
C’est la deuxième fois en deux jours que je vois des membres de haut niveau de l’équipe Discourse propager de graves idées fausses sur la sécurité. Je pense qu’il y a des points généraux que vous devez réexaminer, et j’espère que vous prendrez cela comme un retour constructif.
De plus, cette suggestion précise ne sort pas de nulle part : nous avons récemment eu un compte utilisateur compromis parce que le nom d’utilisateur était myusername et que le mot de passe était de la forme myusername46.
Il est vrai qu’il s’agissait d’un site ClassicPress (même structure de connexion que WordPress), ce qui le rend beaucoup plus « facile à atteindre » pour les bots, etc. Cependant, c’est précisément ce que les bots recherchent.
Les règles de mot de passe ne peuvent pas empêcher tous les types de mauvais mots de passe, mais elles peuvent faire une grande différence.
Techniquement, nous suivons les directives du NIST 800-63-B :
Lors du traitement des demandes d’établissement et de modification de secrets mémorisés, les vérificateurs DOIVENT comparer les secrets potentiels à une liste contenant des valeurs connues pour être couramment utilisées, attendues ou compromises. Par exemple, la liste PEUT inclure, sans s’y limiter :
- Des mots de passe obtenus à partir de corpus de violations antérieures.
- Des mots du dictionnaire.
- Des caractères répétitifs ou séquentiels (par exemple, « aaaaaa », « 1234abcd »).
- Des mots spécifiques au contexte, tels que le nom du service, le nom d’utilisateur et leurs dérivés.
Ils utilisent explicitement le terme PEUT et non DOIVENT. Cela relève donc de notre discrétion. Il n’y a aucune recommandation concernant la distance de Levenshtein ici. Peut-être que si le nom d'utilisateur fait plus de 6 caractères, il ne doit pas être inclus dans le mot de passe, ou peut-être pourrions-nous ajouter une vérification d’entropie en plus de la liste des 1 million de mots de passe. Je ne sais pas.
Je suppose que si vous êtes très désireux d’avoir vos propres règles ici, vous pouvez exécuter un SSO et appliquer les règles que vous souhaitez de votre côté. Ou bien écrire un plugin.
C’est probablement ce que nous allons faire. Il manque encore certaines choses ici, mais les réponses reçues jusqu’à présent ne me donnent pas l’impression qu’il soit particulièrement utile d’en parler.
Veuillez partager le plugin que vous avez créé avec la communauté ici dans la catégorie #plugin. Tout le monde n’est pas d’accord avec chaque décision que nous prenons ; je respecte pleinement la diversité et les choix. Peut-être que d’autres sont intéressés par des règles de mot de passe plus strictes.