Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 « J'aime »
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 « J'aime »
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 « J'aime »
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 « J'aime »
Cela n’a aucun sens pour moi (d’où le rappel de ce sujet) : une fois qu’un mot de passe est connu pour avoir été craqué (ou trouvé en clair), il est considérablement moins sécurisé. Cela représente une énorme baisse d’entropie, même avec des hypothèses très indulgentes :
- un mot de passe aléatoire de 10 caractères, même avec un jeu de caractères très limité (exemple fictif : uniquement des lettres minuscules : Pr = 1/26^10 = 1/1,4e14)
- un mot de passe qui est connu pour apparaître dans la liste HIBP (Pr = 1/5e8)
Dès qu’un autre l’utilise et qu’il a également été compromis et/ou décodé – différence cruciale.
Quel est le problème pratique à empêcher l’utilisation d’un mot de passe qui n’est apparu que dans une seule liste ? En tant qu’utilisateur, c’est certainement une information que j’aimerais connaître afin d’éviter de réutiliser ce mot de passe. En tant qu’administrateur de site, je ne veux pas que mes utilisateurs utilisent des mots de passe compromis. Cela semble largement valoir le compromis en matière d’utilisabilité.
Non, ce n’est pas une différence cruciale car, statistiquement, tous les mots de passe seront compromis avec le temps.
Rappelez-vous que nous bloquons déjà depuis des années les un million de mots de passe les plus courants, vous êtes donc déjà protégé là où cela compte.
3 « J'aime »
Statistiquement, tous les algorithmes de cryptographie et de hachage seront brisés avec le temps. Dès que les premiers signes indiquent qu’un algorithme est sur le point d’être compromis, nous cessons de l’utiliser.
Pourquoi les mots de passe devraient-ils être différents ? Toute sécurité repose sur un pari : l’entropie utilisée est suffisante pour la tâche donnée, et il y a toujours une hypothèse sous-jacente concernant la durée ou l’intensité de l’attaque que le système peut résister.
Étant donné que vous perdez au moins six ordres de grandeur d’entropie dès qu’un mot de passe apparaît dans une liste (réalistement, probablement plusieurs de plus), cela semble être une décision évidente.
Oui, c’est une situation bien meilleure que celle offerte par de nombreux autres logiciels disponibles aujourd’hui. HIBP reste une amélioration appréciable pour les sites qui souhaitent obtenir des garanties supplémentaires au-delà de cela.
Cela semble être une opportunité pour un bouton « Générer une phrase de passe » via un plugin, si cela est techniquement faisable…
Cela exclurait tout ce qui figure sur la liste des mots de passe compromis, et l’utilisateur pourrait choisir d’en créer un lui-même, avec la liste d’exclusion « basique » de 1 million d’entrées déjà intégrée. La méthode du bouton permet d’éviter d’avoir à expliquer à l’utilisateur les listes de mots de passe compromis et l’entropie, ce dont ils n’ont généralement pas le temps de s’occuper.
Discourse fait déjà un assez bon travail, à mon avis.
Pourquoi générer le mot de passe côté serveur ?
En supposant que l’utilisateur doive le sauvegarder, n’aurait-il pas plus de sens de lui laisser la responsabilité de la génération du mot de passe ? Son gestionnaire d’identifiants préféré le fait probablement déjà.
2 « J'aime »
Parce que cela pourrait être préférable à continuer de leur dire que « apple », « apple1 », « apple 123 », « apple 12345 » ne sont pas acceptables selon la liste des 1 million de mots de passe interdits. Personnellement, je n’attendrais pas vraiment cette fonctionnalité sur Discourse, mais si cela permet de régler la question des mots de passe compromis de manière élégante et laisse la main à l’utilisateur en cas de problème, cela pourrait valoir la peine d’être envisagé.
Et vous suggérez que les gestionnaires de mots de passe côté client généreront des mots de passe comme celui-ci ?
Encourager vos utilisateurs à utiliser un gestionnaire de mots de passe sera bien plus efficace que d’imposer un mot de passe provenant d’un seul site. Ce dernier conduira simplement à ce qu’ils l’utilisent partout ailleurs et accélérera sa compromission.
Réparer la stupidité est plus difficile que de réparer ce qui a été compromis. Proposer quelque chose de similaire à https://www.useapassphrase.com/ permet, selon moi, de donner une opportunité à ceux qui ne s’intéressent pas à l’aspect académique de la chose.
J’ai créé des systèmes utilisés par des dizaines de millions de personnes, et nous avons testé diverses approches concernant les mots de passe, y compris ces règles affreuses exigeant la présence de x et de y.
À moins d’éduquer les utilisateurs sur la gestion des mots de passe, vous ne faites qu’augmenter la probabilité de fatigue liée aux mots de passe, de réutilisation et du redouté « post-it sous le clavier ».
Générer des mots de passe côté serveur crée également un nouveau vecteur d’attaque et une nouvelle surface d’attaque qu’il faut sécuriser. Personnellement, je pourrais très bien me passer de tout cela.
3 « J'aime »
J’aurais pensé que JS générerait une phrase de passe de manière aléatoire côté client, puis la hacherait et la comparerait à une liste. La partie éducative peut être un stub au-dessus de « Créez-moi un mot de passe ». Je ne pense vraiment pas que Discourse doive s’en soucier, mais tant que les gens attribuent à tort leur colère à leur propre comportement envers la marque, cela pourrait valoir la peine d’y réfléchir.
Je pense que votre meilleure option, dans ce cas, est de développer ou de commander un plugin qui fait ce que vous suggérez.
1 « J'aime »
C’est exactement pour cela que ce plugin existe.
J’ai réfléchi à cette question depuis la création de ce plugin, et je finis par être d’accord avec Jeff.
« Compromis » signifie qu’il y a eu quelqu’un, quelque part, qui a imaginé cette phrase et qui l’a ajoutée à « une liste ». Imaginez que quelqu’un crée un outil qui :
- Publie une liste de chaînes de caractères.
- Génère systématiquement et ajoute des chaînes uniques à cette liste.
L’argument de Jeff est que cela signifie qu’à terme, toutes les chaînes seront « non sécurisées » car elles apparaîtront sur une liste publique quelque part – et qu’à la fin, votre « super phrase de passe sécurisée » apparaîtra également sur cette liste en expansion constante.
L’idée même des mots de passe repose uniquement sur une « impossibilité statistique » qu’une personne ne puisse deviner le mot de passe de votre compte. Un attaquant n’a techniquement pas besoin de connaître le mot de passe ; il doit simplement faire une vraiment bonne supposition. Il peut jouer en sa faveur en définissant ce que signifie faire une « bonne supposition » :
- S’il dispose d’une fuite de données, essayez le même mot de passe pour le même compte.
- S’il dispose d’une liste de fuites, essayez les mots de passe que beaucoup de gens utilisent.
Nous avons déjà discuté de la façon dont Discourse est performant pour le point #2 ci-dessus. Je pense que ce que vous visez est le point #1, mais il est plutôt inutile et transforme l’expérience utilisateur en cauchemar d’avoir quelque chose comme cela dans le cœur du système (en supposant que tout mot de passe, non lié au nom d’utilisateur, ne devrait pas être utilisé)… Mais si vous voulez ce que vous décrivez pour votre site, ce plugin est fait pour vous.
4 « J'aime »
Oui. Franchement, c’est un argument terrible car il est complètement déconnecté de toute notion de probabilité, qui est la seule façon correcte de raisonner sur ce sujet.
Heureusement, nous parlons d’un cas limite qui n’apparaît qu’après avoir éliminé les mots de passe les plus couramment utilisés, ce qui constitue déjà une stratégie assez bonne en soi.
1 « J'aime »