Les mots de passe sont envoyés en texte clair en raison d'une erreur des utilisateurs en les tapant dans le champ du nom d'utilisateur
En examinant les journaux générés par différents SIEM (Splunk, HP Logger Trial et SIEM de la plate-forme AlienVault), j'ai remarqué que pour une raison quelconque, un grand nombre d'utilisateurs ont tendance à commettre l'erreur de taper leurs mots de passe dans le champ du nom d'utilisateur, soit dans la connexion au domaine OS. ou dans des applications Web. Je suppose que ce sont des gens qui ne peuvent pas taper sans regarder le clavier et en essayant de le faire, le faire rapidement, finissent par taper leurs mots de passe dans le mauvais champ. Cela signifie que le mot de passe est envoyé en texte brut partout dans le réseau et finit par être enregistré dans les journaux avec un événement qui dit quelque chose dans le sens:
User P@$$w0rd does not exist [...]
Ou
An account failed to login: P@$$w0rd [...]
(où P @ $$ w0rd est le mot de passe de l'utilisateur réel)
Il devient assez évident de déterminer à qui appartiennent les mots de passe: généralement l'événement précédent ou très suivant (non) réussi sur le même fichier journal vous indiquera un événement déclenché par le même utilisateur.
Tout autre analyste, en consultant les journaux, pourrait obtenir les informations d'identification de quelqu'un d'autre sans que le propriétaire ne le sache; le pire des cas est l'écoute du réseau ou la compromission réelle du fichier journal.
Je suis à la recherche d'un guide général pour aider à prévenir cela. Je suppose que masquer simplement le nom d'utilisateur n'est pas possible et même s'il l'était, cela éliminerait probablement une grande partie de l'analyse du journal pour ne pas pouvoir dire qui a fait quoi.
Remarque: Il existe déjà un article sur un problème similaire, mais j'essaie de trouver un moyen de l'empêcher. Quel est le risque si je tape accidentellement mon mot de passe dans un champ de nom d'utilisateur (connexion Windows)?
Réponse acceptée: J'aimerais pouvoir sélectionner quelques réponses dans la liste. Malheureusement, je dois m'en tenir à un seul dans le forum, mais dans la pratique, je peux les combiner. Merci beaucoup pour toutes les réponses; Je vois qu'il n'y a pas de solution unique. Comme je suis d'accord que l'ajout de "choses" ajoute de la complexité qui augmente la probabilité de failles de sécurité, je dois convenir avec la plupart des électeurs que @AJHenderson a la réponse la plus élégante et la plus simple comme première approche. Certainement SSL et une simple vérification de code sur le serveur ou même côté client. Comme je cherche à atténuer non pas les utilisateurs malveillants, mais les distraits, cela fera l'affaire. Une fois que cela est en place, nous pouvons commencer à chercher à étendre la mise en œuvre aux utilisateurs mal intentionnés, le cas échéant. Merci encore beaucoup pour la contribution de tout le monde.
Une idée est de ne pas autoriser la soumission de formulaire s'il n'y a pas de valeur dans la zone de mot de passe. En général, s'ils ont accidentellement entré le mot de passe dans le nom d'utilisateur, il n'y aura probablement rien dans la boîte de dialogue du mot de passe.
Il convient de noter que cela ne doit pas simplement être effectué côté client, mais peut également être effectué sur un serveur tant que le transport utilisé est sécurisé et que l'entrée n'est enregistrée qu'après avoir vérifié que le champ de mot de passe n'est pas vide .
En supposant que votre application dorsale et SIEM doivent afficher les tentatives de connexion échouées à diverses applications (et ainsi afficher le message d'erreur "L'utilisateur P @ $$ w0rd n'est pas valide"), il ne sera pas trivial d'arrêter cela.
Cependant, s'assurer que toutes les applications qui envoient des données sensibles, y compris les noms d'utilisateur et les mots de passe, implémentent HTTPS (HTTP crypté à l'aide de SSL) est un bon moyen de s'assurer que les périphériques réseau et quiconque sur le réseau ne peuvent pas obtenir le mot de passe entré par erreur dans la zone du nom d'utilisateur!
Le problème est donc que vous ne voulez pas que les analystes voient les mots de passe dans les fichiers journaux sensibles?
Attention: Même si vous utilisiez Javascript, il ne traite pas les données de mot de passe qui sont stockées sur votre disque en texte brut.
Une meilleure solution consiste à prétraiter les journaux avant que les analystes ne les voient et à expurger les informations dans les journaux.
Vous pouvez effectuer ce filtrage ligne par ligne si vous ajoutez des lignes à la liste blanche ou mettez sur liste noire d'autres lignes. Par exemple:
Vous pouvez mettre en liste blanche les noms d'utilisateur lorsqu'ils apparaissent dans un fichier journal qui
- Avoir un modèle ([az] + nombre) ou ([az] + période + [az])
- inclure un nom de domaine suivi d'une barre oblique "\" pour les environnements AD
- apparaître plusieurs fois
- Peut être comparé à un répertoire LDAP de noms d'utilisateurs connus avant que les analystes ne le voient
Vous identifiez et mettez également les mots de passe sur liste noire par:
- La politique de mot de passe suit souvent un modèle (un symbole, haut/bas, x caractères ...)
Vous pouvez utiliser ces connaissances pour créer un nettoyeur de données de journal personnalisé afin de protéger les informations que vous ne souhaitez pas que les analystes voient.
A quoi ressemble une ligne filtrée?
Vous pouvez simplement supprimer les noms d'utilisateur douteux en les hachant, en leur attribuant un ID humain et en les stockant dans un emplacement sécurisé:
eb574b236133e60c989c6f472f07827b Redact1
7e67b89a695bfbffc05b7ed2c38f927f Redact2
..etc
Les analystes peuvent voir si une entrée particulière se produit encore et encore si le hachage se répète en fréquence.
La méthode de hachage exacte (ou la méthode de cryptage) que vous choisissez est sujette à des risques car cette "base de données de hachage" contiendra des informations de grande valeur. Et l'ensemencement empêchera (par sa nature) l'analyse de fréquence qui peut ou non vous être utile.
Je ne peux identifier que trois problèmes avec ce dont vous discutez.
- Les utilisateurs ne saisissent pas correctement les informations.
- Les analystes peuvent discerner les mots de passe des journaux.
- Les mots de passe sont envoyés en texte clair et sont susceptibles de
l'homme au milieuécoute.
À mon avis, c'est assez simple à corriger.
- Acceptez l'erreur utilisateur, à contrecœur .
- N'enregistrez pas les noms d'utilisateur invalides, mais enregistrez à la place les tentatives infructueuses et l'adresse IP.
- N'envoyez pas de noms d'utilisateur en texte clair. Utilisez une technologie comme HTTPS o utilisez javascript pour coder le texte brut (par exemple ROT13).
Exemple de journal d'une connexion échouée, puis d'une nouvelle tentative réussie.
[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100
En lisant d'autres réponses, je voudrais inclure ceci.
- Validez tous les champs avant la soumission.
- Envisagez de diviser le formulaire entre plusieurs pages, comme l'a mentionné Eric G.
Une solution que j'ai vu quelques banques implémenter, au moins dans les applications Web, est d'avoir une connexion de deux pages.
- Sur la première page, acceptez uniquement le nom d'utilisateur
- Sur la page suivante du processus, demandez le mot de passe et ne renvoyez que le nom d'utilisateur afin qu'il ne soit pas un champ modifiable
Par conséquent, la seule entrée sur la deuxième page doit être le mot de passe. Étant donné que l'utilisateur sait qu'il doit effacer la première page avec un nom d'utilisateur, il sait qu'il doit effacer cette porte, alors la seule option sur la deuxième page est le mot de passe.
Si vous pouvez implémenter ce flux de travail, cela aidera à concentrer les utilisateurs sur ce qu'ils tapent et quand.
En outre, compte tenu de votre journalisation: vous pouvez peut-être modifier votre journalisation pour ne pas inclure les informations d'identification réelles?
Par exemple, lors d'une connexion réussie, utilisez l'ID de la clé primaire au lieu de renvoyer l'entrée: "L'utilisateur avec l'ID: '2342342' a tenté de se connecter" puis "L'utilisateur avec l'ID '2342342' a correctement fourni un mot de passe".
Si vous effectuez une recherche et que le nom d'utilisateur n'est pas là, quelque chose comme "Utilisateur de l'adresse IP '192.168.0.10' a tenté de se connecter avec un ID utilisateur non valide".
Ce serait vos journaux au niveau de l'application. Les journaux de serveur Web peuvent inclure des paramètres de requête, ce qui peut être un peu plus difficile à traiter ou peut-être pouvez-vous mettre un certain type de filtre proxy entre l'action et lorsque le journal est écrit pour expurger le contenu du journal en fonction de certaines règles. Ce serait spécifique à la plate-forme, mais il semble que ce soit possible sur Apache .
En tant que contrôle secondaire, limitez l'accès en lecture aux différents fichiers journaux que vous traitez.
De manière générale, tous les codes client sont suffisamment intelligents pour gérer les erreurs de base
- ID utilisateur et/ou mot de passe manquant
- Mot de passe ne correspondant pas aux directives
Donc, dans tous les cas, lorsque vous voyez toujours ces entrées dans le journal,
User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]
Aucune validation client n'a fonctionné et le système a fini par envoyer le mot de passe non chiffré sur le réseau. Alors, qu'y avait-il dans le champ Mot de passe? Certainement pas vide car la validation du client échouerait. Il doit me quelque chose de différent du mot de passe
Alors faites-en une authentification en deux passes
- First Pass, envoyez tous les détails cryptés, y compris le mot de passe, au serveur. Vérifiez si le champ Mot de passe est vide.
- Première passe, vérifiez si le mot de passe correspond aux directives sinon Erreur en sortie.
- Première passe, vérifiez ensuite si le mot de passe est présent dans votre base de données. Sinon Error Out.
- Renvoyez une réponse RPC au client et laissez-le envoyer l'ID utilisateur et le mot de passe maintenant.
- Effectuez maintenant le processus d'authentification
L’essence même de ce processus est de
- Minimisez les risques. Remarque, vous ne pouvez pas éliminer le risque de zéro
- Ne pas faire confiance au client.
Et enfin, faites réviser votre interface par un expert UX. Il se peut que votre interface présente une faille entraînant la saisie du mot de passe par les utilisateurs dans le champ ID.
D'après ce que vous décrivez de votre architecture, cela est irréalisable, mais à mon avis, la bonne solution est la suivante: n'envoyez pas le nom d'utilisateur en clair et n'enregistrez pas les noms d'utilisateur des tentatives de connexion infructueuses. Le seulement endroit où le nom d'utilisateur et le mot de passe doivent aller est au sous-système qui vérifie le mot de passe; jusqu'à ce que cela se produise, le nom d'utilisateur est données arbitraires non authentifiées - toute personne ayant accès au formulaire de connexion, qui dans une application Web est tout Internet, peut taper tout ce qu'elle veut, aussi souvent qu'elle le veut - et donc vous dit très peu d'intérêt. (À moins que votre formulaire de connexion ne soit pas exposé à Internet.)
cela éliminerait probablement une grande partie de l'analyse du journal pour ne pas être en mesure de dire qui a fait quoi ...?
Étant donné un nom d'utilisateur sans le mot de passe correct, vous je ne sais pas si la demande provient réellement de cet utilisateur, donc vous ne savez toujours pas qui a fait la tentative de connexion.
Le problème général est l'authentification par mot de passe. Chaque boutique maman-et-pop insiste pour avoir sa propre authentification avec des mots de passe. C'est stupide.
Laissez un autre fournisseur d'identité faire le travail difficile pour sécuriser les informations d'identification. Faites la même chose que StackOverflow: autorisez l'authentification avec OpenID, Gmail, etc.
Vos utilisateurs vous remercieront de ne pas avoir besoin d'un autre mot de passe quelque part.
Le javascript côté client semble raisonnable.
Le champ Vérifier le mot de passe n'est pas vide avant la soumission. Vérifiez que le nom d'utilisateur est sous une forme valide. Particulièrement élégant est quelque chose où le nom d'utilisateur doit être une adresse e-mail. Vous pouvez en outre interdire que le mot de passe de votre mécanisme de définition/modification de mot de passe se présente sous la forme d'une adresse e-mail. Ensuite, vérifiez simplement que le nom d'utilisateur est sous la forme d'une adresse e-mail valide avant de soumettre le formulaire. Cela pourrait être fait de la même façon avec, disons, des caractères spéciaux ou des chiffres. (Par exemple, les chiffres/caractères spéciaux sont requis dans les mots de passe mais interdits par les noms d'utilisateur).
De plus, utilisez une bibliothèque SSL à jour pour toutes les soumissions de formulaires (cela devrait être fait pour empêcher les écoutes indiscrètes du réseau d'écouter). Exiger des autorisations élevées pour lire ces journaux (par exemple, le compte du serveur Web peut écrire dans ces journaux, mais seul root peut les lire). Dès que le mot de passe échoue à l'étape d'authentification, ne propagez pas le nom d'utilisateur vers d'autres systèmes. (Utilisez également SSL entre des systèmes internes distincts pour empêcher les écoutes indiscrètes du réseau).
J'aime l'approche que mon entreprise actuelle adopte face à ce problème: si vous tapez votre mot de passe dans la mauvaise case, un système automatisé expire immédiatement votre mot de passe. Ainsi, l'utilisateur doit changer son mot de passe et le mot de passe qui se trouve dans le journal n'est plus vulnérable.
Bien sûr, ce n'est toujours pas idéal si l'utilisateur utilise toujours ce mot de passe pour un autre système, mais il est à espérer que le fait d'être forcé de changer son mot de passe rendra l'utilisateur plus conscient des risques de sécurité possibles.
La réponse la PLUS FACILE est généralement la bonne réponse. Maintenant, nous remarquons que chaque adresse e-mail comporte un signe "@" juste avant le nom de domaine. Faire de "@" une clé NON ACCEPTABLE dans le mot de passe rend la solution assez évidente. Si le nom d'utilisateur n'a PAS @ et TOUS LES NOMS D'UTILISATEURS sont des adresses e-mail, connectez-vous uniquement à ceux qui contiennent au moins @.
Maintenant, si le nom d'utilisateur DONOT a "@", cela pourrait probablement mettre certains utilisateurs en colère, mais c'est une solution intéressante. C'est d'avoir UN SEUL caractère spécial qui vient AVANT un mot de passe. Tout comme TOUS LES NOMS D'UTILISATEUR qui sont des comptes de messagerie ont un format. Toutes les réponses ont un caractère spécial au début ou à la fin, peu importe. Ainsi, lorsque l'utilisateur saisit un mot de passe, vous lui faites savoir qu'il doit le saisir.
La troisième solution est le CODAGE COULEUR. Rendre le champ de nom d'utilisateur jaune et le champ de mot de passe ROUGE. Le rouge attire normalement votre attention car il est utilisé pour les choses sensibles. Donc, même s'ils regardent le clavier, ils APPRENDRONT TRÈS RAPIDEMENT que les mots de passe sont rouges. Donc, fondamentalement, le champ de texte ET l'étiquette de mot de passe sont rouges, de préférence dans une boîte séparée et l'étiquette de nom d'utilisateur et le champ de texte TOUT JAUNE.
Pourquoi ne pas simplement répondre avec ça?
That username does not exist
Quel contrôle avez-vous sur la gestion de ce problème par le serveur récepteur? Il semble que la solution qu'un utilisateur a proposé ci-dessus, pour hacher à la fois le nom d'utilisateur et le mot de passe, serait réalisable de deux manières:
Méthode 1 (nécessitant JavaScript): hachez à la fois le nom d'utilisateur et le mot de passe. Dans votre base de données, stockez les noms d'utilisateur hachés, puis effectuez votre recherche d'authentification à l'aide de ce champ. Ce serait idéal si vous avez un certain contrôle sur la façon dont les données sont traitées sur votre serveur, mais ne contrôlez pas sa capacité de journalisation.
Méthode 2 (ne nécessitant pas JavaScript): recevez le nom d'utilisateur en texte brut comme d'habitude, mais convertissez-le en hachage comme dans la méthode 1 une fois que vous l'avez reçu sur le serveur. Lorsque la tentative échoue, connectez le hachage, pas le nom d'utilisateur. Les journaux seront toujours utiles (un peu moins utiles lorsqu'ils sont inspectés avec curseur), car chaque hachage identifiera toujours de manière unique un utilisateur. Aucun de ces éléments n'est aussi élégant que la meilleure réponse ici (et je suggérerais de l'utiliser également), mais ils sont plus approfondis.
- permet uniquement de transmettre des hachages md5 de noms d'utilisateurs ET de mots de passe (ou hachage similaire), de sorte que tout ce qui est enregistré dans les fichiers journaux ressemblera toujours à une longueur fixe de caractères aléatoires, ce qui ne permettra à personne de deviner rapidement qu'il s'agit d'un md5 d'un mot de passe ou d'un nom d'utilisateur.
Con: Pour comparer avec les noms d'utilisateur dans votre base de données, vous devez soit stocker deux colonnes, par exemple 'nom d'utilisateur' et 'md5 (nom d'utilisateur)' OR vous devez hacher dynamiquement chaque fois que vous demandez un nom d'utilisateur pour la connexion.
- créer une entrée de journal uniquement si le nom d'utilisateur existe dans la base de données, sinon, connectez ip uniquement.
- autorisez uniquement l'utilisateur à cliquer sur Entrée à l'aide de la souris, pas du clavier, ou n'autorisez le clavier qu'après 5 secondes du dernier caractère entré dans l'un ou l'autre des champs, ce qui donnera à l'utilisateur le temps de regarder l'écran et de voir son erreur.
faire une certaine restriction aux noms d'utilisateur et mots de passe autorisés:
- les mots de passe doivent contenir un caractère spécial comme! @ # $% ^ & * ()
- les noms d'utilisateur ne doivent PAS contenir de caractère spécial
De cette façon, vous pouvez faire du javascript pour identifier rapidement si le nom d'utilisateur ou le mot de passe saisi.
Une solution simple mais ennuyeuse pourrait être d'avoir une disposition du clavier à l'écran des boutons html, où les utilisateurs ne peuvent taper leur nom d'utilisateur qu'en utilisant ces boutons, cela empêchera l'erreur de se produire, je me rends compte à quel point cela peut s'avérer ennuyeux , mais après la première connexion, vous pouvez utiliser un cookie pour mémoriser le nom d'utilisateur et ne plus en avoir besoin. Javascript sera bien sûr requis. Il est désormais impossible d'envoyer le mot de passe en texte brut par accident. J'espère que cela aide.
J'ai un point de vue différent ... Quel problème essayez-vous de résoudre vraiment?
Mauvais mots de passe? C'est à dire. lorsque vous voyez une personne utiliser un "mot de passe" (ou une variante), vous voulez pouvoir remonter jusqu'à l'utilisateur et le corriger?
Des mots de passe envoyés en clair?
Ou le problème avec les idiots qui ne peuvent pas taper ou lire des formulaires (ou peut-être une interface utilisateur mal conçue)?
Rappelez-vous toujours que chaque fois que vous "ajoutez" au système, vous ajoutez potentiellement de la complexité, et vous ajoutez définitivement du code - les deux qui augmentent la possibilité d'ouvrir des "trous" de sécurité dans votre architecture globale quelque part (pourrait être dans la pile, pourrait être via le web, pourrait être sur le net ...). Donc, en résolvant l'un des 3, vous devez mesurer si la valeur de le résoudre vaut le risque de percer un trou que vous ne connaissez pas - le diable que vous connaissez est toujours meilleur que le diable que vous ne connaissez pas.
Maintenant à chacun.
La résolution des mauvais mots de passe doit être effectuée lors de la configuration et du changement du mot de passe via les règles de validation. Et seulement là. Pour ajouter un autre endroit pour le faire, cela signifie seulement que vous risquez de confondre ou de désynchroniser les règles de validation.
Les mots de passe sont envoyés en clair. On s'en fout? Certes, cela peut "sembler" dangereux, mais n'oubliez pas qu'il s'agit d'une authentification en n parties et si vous n'en avez qu'une, ce n'est pas différent d'avoir un mot dans un dictionnaire. Peut-être, juste peut-être que si vous avez un renifleur actif, cela peut leur donner des indices, mais alors l'intrusion déjà en place est votre vrai problème, pas des mots de passe occasionnels, aléatoires et fatigants dans le champ du nom d'utilisateur. Maintenant, si vous avez envoyé toutes les pièces dans le gros problème clair.
Problème d'idiots ou de mauvaise conception de l'interface utilisateur. Reconnaître les utilisateurs ou l'interface utilisateur. Facile. Fournir une aide active sur l'interface utilisateur, demander aux départements de suivre une formation ou quelque chose du genre. Solution facile qui nécessite des modifications de codage limitées et à faible risque (ou devrait - être prudent avec l'aspect de l'interface utilisateur cependant).
Bien que j'admire beaucoup de suggestions ici, et beaucoup d'entre elles ont de merveilleuses idées à la base. Je recommande une approche KISS, no BS, en se souvenant toujours que si vous ajoutez à vos systèmes, vous risquez d'ajouter à votre insécurité.
Juste mes 2 cents.
La biométrie est maintenant assez peu coûteuse et fonctionne au moins 80% du temps. Je le trouve génial sur les TabletPC et j'ai voulu déployer des claviers biométriques car il est plus rapide (au moins pour 80% du temps).
Je parie que ce n'était pas autant un problème avec Win2000, WinXP, Win2003 et WinVista car par défaut, le champ du nom d'utilisateur était déjà rempli avec le dernier nom d'utilisateur réussi. Vous ne savez pas exactement quelle version d'ActiveDirectory ou de la station de travail a changé, mais la valeur par défaut est maintenant que le champ du nom d'utilisateur soit vide, ce qui rend ce problème plus fréquent.