Clause de non-responsabilité: je suis l'auteur, le créateur, le propriétaire et le mainteneur de Have I Been Pwned et du service Pwned Passwords associé.
Permettez-moi de clarifier tous les points soulevés ici:
L'objectif initial de HIBP était de permettre aux gens de découvrir où leur adresse e-mail avait été exposée dans des violations de données. Cela reste le cas d'utilisation principal du service aujourd'hui et il y a près de 5 milliards d'enregistrements là-dedans pour aider les gens à faire cela.
J'ai ajouté Pwned Passwords en août de l'année dernière après que le NIST a publié un tas de conseils sur la façon de renforcer l'authentification des modèles. Une partie de ces conseils comprenait ce qui suit:
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és, attendus ou compromis. Par exemple, la liste PEUT inclure, mais sans s'y limiter: les mots de passe obtenus à partir de corpus de violation précédents.
C'est ce que Pwned Passwords adresse: le NIST a conseillé "ce que" vous devriez faire mais ne l'a pas fait fournissez les mots de passe eux-mêmes. Mon service aborde la partie «comment».
Maintenant, en pratique, quelle différence cela fait-il? Est-ce vraiment comme vous le dites en ce sens que c'est comme une situation clé sur un million? Eh bien tout d'abord, même si l'était , l'exemple IRL échoue car il n'y a aucun moyen qu'une personne anonyme à l'autre bout du monde puisse essayer votre clé de porte d'entrée sur des millions de porte d'une manière anonyme et rapide. Deuxièmement, la distribution des mots de passe n'est en aucun cas linéaire; les gens choisissent les mêmes conneries encore et encore et cela expose ces mots de passe à des risques beaucoup plus élevés que ceux que nous voyons rarement. Et enfin, le bourrage d'informations d'identification est endémique et c'est un problème vraiment sérieux pour les organisations proposant des services en ligne. J'entends continuellement des entreprises parler des défis qu'elles rencontrent avec les attaquants qui tentent de se connecter aux comptes des personnes avec des informations d'identification légitimes . Non seulement cela est difficile à arrêter, mais cela peut également engager la responsabilité de l'entreprise - cela est apparu la semaine dernière: "Le message de la FTC est clair et net: si les données des clients ont été mises en danger par le bourrage d'informations d'identification, alors être la victime innocente de l'entreprise n'est pas une défense dans une affaire de mise en application " https://biglawbusiness.com/cybersecurity-enforcers-wake-up-to-unauthorized-computer-access-via-credential-stuffing/
Avoir déjà vu un mot de passe lors d'une violation de données n'est qu'un indicateur de risque et c'est un indicateur que chaque organisation utilisant les données peut décider comment gérer. Ils peuvent demander aux utilisateurs d'en choisir un autre s'il a été vu plusieurs fois auparavant (il y a un décompte à côté de chacun), leur signaler le risque ou même simplement marquer silencieusement le compte. C'est une défense avec MFA, anti-automatisation et autres heuristiques basées sur le comportement. Ce n'est qu'une partie de la solution.
Et accessoirement, les gens peuvent soit utiliser le modèle k-Anonymity (disponible gratuitement) via l'API qui contribue largement à protéger l'identité du mot de passe source, soit simplement télécharger l'ensemble des hachages (également disponibles gratuitement) et les traiter localement. Pas de termes de licence, pas d'obligation d'attribution, allez-y et faites de bonnes choses avec :)