Question:
Est-il courant de consigner les mots de passe rejetés?
Drew Lex
2012-07-05 03:59:39 UTC
view on stackexchange narkive permalink

Bien que la sélection de mots de passe uniques pour chaque objectif soit une excellente idée, cela se produit rarement en pratique. Par conséquent, beaucoup choisissent des mots de passe dans un pool personnel de mots de passe faciles à retenir. Lors de l'authentification dans des systèmes rarement utilisés, il est très probable qu'un certain nombre de mots de passe de ce pool soient essayés séquentiellement. Sinon, 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, devrait-on commencer à supposer qu'ils sont collectés dans une base de données vendue au plus offrant?

Existe-t-il des instructions de mise en œuvre? Que se passe-t-il généralement avec un mot de passe candidat lorsque celui-ci est rejeté? Sont-ils enregistrés, immédiatement supprimés ou laissés à la traîne jusqu'à ce qu'ils soient ramassés? 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 d'implémentation et des recommandations concernant la façon dont les mots de passe valides doivent être traités, mais vagues concernant les valeurs de mot de passe rejetées.

EDIT↑

Je vais essayer de lister ici les différentes implémentations qui enregistrent les échecs de connexion des identifiants de sécurité afin d'avoir une idée de l'étendue de cette procédure:

Systèmes de gestion de contenu:

Joomla via Journal des échecs de connexion plugin

Ce petit plug-in collecte des journaux sur chaque tentative de connexion infructueuse de l'administrateur de votre site Joomla et envoie un e-mail à propos de chacun d'eux au super administrateur du site avec le nom d'utilisateur, le mot de passe, adresse IP et erreur.

KPlaylist v1.3 et v1.4 - un système PHP gratuit qui rend votre collection musicale disponible via l'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.13.

Lorsqu'un utilisateur anonyme ne parvient pas à se connecter en raison d'une erreur de saisie de son nom d'utilisateur ou de son mot de passe et que la page sur laquelle il se trouve contient une table 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 pour Symantec Reporting Server pourrait être divulgué après une tentative de connexion infructueuse.

Linux: final

OpenSSH via auth-passwd modifié .c; en utilisant PAM via la fonction de surcharge pam_sm_authenticate

EDIT # 2

Il semble qu'il y ait un consensus, et l'enregistrement des mots de passe ratés ou PINS est considéré comme un risque de sécurité sérieux / majeur, néanmoins comme pour autant que je sache, les normes suivantes ne fournissent aucune directive, procédure auditée ou contrôle qui traite spécifiquement de ce risque:

  • PCI-DSS: procédures relatives aux mots de passe traitées dans 8.4. et 8.5. (les mots de passe échoués ne sont protégés que lors de la transmission; après validation, ils ne sont pas considérés comme des mots de passe, donc il n'est pas nécessaire de les protéger)

  • FIPS140-2: authentification adressée dans 4.3 (cycle de vie des données d'authentification ayant échoué partiellement traité)

Lié (à propos d'un cas spécifique, alors que cette question est plus générale): [Les mots de passe doivent-ils être révélés dans un message d'erreur?] (Http://security.stackexchange.com/q/15452)
L'utilisateur doit être retardé et connecté mais pas avec un mot de passe en clair. Vous devez avoir un utilisateur sur un thread ou un contexte distinct pour le faire, ou cela peut geler d'autres utilisateurs dans certains cas.
Connexes: http://security.stackexchange.com/questions/8323/is-it-legal-to-log-passwords-from-failed-logins
@AndrewSmith "_Vous devez avoir un utilisateur sur un fil ou un contexte séparé pour le faire_" pouvez-vous expliquer ce que vous entendez par "contexte"?
J'ai vu des fichiers binaires `ssh` et` sshd` sur des serveurs rootés dans plusieurs instances qui ont été modifiés pour (avec l'installation d'un mot de passe "porte dérobée") enregistrer les mots de passe réussis dans un fichier caché quelque part. J'imagine que ça fait partie d'un kit, puisque je vois le même code partout. Ce qui ne fait que souligner l'importance de ** l'utilisation de clés SSH **.
@tylerl "_Ce qui souligne simplement l'importance d'utiliser les clés SSH_" Un "trojan'ed` ssh` "ne pourrait-il pas divulguer votre clé privée SSH?
@curiousguy Votre clé doit être stockée en toute sécurité sur votre propre ordinateur et non sur votre serveur.
@tylerl Je vois: le serveur est compromis, pas l'ordinateur d'où vous `ssh` (et vous n'utilisez pas le client` ssh` sur le serveur). Quoi qu'il en soit, le `sshd` n'a pas besoin de votre mot de passe pour accéder à tous vos fichiers sur le serveur.
@curiousguy L'implication est que, comme il arrive fréquemment que le même mot de passe soit utilisé sur plusieurs serveurs (pas judicieux, mais néanmoins courant), si le sshd rassemble ces mots de passe, ils peuvent être utiles pour propager l'attaque. L'utilisation des touches ssh minimise votre exposition. Le client ssh sur le serveur est soumis à un cheval de Troie pour la même raison, c'est pourquoi il est déconseillé d'utiliser SSH * depuis * un serveur suspect (ou en fait n'importe quel serveur si cela peut être évité). L'exposition peut être encore limitée en utilisant un agent clé, mais cela vient avec ses propres expositions, donc ...
Cinq réponses:
Mark
2012-07-05 05:19:51 UTC
view on stackexchange narkive permalink

La journalisation de la valeur d'une tentative de mot de passe échouée (texte clair ou autre) semble être un anti-modèle de sécurité. Je n'ai jamais vu une application Web qui fasse cela, et je ne connais aucun service système par défaut tel que SSH qui le fasse 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é

De façon désinvolte, je peux penser à trois raisons pour lesquelles la journalisation de la valeur d'une tentative de mot de passe a échoué idée:

1. Fautes de frappe utilisateur

Il est extrêmement courant que les gens saisissent mal un mot de passe avec un ou deux caractères. L'examen d'un fichier journal des tentatives infructueuses rendrait la plupart de celles-ci faciles à comprendre, surtout si vous pouviez comparer une séquence de tentatives infructueuses avec une authentification réussie.

2. Guess-and-Check

De nombreuses personnes ont deux ou trois mots de passe à parcourir pour tout. Par conséquent, lorsqu'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 le piratage de leurs comptes sur d'autres sites.

3. Log Bloat

Le stockage des mots de passe ayant échoué ne sert à rien pour la grande majorité des services d'authentification en production aujourd'hui. Bien qu'il puisse y avoir des cas extrêmes, pour la plupart des gens, le stockage de ces données gaspille simplement de l'espace disque.

Sur la législation / les normes pertinentes

Je ne connais aucune norme (PCI, HIPAA, etc.) qui traite spécifiquement des procédures de stockage des tentatives de connexion infructueuses, mais je pense que compte tenu des faits ci-dessus, un bon argument juridique pourrait être avancé pour expliquer pourquoi les mêmes normes que s'appliquent également au stockage des mots de passe en général. En d'autres termes, vous pouvez faire valoir un argument juridique selon lequel un mot de passe é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 fait preuve de négligence ou enfreint les normes de l’industrie parce que les mots de passe échoués ont été stockés en texte clair et que les conséquences. Je ne pense pas que cela se terminerait par une décision favorable.

Je suis d'accord avec le PO pour dire qu'il pourrait être utile que les divers organismes de normalisation abordent spécifiquement ce problème (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é.

Sous HIPAA, je crois que vous devez générer un enregistrement d'audit de tentative de connexion échouée (sans informations de mot de passe), mais ils ne disent rien sur la journalisation. Si ce n'est pas dans HIPAA, alors les cadres de mise en œuvre comme IHE l'exigent.
@Oleksi bon point. J'ai mis à jour ma réponse pour spécifier que je voulais stocker la valeur d'une tentative d'accès. Tout logiciel du secteur de la santé doit conserver un journal des tentatives d'accès réussies et infructueuses dans le cadre des contrôles d'audit HIPAA / Utilisation significative. Bien entendu, ce journal ne doit pas inclure les valeurs de mot de passe.
selon le [article:] (http://www.dailymail.co.uk/news/article-1255888/Facebook-founder-Mark-Zuckerberg-hacked-emails-rivals-journalists.html) suggéré par [@dr jimbob ci-dessous ] (http://security.stackexchange.com/a/16839/10923), Facebook collectait la valeur des tentatives de mots de passe infructueuses dès 2004. Il n'y a rien en termes de législation à ma connaissance qui aurait pu les obliger à supprimer cette pratique.
@DrewLex - Facebook est un exemple parfait de ce qu'il ne faut PAS faire en matière de sécurité et de confidentialité.
@Drew Lex - Bien que Facebook ait encore de fréquentes failles de sécurité / violations de la vie privée, je doute qu'ils enregistrent plus de tentatives de mot de passe incorrectes (et l'accusation de businessinsider d'un `` ami '' anonyme selon laquelle Z s'en est vanté n'est pas la preuve que cela s'est réellement produit - les gens mentent). Il semble plus probable qu'un enfant d'université agissant seul fasse quelque chose comme ça (pourquoi ne pas enregistrer les informations pourrait être utile / cool), par rapport à une multinationale d'un milliard de dollars avec de vrais professionnels qui pourraient s'inquiéter de faire des choses qui ne pourraient être utiles que pour faire des choses illégales.
PCI définit le «mot de passe» comme suit:> Une chaîne de caractères qui sert d'authentificateur de l'utilisateur.
Kevin Mitnick faisait un piratage et avait un enregistreur sur un serveur distant. Un administrateur système inexpérimenté ne pouvait pas se souvenir exactement du mot de passe du serveur, donc l'administrateur système a continué à parcourir ses mots de passe (qui étaient tous des mots de passe réseau), facilitant le travail de Kevin en ce sens qu'il n'avait plus besoin de pirater / craquer les mots de passe. Autoriser un programme à enregistrer les mots de passe échoués revient à peu près à faire la même chose
Mon patron voulait au départ que je verrouille un SHA256 du mot de passe échoué dans la table, et j'ai réussi à le persuader de ne pas le faire.Mais je pense qu'il pourrait être utile de stocker un hachage bcrypt + salt du dernier mot de passe échoué et de l'utiliser pour déterminer si le même mauvais mot de passe est retenté (nous avons un cas d'utilisation de l'IoT où les appareils peuvent continuer à essayer de se connecter de manière automatique avecle mauvais mot de passe)
dr jimbob
2012-07-05 10:03:03 UTC
view on stackexchange narkive permalink

Il n'y a aucune raison légitime de consigner les mots de passe en clair pour aucune application; surtout pour une connexion incorrecte. Il peut être enregistré par hasard - j'ai regardé avec désinvolture auth.log à d'autres fins, et j'ai 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) - cependant 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 vous utilisez enregistre chaque mot de passe des tentatives incorrectes. C'est pourquoi c'est une mauvaise idée d'avoir un petit (trois) 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és (é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. Extrait du courrier quotidien::

Cependant, après que d'autres affirmations ont émergé, Zuckerberg est apparemment devenu anxieux que le journal publie une histoire sur lui 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 du personnel de Crimson.

Ensuite, il aurait examiné un rapport d'échec de connexion pour voir si l'un des membres de Crimson avait déjà entré un mot de passe incorrect dans TheFacebook.com.

Également assez pertinent xkcd (imaginez que les comptes malveillants ont également enregistré des tentatives de mots de passe pour augmenter leur taux de réussite).

+1 mentionner simplement le XKCD suffirait à tout expliquer
@dr jimbob - Re "Il n'y a pas de but légitime pour enregistrer des mots de passe en clair pour une application" - qu'en est-il de déterminer si un compte utilisateur est attaqué par la force brute?
@Drew Lex - Vous pouvez (et devriez) enregistrer que quelqu'un a entré un mot de passe incorrect pour le compte d'un utilisateur à partir de l'adresse IP à un moment donné, et éventuellement activer une sécurité supplémentaire (exiger des CAPTCHA, des délais entre les tentatives, bloquer une adresse IP, verrouiller un compte, etc) si les échecs de connexion sont trop fréquents (par exemple, à partir d'environ 5 tentatives consécutives). Mais il n'y a aucune raison légitime de consigner les mots de passe qu'ils tapent réellement.
+1 pour XKCD, il contient toutes les informations nécessaires;)
@drjimbob, J'ai eu cette idée sur laquelle j'ai posé une question, cela peut-il être un point à votre avis? merci http://security.stackexchange.com/questions/66484/temporately-save-failed-logins-password-hashes-for-using-against-brute-force-att
tylerl
2012-07-05 08:22:21 UTC
view on stackexchange narkive permalink

Il n'est pas rare de consigner le fait qu'une tentative d'authentification a échoué et à quel utilisateur elle était destinée. Cela peut s'avérer très utile pour 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 n'ont aucune utilité et peuvent être utilisées contre vous.

MODIFIER
Vous devriez, espérons-le , être en mesure de vous attendre à ce qu'un -une entreprise organisée ne vendrait pas vos informations de mot de passe car cela serait vraiment mauvais pour eux si elles étaient découvertes. Mais dans l'intérêt de votre propre sécurité, vous devez toujours être prêt à ce que les informations que vous communiquez soient utilisées contre vous car c'est toujours une possibilité. Cela est double pour toute organisation dont vous ne pouvez pas établir la réputation de manière fiable.

+1 J'ai ajusté ma réponse pour préciser que je voulais dire consigner la valeur en texte clair d'une tentative de mot de passe. J'ai également mis à jour avec une référence à votre réponse sur les méta-informations utiles à des fins d'audit / d'enregistrement.
OnTheShelf
2012-07-11 00:17:13 UTC
view on stackexchange narkive permalink

Il y a des réponses formidables ci-dessus, il ne s'agit donc que d'une perspective rapide et simplifiée des politiques du gouvernement américain sur la gestion des systèmes informatiques qui traitent des informations classifiées.

(1) L'ensemble du système informatique doit être protégé selon la norme la plus élevée requise par toutes les données sur cette machine. Cela inclut les journaux stockés sur ou hors de la machine.

Par exemple, si vous mettez intentionnellement ou accidentellement des données «secrètes» sur un ordinateur, CHAQUE partie de cet ordinateur doit maintenant être protégée comme information "secrète". C'est le cas même si vous aviez un ordinateur non classé (comme à la maison par exemple) qui a reçu un email avec des informations classifiées. L'ordinateur entier et tout ce qu'il contient sont désormais classés "secrets".

(2) Les mots de passe de cette machine sont également classés au plus haut niveau de protection requis par toutes les données sur cette machine.

Par exemple, si vous avez des données "secrètes" sur cette machine, quel que soit l'endroit où vous stockez le mot de passe, il nécessite également le même niveau de protection.

Comme appliqué à votre question, quelle que soit la norme que vous appliquez, telle que 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 un 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, alors vous ne pouvez pas avoir de mots de passe en texte clair dans vos journaux.

J'accepte que toute chaîne de caractères saisie via le champ de mot de passe soit considérée comme «données utilisateur» ou «données de mot de passe», que cela s'avère valide ou non. Malheureusement, «mot de passe» est défini comme la chaîne qui valide, ce qui signifie que les valeurs qui ne répondent pas à ces critères ne sont pas considérées comme des mots de passe. Aucune norme ne définit cette définition plus large d'un «mot de passe». [SP800-53] (http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf) est silencieux sur les valeurs de mot de passe ayant échoué.
Toute information qu'un utilisateur revendique comme un jeton de sécurité, même si elle est mal orthographiée, sera traitée comme un mot de passe par toute autorité de régulation compétente. Un gestionnaire de sécurité utilisant un argument selon lequel un utilisateur a déclaré un mot de passe qui ne parvient pas à authentifier l'utilisateur n'a pas besoin de protection au niveau du système doit être retiré de sa position pour faute. Dans la plupart des environnements réglementés, je m'attendrais également à ce qu'ils soient exclus des travaux futurs dans les programmes de sécurité réglementés. Plus important encore, cela les rendrait incroyablement amateurs.
John Haugeland
2012-07-06 05:38:32 UTC
view on stackexchange narkive permalink

Non. Il est courant que les utilisateurs aient un pool de mots de passe et les parcourent en essayant de déterminer lequel est utilisé pour un site donné. La journalisation signifie simplement que lorsque vous êtes compromis, leurs suppléants sont ajoutés au pool de crackers de celui qui vous a frappé.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...