Est-il courant de consigner les mots de passe rejetés?
Bien que la sélection de mots de passe uniques pour chaque objectif soit une excellente idée, cela se produit rarement dans la pratique. Par conséquent, de nombreux utilisateurs sélectionnent des mots de passe à partir d'un pool personnel de mots de passe facilement mémorisables. Lors de l'authentification dans des systèmes qui sont rarement utilisés, il est très probable qu'un certain nombre de mots de passe provenant d'un tel pool soient essayés séquentiellement. Alternativement, les mots de passe échoués sont très proches du mot de passe réel en cas de faute de frappe.
Étant donné que presque personne ne décrit la politique de mot de passe en vigueur, y compris la façon dont les mots de passe rejetés sont traités, faut-il commencer par supposer qu'ils sont collectés dans une base de données vendue au plus offrant?
Existe-t-il un guide de mise en œuvre? Que se passe-t-il généralement avec un mot de passe candidat lorsqu'il est rejeté? Sont-ils enregistrés, immédiatement jetés ou laissés traîner jusqu'à la collecte des ordures? Les procédures de gestion des mots de passe ayant échoué font-elles partie des contrôles audités? Il semble qu'il existe de nombreuses exigences de mise en œuvre et recommandations concernant la façon dont les mots de passe valides doivent être traités, mais vague concernant les valeurs de mot de passe rejetées.
[~ # ~] modifier [~ # ~]
Je vais essayer de lister ici les différentes implémentations qui enregistrent les informations d'identification de sécurité de connexion échouées afin d'avoir une idée de l'étendue de cette procédure:
Systèmes de gestion de contenu:
Joomla via Login Failed Log plugin
Ce petit plug-in collecte les journaux de chaque tentative de connexion infructueuse de l'administrateur de votre site Joomla et envoie un e-mail à propos de chacun de ceux-ci au super administrateur du site avec le nom d'utilisateur, le mot de passe, l'adresse IP et l'erreur.
KPlaylist v1.3 et v1.4 - un système gratuit PHP PHP qui rend votre collection de musique disponible via Internet.
enregistre les noms d'utilisateur et les mots de passe des tentatives de connexion infructueuses dans le journal des erreurs Apache
Drupal 5.x avant la version 5.19 et Drupal 6.x avant la version 6.1 .
Lorsqu'un utilisateur anonyme ne parvient pas à se connecter en raison d'une faute de frappe sur son nom d'utilisateur ou son mot de passe et que la page sur laquelle il se trouve contient un tableau triable, le nom d'utilisateur et le mot de passe (incorrects) sont inclus dans les liens du tableau. Si l'utilisateur visite ces liens, le mot de passe peut alors être divulgué à des sites externes via le référent HTTP.
Logiciel autonome
Reporting Server inclus avec Symantec Client Security 3.1 et SAV CE 10.1
Le mot de passe administrateur de Symantec Reporting Server peut être divulgué après l'échec d'une tentative de connexion.
Linux:
OpenSSH via modifié auth-passwd.c ; utilisation de PAM via la surcharge de la fonction pam_sm_authenticate
EDIT # 2
Il semble qu'il y ait un consensus, et l'enregistrement des mots de passe ou des NIP échoués est considéré comme un risque de sécurité grave/majeur, néanmoins pour autant que je sache, les normes suivantes ne fournissent aucune orientation, procédure vérifiée ou contrôles qui traitent spécifiquement de ce risque:
PCI-DSS : Procédures de mots de passe traitées en 8.4. et 8.5. (les mots de passe qui ont échoué ne sont protégés que pendant la transmission; après validation, les mots de passe ne sont pas considérés, il n'est donc pas nécessaire de les protéger)
FIPS140-2 : authentification adressée en 4.3 (cycle de vie des données d'authentification ayant échoué seulement partiellement adressé)
La consignation de la valeur d'une tentative de mot de passe ayant échoué (texte clair ou autre) semble être un anti-modèle de sécurité. Je n'ai jamais vu une application Web qui fait cela, et je ne connais pas de services système par défaut tels que SSH qui le font non plus. Comme indiqué par @tylerl ci-dessous, la plupart des systèmes enregistrent simplement des méta-informations sur une tentative d'accès (par exemple, nom d'utilisateur, heure, peut-être adresse IP, etc.).
Pourquoi cela devrait être un anti-modèle de sécurité
Offhand, je peux penser à trois raisons pour lesquelles la journalisation de la valeur d'une tentative de mot de passe a échoué est une mauvaise idée:
1. Typos utilisateur
Il est extrêmement courant que les gens tapent un mot de passe avec un ou deux caractères. L'examen d'un fichier journal des tentatives infructueuses faciliterait la plupart de ces opérations, en particulier si vous pouviez comparer une séquence de tentatives infructueuses avec une authentification réussie.
2. Devinez et vérifiez
Beaucoup de gens ont deux ou trois mots de passe qu'ils parcourent pour tout. Par conséquent, quand ils oublient le mot de passe qu'ils ont utilisé sur un site donné, ils les parcourent tous jusqu'à ce qu'ils trouvent une correspondance. Cela rendrait trivial de pirater leurs comptes sur d'autres sites.
. Log Bloat
Le stockage des mots de passe défaillants ne sert à rien pour la grande majorité des services d'authentification en production aujourd'hui. Bien qu'il puisse y avoir des cas Edge, pour la plupart des gens, le stockage de ces données est simplement un gaspillage d'espace disque.
Sur les lois/normes pertinentes
Je ne connais pas de normes (PCI, HIPAA, etc.) qui traitent spécifiquement des procédures de stockage des tentatives de connexion infructueuses, mais je pense qu'accordé aux faits ci-dessus, un bon argument juridique pourrait être avancé pour expliquer pourquoi les mêmes normes qui s'appliquent au stockage les mots de passe en général devraient également s'appliquer aux tentatives de mot de passe ayant échoué. En d'autres termes, vous pourriez faire un argument juridique selon lequel un mot de passe ayant échoué est toujours catégoriquement un mot de passe et, en tant que tel, il est soumis aux mêmes normes.
Bien que je ne sois certainement pas avocat, je ne voudrais pas qu'un juge doive décider si j'ai été négligent ou non conforme aux normes de l'industrie, car les mots de passe défectueux ont été stockés en texte clair et les consommateurs en ont subi les conséquences. Je ne pense pas que cela se terminerait par une décision favorable.
Je suis d'accord avec le PO qu'il pourrait être utile que les divers organismes de normalisation abordent spécifiquement cette question (s'ils ne l'ont pas déjà fait). À cette fin, ma suggestion serait de créer une norme de conformité de ne pas stocker du tout la valeur des tentatives de mot de passe ayant échoué.
Il n'y a aucun but légitime à enregistrer des mots de passe en texte brut pour une application; surtout pour une connexion incorrecte. Il peut être enregistré par hasard - j'ai regardé nonchalamment auth.log à d'autres fins, et vu un utilisateur taper accidentellement son mot de passe dans le champ de connexion (et j'enregistre les champs de connexion pour voir quels comptes sont tentés de se connecter) - mais j'en ai informé l'utilisateur et ils ont changé leur mot de passe.
D'un autre côté, en tant qu'utilisateur, l'hypothèse prudente est de dire que chaque application aléatoire que vous utilisez enregistre chaque mot de passe de tentatives incorrectes. C'est pourquoi c'est une mauvaise idée d'avoir un petit (trois) de mots de passe aléatoires que vous parcourez, par rapport à un mot de passe unique pour chaque site géré dans une liste de mots de passe cryptée (éventuellement en utilisant un outil comme keepass).
Sur cette note, Mark Zuckerberg (fondateur de Facebook) a été accusé par businessinsider.com d'utiliser des journaux de combinaisons login/mot de passe (même à partir d'entrées incorrectes) de thefacebook.com (une première version de Facebook) pour pirater les comptes de messagerie des journalistes de Harvard Crimson qui enquêtaient sur lui. Du courrier quotidien: :
Cependant, après l'émergence de nouvelles allégations, Zuckerberg était apparemment inquiet que le journal lui raconte une histoire après tout.
Business Insider a affirmé avoir ensuite raconté à un ami comment il avait piraté les comptes du personnel de Crimson.
Il aurait dit à l'ami qu'il avait utilisé TheFacebook.com pour rechercher des membres qui disaient être des employés de Crimson.
Ensuite, il aurait examiné un rapport d'échecs de connexion pour voir si l'un des membres de Crimson avait déjà entré un mot de passe incorrect sur TheFacebook.com.
Également quelque peu pertinent xkcd (imaginez que les mauvais comptes ont également enregistré des tentatives de mots de passe pour augmenter leur taux de réussite).
Il y a quelques réponses formidables ci-dessus, donc ce n'est qu'une perspective rapide et simplifiée des politiques du gouvernement américain sur la gestion des systèmes informatiques qui traitent les informations classifiées.
(1) L'ensemble du système informatique doit être protégé au niveau le plus élevé requis par toutes les données sur cette machine. Cela inclut les journaux stockés sur ou hors de la machine.
Par exemple, si vous placez intentionnellement ou accidentellement des données "secrètes" sur un ordinateur, CHAQUE partie de cet ordinateur doit maintenant être protégée en tant qu'informations "secrètes". C'est le cas même si vous disposiez d'un ordinateur non classifié (comme chez vous par exemple) qui recevait un email avec des informations classifiées. L'ordinateur entier, et tout ce qu'il contient, est désormais classé "secret".
(2) Les mots de passe de cette machine sont également classés au niveau de protection le plus élevé requis par toutes les données de cette machine.
Par exemple, si vous avez des données "secrètes" sur cette machine, où que vous stockiez le mot de passe, cela nécessite également le même niveau de protection.
Comme appliqué à votre question, quelle que soit la norme que vous appliquez, comme PCI-DSS, NISPOM, etc., vous ne pouvez pas avoir de mots de passe en texte clair dans les journaux si l'exigence est qu'ils soient protégés (tels que hachés et salés) .
Donc, en résumé, si n'importe quel régime réglementaire est appliqué à votre système informatique en question et que ce règlement dit que vous ne pouvez pas avoir de mots de passe en texte clair, vous ne pouvez pas avoir de mots de passe en texte clair dans vos journaux.
Il n'est pas rare de consigner le fait qu'une tentative d'authentification a échoué et pour quel utilisateur elle était destinée. Cela peut s'avérer très utile dans le dépannage médico-légal. Il est extrêmement rare et irresponsable du point de vue de la sécurité de consigner le mot de passe qui a été rejeté. Ces informations ne servent à rien et peuvent être utilisées contre vous.
MODIFIER
Vous vous devriez vous attendre à ce qu'une entreprise réputée et bien organisée ne vende pas vos informations de mot de passe, car ce serait vraiment mauvais pour eux si on le découvrait. Mais dans l'intérêt de votre propre sécurité, vous devez toujours être prêt à ce que les informations que vous fournissez soient utilisées contre vous, car c'est toujours une possibilité. Cela va doubler pour toute organisation dont la réputation ne peut être établie de manière fiable.
Non. Il est courant pour les utilisateurs d'avoir un pool de mots de passe et de les parcourir en essayant de déterminer lequel est utilisé pour un site donné. La journalisation signifie simplement que lorsque vous êtes compromis, leurs remplaçants s'ajoutent au pool de crackers de celui qui vous frappe.