Y a-t-il une raison pour laquelle je ne devrais pas utiliser l'API HaveIBeenPwned pour avertir les utilisateurs des mots de passe exposés?
Il y a beaucoup de discussions sur le vérificateur de mot de passe HaveIBeenPwned qui peut en toute sécurité dire aux utilisateurs si leur mot de passe apparaît dans l'un de leurs fichiers de mots de passe connus.
Cet outil a une API accessible au public derrière lequel les sites Web/applications/etc sont libres d'utiliser pour permettre à leurs utilisateurs de vérifier leurs mots de passe, mais d'après ce que je peux voir toutes les applications répertoriées sont spécifiquement des outils de vérification d'email/mot de passe.
Je n'ai jamais vu ou entendu parler d'un utilisateur saisissant un mot de passe sur un site Web lors de la création d'un compte et cela lui donne ensuite un message d'erreur précisant que le mot de passe choisi peut être trouvé dans une violation de données bien connue.
Si je devais créer un site Web, serait-ce une mauvaise idée de vérifier automatiquement les mots de passe de mes utilisateurs par rapport à l'outil HaveIBeenPwned par mesure de sécurité supplémentaire et de leur demander de choisir un mot de passe dont le site ne connaît pas?
Les dernières recommandations du NIST (SP 800-63b Section 5.1.1.2; voir ici ou ici pour un résumé ) suggèrent en fait de vérifier les mots de passe des utilisateurs par rapport aux listes de mots de passe compromis connus, donc faire exactement cela est en fait conforme aux meilleures pratiques actuelles. C'est aussi bien mieux que d'exiger des mots de passe pour respecter certaines "règles" (contre lesquelles le NIST recommande maintenant). HIBP n'est qu'un moyen (et probablement le plus simple) de le faire dans la pratique. Il suffit d'envoyer les 5 premières lettres du hachage du mot de passe, donc le risque réel pour les utilisateurs est pratiquement nul. Alors oui, n'hésitez pas à le faire si vous le souhaitez.
Quant à savoir pourquoi une organisation particulière pourrait ne pas faire cela, je suis sûr que cela varie énormément d'un site à l'autre, mais je pense que c'est une valeur sûre que cela se résume aux suspects habituels:
- La sécurité est un domaine où beaucoup aiment lésiner, et la mise en œuvre d'un tel système demande des efforts supplémentaires.
- Il faut du temps pour que les nouvelles meilleures pratiques deviennent des connaissances communes pour les institutions
- Il faut encore plus de temps aux institutions pour se familiariser avec les meilleures pratiques
- Chaque fonctionnalité développée a des coûts: de l'argent en termes de temps d'ingénierie pour développer et maintenir, les utilisateurs perdus qui ne comprennent pas ou ne souhaitent pas suivre la règle ( h/t @Woohoojin ), etc. Les organisations peuvent ne pas considérer que les avantages supplémentaires valent le coût.
Pour être honnête, aucun de mes systèmes ne le fait encore, vous pouvez donc m'ajouter à # 3 ou # 4.
L'article # 4 mérite un peu plus de mention. Les coûts de mise en œuvre sont évidents: il faut du temps au développeur pour créer et maintenir une fonctionnalité. Les avantages sont beaucoup plus difficiles à quantifier. Bien sûr, en ce qui concerne les problèmes de sécurité, de nombreuses entreprises font l'erreur de supposer que les avantages sont nuls et donc de lésiner sur la sécurité (voir point # 1). Cependant, c'est une caractéristique dans laquelle les avantages sont probablement faibles. Il y a souvent des coûts réels pour une entreprise liés à la compromission des comptes d'utilisateurs (plus de support client, peut-être l'annulation des transactions, etc ...), mais tant que le compromis est dû aux propres erreurs de l'utilisateur (dans ce cas, par choisir des mots de passe compromis), une entreprise ne verra probablement aucune responsabilité directe et évitera donc probablement des coûts plus importants. En conséquence, des fonctionnalités comme celle-ci peuvent ne pas être utiles à toutes les entreprises à mettre en œuvre - c'est toujours à chaque entreprise de peser par elle-même les coûts et avantages potentiels.
Parce que le coût de le faire n'est pas anodin:
- les personnes qui ne comprennent pas comment fonctionne HIBP supposeront que vous ne gérez pas correctement les mots de passe ( exemple ), et vous devrez faire face aux plaintes et aux critiques erronées.
- vous devrez mettre à jour périodiquement le code lorsque l'API HIBP change, ou le service s'arrête et vous devrez migrer vers un nouveau.
- tout ralentissement ou temps d'arrêt sur HIBP signifiera que votre propre site ralentira. Surtout si vous souhaitez continuer à vérifier les mots de passe existants contre de nouvelles violations.
Plus tard, il est probable qu'une telle fonctionnalité sera attendue d'un site Web qui prétend prendre la sécurité au sérieux. Ensuite, tout le monde le mettra en œuvre car les coûts décrits ci-dessus seront compensés par l'avantage de ressembler à un site Web sécurisé.
Et oui, il y a sont entreprises qui ont déjà implémenté le contrôle HIBP.
Vous n'avez pas mis d'étiquette de pays, ce qui peut influencer ou non ce que vous pouvez faire. Vous semblez cependant être du Royaume-Uni - qui a apparemment une approche plus détendue en ce qui concerne les points ci-dessous.
Vous semblez également vouloir faire la vérification au moment de la connexion - cela rendrait mes commentaires ci-dessous moins utiles.
Cela dit, en prenant l'exemple de la France ou de l'Allemagne, il faut être très prudent en présentant une solution qui suit les activités des utilisateurs. Vous pouvez avoir les meilleures intentions du monde, il y a des gens qui n'apprécieront pas.
Plus précisément, si vous vérifiez les fuites par rapport aux utilisateurs professionnel email, vous allez bien (je suppose que vous travaillez dans la sécurité des informations pour cette entreprise). Vous avez l'obligation de protéger les intérêts de votre entreprise, donc si un e-mail professionnel (et éventuellement le mot de passe associé) est mal utilisé, vous êtes dans le vert.
Soyez prudent en étendant ce contrôle à des activités non professionnelles. Vous voudrez peut-être suggérer aux gens de vérifier eux-mêmes leurs e-mails personnels contre HIBP, mais c'est tout.
YMMV - c'est une position consensuelle que j'ai prise après des millions de discussions avec des experts en droit, en vie privée et en droit du travail; chacun ayant sa propre opinion sur le sujet, je marche donc légèrement.