Quels sont les risques de sécurité liés à la journalisation du hachage des mots de passe rejetés?
Selon Est-il courant de consigner les mots de passe rejetés? , je sais que la journalisation du mot de passe en texte brut rejeté est une mauvaise idée, mais qu'en est-il si je stocke la forme hachée des mots de passe rejetés? Je souhaite avoir plus d'informations sur l'échec de la connexion pour l'analyse, par exemple:
Vérifiez s'il s'agit simplement d'une faute de frappe: si un utilisateur échoue souvent à la première connexion avec le même mot de passe haché, mais plus tard, il se connecte avec succès, il s'agit peut-être simplement d'une faute de frappe
Vérifiez s'il y a quelqu'un qui essaie de deviner le mot de passe: certains mots de passe courants, comme 123456 et anniversaire, qui a corrigé le hachage, si ces tentatives existent, la connexion échouée peut être effectuée par des devineurs de mots de passe.
Vérifiez si un utilisateur a un compte alternatif: certains utilisateurs peuvent avoir un compte alternatif mais avec des mots de passe différents, si un utilisateur ne parvient généralement pas à se connecter avec le même hachage, et si le hachage est le même qu'un autre compte mais se connecte avec succès, alors il peut s'agir d'un l'utilisateur essayant de se connecter avec un autre compte mais a oublié de changer de mot de passe.
Ma question est la suivante: la journalisation de la forme hachée des mots de passe rejetés a-t-elle le même problème que la journalisation des mots de passe rejetés en texte brut?
Si correctement haché (c'est-à-dire avec du sel aléatoire et un hachage fort), un mot de passe haché n'est pas réversible et les mots de passe hachés pour différents comptes diffèrent même si les mots de passe sont les mêmes.
Cela signifie que presque aucune des analyses que vous voulez faire ne peut être effectuée avec les mots de passe correctement hachés (c'est-à-dire sel aléatoire) en premier lieu, c'est-à-dire que vous ne gagnez presque rien de la journalisation des mots de passe et tout au plus vous perdez depuis que vous perdez des informations dans des endroits où un attaquant pourrait obtenir un accès plus facile car les journaux ne sont généralement pas considérés comme aussi sensibles que les mots de passe stockés.
Lorsque vous utilisez un hachage simple à la place (sans sel), certaines des choses que vous mentionnez sont possibles au prix d'un vecteur d'attaque accru, car un attaquant peut désormais utiliser des tables de hachage pré-calculées pour inverser vos mots de passe enregistrés.
Vous avez peut-être des idées fausses sur ce que signifie le hachage de mot de passe approprié. Je recommande de lire Comment hacher en toute sécurité les mots de passe? pour avoir une idée de la façon dont le hachage de mot de passe est effectué et pourquoi il est fait de cette façon, mais dans ce qui suit, je vais aborder certaines des idées fausses que vous semblez avoir:
Vérifiez s'il s'agit simplement d'une faute de frappe: si un utilisateur échoue souvent à la première connexion avec le même mot de passe haché, mais plus tard, il se connecte avec succès, il s'agit peut-être simplement d'une faute de frappe
Vous ne pouvez pas vérifier une faute de frappe en utilisant les mots de passe hachés car même un petit changement sur l'entrée entraîne un énorme changement dans la sortie. Vous ne pouvez pas non plus vérifier la faute de frappe dans les mots de passe d'origine car vous ne pouvez pas inverser le hachage pour obtenir le mot de passe pour comparaison. Pour vérifier si le mauvais mot de passe saisi est toujours le même, vous pouvez enregistrer le hachage salé avec le même sel que le mot de passe stocké (correct) comme Jon Bentley l'a suggéré dans un commentaire. Si les journaux sont au moins aussi bien protégés que les mots de passe stockés, cela n'augmenterait que légèrement la surface d'attaque, mais comme je l'ai dit, les journaux ne sont généralement pas considérés comme aussi sensibles que le stockage des mots de passe.
... Certains mots de passe courants, comme 123456 et anniversaire, qui a corrigé le hachage, ...
Le hachage de mot de passe approprié utilise un sel aléatoire pour rendre impossible les attaques utilisant des hachages précalculés avec des mots de passe courants. Cela signifie que le même mot de passe entraîne un hachage différent lorsqu'il est haché, c'est-à-dire que votre supposition que ces mots de passe ont un hachage fixe est erronée. Encore une fois, vous pouvez utiliser les hachages non salés les plus faciles à inverser ici au prix d'une surface d'attaque accrue.
Il pourrait être préférable de faire ce type d'analyse lorsque le mot de passe entré est toujours disponible et de ne consigner que le résultat de cette analyse.
... si un utilisateur ne parvient généralement pas à se connecter avec le même hachage, et que le hachage est le même qu'un autre compte mais se connecte ensuite avec succès, ...
Étant donné que les hachages pour le même mot de passe diffèrent, vous avez besoin du mot de passe entré à l'origine pour effectuer ce type de comparaison. Étant donné que vous ne pouvez pas récupérer cela à partir du hachage enregistré, il n'est pas utile d'avoir le mot de passe haché connecté. Encore une fois, vous pouvez faire ce type d'analyse avec des hachages non salés, mais cela signifierait que tous vos comptes doivent avoir leur mot de passe disponible de manière non sécurisée non salée - ce qui représente une augmentation importante de la surface d'attaque. Vous pourriez probablement faire ce type d'analyse avec des mots de passe salés également, mais vous devriez alors enregistrer les mots de passe nouvellement entrés avec tous les sels que vous utilisez actuellement (c'est-à-dire un pour chaque compte).
Ce n'est pas une pratique courante et va à l'encontre de la sécurité en général. À mon humble avis, aucune des raisons que vous citez n'est assez bonne pour enregistrer les mots de passe hachés. En fait, je ne vois pas de bonne raison de les enregistrer. Vous pourriez rencontrer des problèmes de conformité/législation (PCI par exemple). Les utilisateurs échouent généralement les mots de passe par des fautes de frappe, oubliant quel mot de passe ils ont utilisé pour quel site, etc. Vous aurez également ces mots de passe dans un endroit autre que votre base de données, même un serveur distant si vous utilisez une sorte de journalisation via syslog.
Rien de tout cela n'est une raison pour enregistrer des mots de passe hachés. Pour répondre directement à votre question, il est "préférable" de consigner les mots de passe hachés par rapport à ceux en texte brut, mais les deux sont très mauvais et ne doivent pas être effectués.
Exemple: Une partie de HIPPA se concentre sur la nécessité de protéger de manière adéquate et efficace les informations électroniques sur la santé protégée (ePHI) en respectant les bonnes pratiques et les normes. Selon l'auditeur avec lequel je travaille, la journalisation des mots de passe (hachés ou non) vous laisserait comme non conforme car ce n'est pas une pratique recommandée et standard.
Vous faites de nombreuses hypothèses sur:
- L'utilité de ces actions.
- Le hachage et le stockage des mots de passe sont le seul moyen de réaliser ces actions.
- Même que certaines de ces actions peuvent être glanées à partir d'un mot de passe correctement salé et haché.
Si un utilisateur échoue à la connexion, cela peut être dû à de nombreuses raisons. Par exemple, cela peut être dû au fait qu'ils ont plusieurs mots de passe et les parcourent, se demandant lesquels ils ont utilisé sur le site ... vous êtes maintenant passé du stockage d'un hachage (salé) du mot de passe des utilisateurs pour ce site à potentiellement multiple (salé) ) les mots de passe hachés que l'utilisateur a tendance à utiliser. De même avec les courriels, j'ai plusieurs courriels que j'utilise, je ne me souviens peut-être pas de ceux que j'ai utilisés pour le site. Maintenant, vous stockez mes e-mails pour les corréler (cette partie dépend de votre corrélation du mot de passe avec la logique utilisateur). Fondamentalement, vous créez un recueil de combinaisons de noms d'utilisateur/e-mails et de mots de passe pour un futur adversaire potentiel de votre site. Certaines de vos idées:
"Vérifiez si c'est juste une faute de frappe"
Pourquoi est-ce que tu t'en préoccupes? S'il s'agit d'une faute de frappe, l'utilisateur a fait une faute de frappe et l'a trouvée. Si votre objectif est de développer les empreintes digitales pour indiquer au forçage brutal d'un attaquant, il existe d'autres moyens. Cela n'est également pas possible avec un mot de passe correctement salé et haché. C'est le but même du salage et du hachage, vous, vous-même, ne devriez pas être en mesure de rétroconcevoir ce que le texte brut d'origine était sans effort considérable. Si vous n'avez pas le texte brut et que l'algorithme de hachage est bon, vous ne pourrez pas savoir si une faute de frappe a été faite.
"Vérifiez si quelqu'un essaie de deviner le mot de passe"
Tout d'abord, assurez-vous que les utilisateurs réels n'ont pas ces mots de passe. Deuxièmement, il existe d'autres méthodes. Troisièmement, si vous le vouliez vraiment, vous pouvez en flux hacher l'entrée et la comparer à des hachages de mots de passe faibles connus, si c'est le cas, puis enregistrer qu'elle correspond, il n'est pas nécessaire d'enregistrer le mot de passe sous quelque forme que ce soit.
"Vérifier si un utilisateur a un autre compte"
Sauf si vous avez une raison explicite de le faire, quelque chose qui va à l'encontre de vos conditions, cela n'est pas nécessaire du point de vue de l'utilisateur. De plus, un mot de passe correctement salé et haché ne sera pas immédiatement comparable aux autres enregistrements de votre système. C'est le point de salage, donc les hachages pré-calculés de diverses entrées de texte brut ne peuvent pas être mis en correspondance. Ainsi, si quelqu'un avait le même mot de passe sur deux comptes différents, ce hachage par la notion que le sel qui leur est ajouté est aléatoire, ne correspondra pas malgré tout. Même s'ils correspondaient, il pourrait s'agir d'un utilisateur entièrement différent avec le même mot de passe ou un mot de passe à un caractère (faute de frappe ou variation de mot de passe).
L'idée même viole à peu près toutes les notions de sécurité qui existent. Je ne le recommanderais pas.
réponse de Steffen est parfait, mais je pense qu'il est important de savoir que vous avez d'autres options sans enregistrer les mots de passe hachés. Mes réponses supposent que vous exécutez un site Web externe avec un identifiant. S'il est interne, vous pouvez stocker à peu près tout ce qui concerne l'ordinateur/l'appareil sur lequel ils se sont connectés.
Vérifiez s'il s'agit simplement d'une faute de frappe: si un utilisateur échoue souvent à la première connexion avec le même mot de passe haché, mais plus tard, il se connecte avec succès, il s'agit peut-être simplement d'une faute de frappe
Connectez-vous simplement lorsqu'un utilisateur échoue et réussit. Vous pouvez exécuter des rapports et voir si un utilisateur échoue fréquemment lors de la première connexion.
Vérifiez s'il y a quelqu'un qui essaie de deviner le mot de passe: certains mots de passe courants, comme 123456 et anniversaire, qui a corrigé le hachage, si ces tentatives existent, la connexion échouée peut être effectuée par des devineurs de mots de passe.
Enregistrez les adresses IP des tentatives de connexion. Bien qu'il s'agisse d'une pratique courante, vous devrez vous assurer de le faire de manière légale dans les lieux où vous opérez. De nombreux sites nécessitent des informations supplémentaires si vous vous connectez à un endroit inconnu.
Vérifiez si un utilisateur a un compte alternatif: certains utilisateurs peuvent avoir un compte alternatif mais avec des mots de passe différents, si un utilisateur ne parvient généralement pas à se connecter avec le même hachage, et si le hachage est le même qu'un autre compte mais se connecte avec succès, alors il peut s'agir d'un l'utilisateur essayant de se connecter avec un autre compte mais a oublié de changer de mot de passe.
Cela semble être une combinaison des deux autres réponses.
Vous pouvez accomplir ce que vous voulez sans enregistrer le mot de passe. Mais il est également important de demander "pourquoi?" Pourquoi ces contrôles? Qu'allez-vous faire de façon réaliste avec ces informations? Peuvent-ils être accomplis par des moyens passifs?
Vérifiez s'il s'agit simplement d'une faute de frappe: si un utilisateur échoue souvent à la première connexion avec le même mot de passe haché, mais plus tard, il se connecte avec succès, il s'agit peut-être simplement d'une faute de frappe
Vérifiez s'il y a quelqu'un qui essaie de deviner le mot de passe: certains mots de passe courants, comme 123456 et anniversaire, qui a corrigé le hachage, si ces tentatives existent, la connexion échouée peut être effectuée par des devineurs de mots de passe.
La journalisation du compte, de l'horodatage, de l'IP et de leur réussite est suffisante. Vous pouvez en déduire beaucoup de ces informations.
Si vous voyez un schéma d'échec, d'échec, d'échec, de réussite rapide pour le même compte, il s'agissait probablement d'une faute de frappe. Si vous voyez un grand nombre d'échecs d'affilée et très rapidement, c'est probablement une attaque sur ce compte.
Mais un attaquant intelligent jouera le jeu des nombres et distribuera ses attaques sur plusieurs comptes. Si l'attaquant n'a aucune information sur vos comptes, toute supposition de mot de passe donnée est tout aussi susceptible de fonctionner sur un compte donné. S'ils ont 100 mots de passe à essayer, peu importe qu'ils les essaient tous sur un seul compte ou qu'ils les répartissent sur 100 comptes, les chances sont les mêmes.
De même, ils peuvent utiliser plusieurs adresses IP. Si vous voyez un groupe de presque tous les échecs de nombreux comptes, mais une seule IP qui pourrait être une attaque distribuée, ou cela pourrait être un groupe d'utilisateurs réels derrière la même NAT ou VPN. C'est difficile dire.
En réalité, il existe un moyen beaucoup plus simple. Ces attaques sont rendues plus coûteuses par limitation de débit et les lock-out logiciels. Pour deviner un mot de passe, il faut pouvoir effectuer un grand nombre de tentatives de connexion très rapidement. Les connexions doivent déjà être limitées par le compte, il n'y a aucune raison pour qu'un véritable utilisateur tente de se connecter plusieurs fois par seconde. Choisissez la limite de taux la plus élevée que vous pouvez, qui n'est toujours pas perceptible par vos utilisateurs. Cela déjouera les tentatives de connexion automatisées à tir rapide. S'il y a de toute façon des tentatives persistantes, augmentez automatiquement et exponentiellement la limite de débit pour ce compte (et éventuellement IP), réduisez-la une fois que les sondes présumées se sont calmées.
De plus, vous pouvez fournir de bons commentaires sur la force des mots de passe lorsque les utilisateurs créent leurs comptes pour éviter les mots de passe faciles à deviner.
De cette façon, vous pouvez déjouer des sondes automatiques à tir rapide sans gêner les utilisateurs légitimes qui ont du mal à taper aujourd'hui.
Vérifiez si un utilisateur a un compte alternatif: certains utilisateurs peuvent avoir un compte alternatif mais avec des mots de passe différents, si un utilisateur ne parvient généralement pas à se connecter avec le même hachage, et si le hachage est le même qu'un autre compte mais se connecte avec succès, alors il peut s'agir d'un l'utilisateur essayant de se connecter avec un autre compte mais a oublié de changer de mot de passe.
Cela semble plus une exigence commerciale qu'un problème de sécurité. Vous essayez essentiellement de détecter la personne unique derrière un compte, et c'est assez difficile à obtenir correctement: Internet ne veut pas que vous ayez cette information. Le coût pour bien faire les choses est élevé, et à mesure que vous obtenez de plus en plus d'utilisateurs, il est de plus en plus probable que de nombreux faux positifs ennuient vos vrais utilisateurs.
À moins que ce ne soit votre entreprise, si vous êtes une entreprise d'exploration de données par exemple, demandez-vous pourquoi vous avez cette exigence: quel est son effet réel sur votre système? Quelles mesures avez-vous pour sauvegarder cela?
Si vous décidez que vous devez vraiment empêcher les modifications, utilisez divers identifiants semi-uniques du monde réel pour ajouter un coût aux comptes alt et réduire leur fréquence. L'adresse e-mail est la plus courante. Faire des comptes coûte de l'argent ou exiger un numéro de carte de crédit en est une autre. Même les numéros d'identification fiscale si vous êtes un site de grande entreprise. Tout dépend de ce que vous faites.
Est-ce une pratique courante, certainement pas; est-ce une bonne pratique, probablement pas. Cependant, je l'ai vu une fois, et pour avoir une discussion complète sur le sujet, je souhaite aller à contre-courant ici et dire à quoi cela peut être utile et quelles précautions ont été prises pour éviter les problèmes notés par d'autres.
Dans un contexte d'attaques externes incessantes contre des connexions bien connues, utilisant la force brute, des attaques par dictionnaire, des attaques avec un seul mot de passe par n'importe quel utilisateur, des logiciels malveillants de spearphishing et de reniflage de mot de passe, l'organisation avait de graves problèmes avec les téléphones mobiles, les tablettes et le mot de passe. changement.
Lorsque la session mobile a été réinitialisée à la suite d'un changement de mot de passe, les téléphones mobiles ont généralement essayé plusieurs fois l'ancien mot de passe avant d'abandonner, généralement un multiple de trois (peut-être mail, calendrier, tâches ou quelque chose comme ça), avant d'inviter l'utilisateur à saisir un nouveau mot de passe. Cela a verrouillé le compte de l'utilisateur en raison d'une règle de trois coups administrativement et techniquement non négociable sur le backend d'authentification.
Il est très possible que ce comportement des appareils mobiles ait été corrigé depuis (c'était il y a quelques années), et je serais intéressé de savoir si c'est le cas.
En bref, les utilisateurs ont un "changement de mot de passe" sur leur bureau chaque mois, et ceux qui n'ont pas immédiatement changé le mot de passe sur tous leurs appareils mobiles ont été verrouillés sur tous les appareils, même ceux connectés au réseau interne (plus) sécurisé, ce qui était un problème plus grave que "simplement" d'être verrouillé à venir à partir d'Internet. Parfois, immédiatement n'était pas suffisant, et il y avait une procédure avec une danse compliquée impliquant le mode avion pour éviter d'être verrouillé. Les utilisateurs possédant à la fois un téléphone mobile et une tablette ont bien sûr eu encore plus de problèmes.
L'organisation a implémenté la journalisation du mot de passe haché de la manière suivante:
- inséré en tant que couche entre l'application et le backend d'authentification.
- hachage à l'aide de PBKDF2.
- un sel de minuit à minuit, un sel de midi à midi, deux hachages stockés pour chaque connexion. Le sel était conservé dans la couche et pas stocké ailleurs (un redémarrage de la couche signifiait un nouveau sel, et lorsque le sel était régénéré, il était perdu, car il n'était pas stocké dans le hachage, comme l'aurait fait bcrypt).
- poivrer avec connexion (ce qui signifie que des mots de passe identiques pour différents comptes n'étaient pas détectables).
- stocké dans une base de données spécifique (non accessible par le service d'assistance) et (éventuellement) enregistré dans une banque de données spécifique sous la forme échec (date, utilisateur, IP source, hachage1, hachage2, agent utilisateur ...) et succès (date, utilisateur, source IP, useragent...).
- la base de données a utilisé une API interdisant toutes les actions qui ne sont pas spécifiquement répertoriées ici (par exemple, répertorier les hachages pour tous les utilisateurs).
- à réception d'une demande d'authentification:
- vérifier dans la base de données si un mot de passe avec le même hachage pour cet utilisateur a été rejeté (dans les 24 heures précédentes), et si c'est le cas, refuser la connexion sans présenter la demande d'authentification au backend, et enregistrer cette raison dans le helpdesk accessible journaux (sans aucun hachage).
- vérifier dans la base de données si la même adresse IP source a échoué l'authentification pour plusieurs comptes d'utilisateurs au cours des n dernières heures, sans aucune connexion réussie, et si c'est le cas, refuser la connexion sans présenter la demande d'authentification au backend, et connecter cette raison les journaux accessibles au helpdesk (toujours sans aucun hachage).
- sinon, transmettez la demande au serveur principal et enregistrez/stockez le résultat.
- lorsque le mot de passe de l'utilisateur est modifié, le backend d'authentification déclenche la suppression de tous les enregistrements de cet utilisateur de la base de données (ce qui enregistre le fait que le mot de passe est modifié). C'était la seule modification apportée au backend d'authentification.
- les enregistrements de plus de 24 heures ont été supprimés de la base de données.
- les journaux n'étaient accessibles qu'aux auditeurs de sécurité.
- dans le cas où les journaux ont été accédés, l'API pour y accéder supprime les hachages, ne présentant que les noms sous la forme PASS1, PASS2. . . PASSN au vérificateur de sécurité. L'accès à la base de données brute était extrêmement restreint, essentiellement uniquement sur la présentation des informations d'identification d'un développeur senior et d'un responsable de la sécurité. Ce n'était pas vraiment à cause de la présence des hachages, c'était à cause de la nature sensible des journaux en général, et c'était (est) la procédure standard dans l'organisation pour l'accès aux bases de données brutes en dehors de l'API approuvée.
- il a été débattu de la nécessité de stocker réellement le nom d'utilisateur. Les mêmes fonctionnalités souhaitées auraient probablement pu être obtenues sans cela, et cela aurait évité un suivi inutile des utilisateurs. Au final, il a été jugé important de savoir si un attaquant cible spécifiquement un utilisateur ou a accès à une liste d'utilisateurs.
- il y avait également une fonction de journalisation des utilisateurs inexistants de manière sécurisée (hachée) (rendue possible par le backend d'authentification renvoyant une raison détaillée de tout refus), de sorte qu'un agent externe essayant de nombreux utilisateurs inexistants serait également mis sur liste noire pour certains beaucoup de temps.
En bref, le concept derrière cette implémentation était que les attaques par dictionnaire sont un problème, mais les tentatives répétées du même (mauvais) mot de passe ne constituent pas une attaque par dictionnaire.
Cette implémentation:
- a réussi à éviter le verrouillage des utilisateurs lorsque l'un de leurs appareils a essayé à plusieurs reprises le même mot de passe, ce qui était l'objectif souhaité et extrêmement urgent
- empêché les attaques par force brute ciblant des mots de passe communs sur plusieurs comptes, ce qui n'était pas une fonction que le backend d'authentification pouvait fournir
- authentification découplée d'Internet du système interne, de sorte que les attaques provenant d'Internet n'affectent pas l'utilisateur se connectant sur son poste de travail
- réduction considérable des appels au help-desk sur le sujet
- réduit considérablement les escalades vers le niveau 3, car le niveau 2 a désormais accès à la raison du rejet de l'authentification pour un compte donné (avec l'agent utilisateur mais sans aucun hachage).
Pour répondre à la question . . . vous présentez plusieurs raisons pour enregistrer les hachages des mots de passe rejetés, mais comme vous le voyez, cet exemple concret de choisir réellement d'enregistrer les hachages des mots de passe rejetés ne s'applique pas à ces raisons. Je pense personnellement que les raisons que vous donnez ne sont pas valables.
Vérifiez qu'il ne s'agit que d'une faute de frappe: tant qu'un utilisateur se connecte réellement après un nombre limité de tentatives, vous n'avez pas de problème. Il peut s'agir d'une faute de frappe ou d'un ancien mot de passe ou du mot de passe d'un autre compte, mais devriez-vous vous en soucier?
Vérifiez si quelqu'un essaie de deviner le mot de passe: oui, mais vous ne le faites pas et ne devez pas le comparer aux hachages de mots de passe connus. Si vous souhaitez empêcher l'utilisation de mots de passe courants, vous devez appliquer des règles lorsque l'utilisateur choisit un mot de passe, et non par la suite.
Vérifiez si un utilisateur possède un autre compte: la liaison de comptes peut éventuellement être effectuée par l'IP source, mais je ne pense pas que savoir qu'un utilisateur essaie d'abord le mot de passe d'un autre utilisateur avant le sien est quelque chose qui vous aidera à empêcher tout accès non autorisé. Si vous avez une raison impérieuse et légale d'empêcher les utilisateurs d'avoir plusieurs comptes, vous feriez mieux en suivant les adresses IP source, les appareils et les temps de connexion qu'en suivant les erreurs dans les mots de passe.
Plus aurait pu être fait en identifiant l'appareil mobile, mais la vraie solution était la gestion des appareils mobiles et un appareil MFA matériel pour les connexions de bureau, et une fois la situation stabilisée, c'était le choix de l'organisation en question.
J'espère que cela t'aides.
Comme indiqué par plusieurs réponses sur ce post, il peut ne pas être pratique d'analyser les mots de passe ayant échoué avec des mots de passe stockés (hachés) pour analyser les cas d'utilisation comme vous l'avez indiqué en raison de fonctionnalités de sécurité améliorées comme `` Salage '', etc.
L'une des exigences du monde réel que je peux voir est, ci-dessous, de la norme HIPAA (Health Insurance Portability and Accountability Act) mais il n'y a pas non plus d'insistance pour enregistrer les mots de passe défaillants mais pour enregistrer/surveiller les autres informations comme indiqué ci-dessous:
Selon la norme HIPAA [164.308 (a) (5)] - Procédures d'enregistrement de l'activité de connexion, y compris les tentatives de connexion infructueuses
Selon cette procédure, vous devez enregistrer les ouvertures et les fermetures de session survenant dans vos systèmes. Vous devez suivre les tentatives d'ouverture de session infructueuses, y compris celles utilisant un mot de passe incorrect et celles avec un compte inexistant. La journalisation doit inclure l'adresse IP ayant échoué, le nom de connexion, le type d'erreur et le nom du système.
J'espère que cela vous sera utile ...