Y a-t-il une raison pour ne pas montrer aux utilisateurs les mots de passe entrés incorrectement après une connexion réussie?
Notre client a proposé que dans le cas où le nom d'utilisateur en question a eu plusieurs tentatives de connexion infructueuses, le ou les mots de passe entrés incorrectement doivent être affichés une fois la connexion réussie. Informations saisies correctement, y compris les mots de passe précédents, ne sera pas affiché dans tous les cas.
Notre développeur principal nous a dit que c'était techniquement possible en ne hachant pas les entrées incorrectes, mais elle est extrêmement très mal à l'aise avec la fonctionnalité et donc elle a été mise en attente pendant que nous réfléchissons.
Le site Web en question est une large application de cartographie/SIG qui ne comporte aucune transaction monétaire. Les autres options de connexion/authentification incluent Google/LinkedIn/Twitter/facebook, donc évidemment aucun mot de passe à y stocker et la gestion qui est principalement un problème UX.
Quelles sont les failles de sécurité associées à l'implémentation d'une telle fonctionnalité? Notre client n'est pas entièrement dépourvu de connaissances techniques, une explication générale suffit donc.
Mes excuses si la question est trop large ou la réponse très évidente.
Le principal problème est que les mots de passe incorrects doivent être stockés de manière à pouvoir être affichés ultérieurement aux utilisateurs. Ce qui, comme l'a souligné votre développeur, signifie qu'ils ne peuvent pas être hachés cryptographiquement en premier. Le résultat est que vous les stockez sous forme de texte en clair (mauvais) ou cryptées (mieux mais pas normalement recommandé).
Le plus grand risque est que cette base de données de mots de passe invalides devienne accessible aux attaquants. Soit ils compromettent le serveur, effectuent une injection SQL ou le récupèrent d'une autre manière. Plutôt que de craquer les mots de passe principaux, qui, espérons-le, sont fortement hachés et donc des cibles plus difficiles, ils pourraient décider de compromettre les comptes en utilisant les informations de l'historique des mots de passe invalides. Soit ils accèdent facilement aux mots de passe en texte brut, soit ils tentent de trouver la clé de chiffrement qui leur permet de déchiffrer à nouveau les mots de passe en texte brut.
Une source courante d'échecs de connexion est des fautes de frappe mineures lors du processus de saisie du mot de passe. Donc mon mot de passe est Muffins16 mais je tape mUFFINS16 car mon verrouillage des majuscules est activé. Ou Muffins166 parce que j'ai appuyé deux fois sur la même touche. Ou Muffina16 parce que mon doigt a touché la mauvaise touche. Comme vous pouvez le voir, ces variations sont suffisamment proches de l'original pour que les attaquants puissent probablement déterminer le mot de passe valide à partir de mots de passe invalides en essayant quelques modifications mineures ou en comparant les mots de passe incorrects aux mots ou noms de dictionnaire probables.
Ce problème est exacerbé car la plupart des gens utilisent des choix de mot de passe similaires à ces formats et non des chaînes aléatoires. Il est plus difficile pour un attaquant d'identifier la faute de frappe si votre mot de passe invalide est V8Az $ p4/fA, bien qu'il soit encore plus facile d'en essayer des variantes que de le deviner sans aucune information.
Un autre risque est que les utilisateurs ne se souviennent pas lequel de leurs mots de passe ils ont utilisé sur ce site, ils essaient donc les mots courants. Maintenant, ce site est soudainement une cible plus importante, car un attaquant pourrait non seulement compromettre le compte d'un utilisateur là-bas, mais aussi sur d'autres sites avec la liste pratique de mots de passe "invalides".
Vous pouvez atténuer certains de ces risques en effaçant le stockage des mots de passe invalides immédiatement après l'affichage après une connexion valide. Cela devrait limiter la fenêtre d'opportunité pour un attaquant d'accéder aux données et d'en bénéficier.
La question que vous devriez probablement poser à votre client est de savoir comment il prévoit que les utilisateurs bénéficieront de voir leurs mots de passe invalides. Est-ce que les utilisateurs peuvent identifier comment ils ont mal saisi leur mot de passe? Les fautes de frappe ne sont pas intentionnelles, il est donc peu probable que leur montrer leur erreur améliore les futures tentatives de connexion. Ainsi, les utilisateurs peuvent identifier un attaquant essayant de deviner leurs mots de passe? Des commentaires similaires peuvent être fournis en répertoriant la date, l'heure, l'IP/la géolocalisation ou d'autres informations pour les tentatives non valides sans mot de passe. Les utilisateurs savent donc qu'ils ont foiré lors de la saisie du mot de passe et ne blâment pas le système de connexion du site? Cela semble être le seul à avoir du mérite et je ne suis pas sûr qu'il apporte suffisamment de valeur pour justifier le risque.
Je suppose qu'une fois que vous comprendrez mieux ce qu'ils essaient d'accomplir avec cette fonctionnalité, vous pouvez probablement suggérer des alternatives plus sécurisées.
tldr; c'est encore pire que de ne pas hacher vos mots de passe et les stocker en texte brut.
Je suis d'accord avec les préoccupations de votre développeur principal. Afin d'afficher les tentatives de mot de passe incorrectes passées, vous devez les stocker de manière réversible, ce qui signifie qu'elles ne peuvent pas être hachées. Si quelqu'un compromettait le système, il aurait alors accès à toutes les mauvaises tentatives et pourrait probablement reconstituer les vrais mots de passe pour certains utilisateurs. Par exemple, si vous pouvez voir certaines de mes mauvaises tentatives:
correct horrse battery staple
correct horse batttery staple
Il serait assez facile de comprendre mon mot de passe réel.
Je suis également d'accord avec réponse de drewbenn : si je tape incorrectement mon nom d'utilisateur mais avec mon mot de passe correct et que le nom d'utilisateur incorrect se trouve être le nom d'utilisateur de quelqu'un d'autre, maintenant que l'utilisateur peut voir mon vrai mot de passe.
Une fois, j'ai essayé de me connecter à un système en utilisant mon mot de passe mais le nom d'utilisateur de mon collègue.
Ensuite, il y a toutes les fois où j'ai utilisé le mauvais mot de passe lorsque j'essayais de me connecter à un compte partagé.
Et je sais que de nombreux administrateurs ont accès au compte de leur patron pour pouvoir faire avancer les choses. Je serais assez choqué si leurs patrons n'avaient jamais entré le mauvais mot de passe puis distrait par un visiteur avant de se connecter correctement pour effacer l'erreur.
Plus toutes les fautes de frappe lorsque quelqu'un se tient au-dessus de mon épaule pendant que je me connecte.
Et dans tous ces cas, j'ai parfois entré mon mot de passe gmail ou lastpass dans l'invite de mot de passe au travail, et vice versa.
Et la fois où j'ai googlé mon mot de passe parce que je ne regardais pas l'écran et je supposais juste qu'il était verrouillé. Non pas que cela ait quoi que ce soit à voir avec votre proposition, mais j'aime partager cette anecdote car elle rappelle aux gens que tout le monde peut parfois faire des erreurs et taper la mauvaise chose.
La seule chose que cette fonction hUnt3r2 fait est de transformer de petites erreurs (en entrant le mauvais mot de passe ou en le tapant mal) en expositions accidentelles à un public plus large.
Perte de réputation
La mise en place d'un tel mécanisme entraînerait une perte de réputation immédiate, étant donné qu'il y a eu des cas très médiatisés où des tentatives de connexion infructueuses ont été utilisées pour attaquer d'autres sites. Voici un exemple:
Mark (Zuckerberg) a utilisé son site, TheFacebook.com, pour rechercher des membres du site qui se sont identifiés comme membres du Crimson. Puis il a examiné un journal des connexions échouées pour voir si l'un des membres de Crimson avait déjà entré un mot de passe incorrect dans TheFacebook.com. Si les cas dans lesquels ils étaient entrés ont échoué, Mark a essayé de les utiliser pour accéder aux comptes de messagerie Harvard des membres Crimson. Il a réussi à accéder à deux d'entre eux.
En d'autres termes, Mark semble avoir utilisé des données de connexion privées de TheFacebook pour pirater les comptes de messagerie séparés de certains utilisateurs de TheFacebook.
Source: Comment Mark Zuckerberg a piraté le Harvard Crimson
Une alternative
Si votre client est déterminé à afficher des tentatives de connexion infructueuses lors de la prochaine connexion réussie, comme une mesure de bien-être, puis-je suggérer une alternative? Au lieu d'afficher les mots de passe ayant échoué, affichez l'adresse IP et les informations de géolocalisation du navigateur qui a soumis le mauvais mot de passe. Devrait être assez facile à faire, ne poserait pas de problème de sécurité et fournirait des informations beaucoup plus utiles en cas d'activité malveillante réelle.
Une raison non liée à la sécurité de ne pas le faire: spam de mauvaise connexion.
Je lance ma liste d'e-mails/noms d'utilisateur sur votre application. J'essaie de me connecter à chaque compte avec le même "mot de passe". Peut-être une phrase offensante; slogan politique, ou simplement une annonce pour un site Web.
Ensuite, chacun de vos utilisateurs se connecte, ceux avec les noms d'utilisateur/e-mails que j'ai devinés sont obligés de regarder tout ce que j'ai entré.
Il donne à chaque personne anonyme un vecteur d'affichage du contenu pour vos utilisateurs.
Dans le cas de collègues qui utilisent chacun le service et qui peuvent probablement deviner les noms de connexion de l'autre, cela pourrait même entraîner du harcèlement ou d'autres problèmes de RH au travail.
Que se passe-t-il lorsque je souhaite me connecter à votre application et que je suis assis avec mon collègue? Supposons que je saisisse mal mon mot de passe. Dois-je maintenant le renvoyer pendant que je me connecte pour qu'il ne voie pas ma tentative de mot de passe?
S'il y a des utilisateurs avec des noms d'utilisateur/adresses e-mail similaires, ils peuvent accidentellement tenter de se connecter au compte d'un autre utilisateur.
Un utilisateur malveillant pourrait alors utiliser sa liste de tentatives de mot de passe "incorrectes" pour pénétrer dans des comptes avec des noms d'utilisateur/adresses e-mail similaires (par exemple, bill11, bill1, etc.).
Je pense qu'il serait préférable de simplement lister les tentatives de connexion incorrectes et réussies avec l'heure et l'adresse IP pertinente.
Je suis d'accord avec d'autres réponses soulignant qu'il est facile de deviner le mot de passe d'un utilisateur si un attaquant a mis la main sur la liste des tentatives infructueuses.
Cela étant, il importe peu que votre système ne contienne aucune information sur les transactions monétaires. Il est courant que les utilisateurs utilisent le même mot de passe ou des variantes du même mot de passe sur plusieurs sites. On peut leur conseiller de ne pas le faire, mais cela arrive quand même. Donc, ce n'est pas parce que vous sentez que votre système expose des informations sensibles lui-même que les informations sensibles de vos utilisateurs ne sont pas mises en danger si votre système est compromis.
Si Joe User utilise le même mot de passe sur votre système qu'il utilise pour sa banque, si un attaquant pouvait deviner son mot de passe sur votre système et découvrir quelle banque Joe utilisait, l'attaquant pourrait avoir accès au compte bancaire de Joe. Ou les dossiers médicaux ou tout autre système sur lequel Joe a utilisé ce mot de passe.
Vous ne protégez pas seulement les mots de passe de votre système.
Je soupçonne que votre client souffre d'un problème XY . Cela signifie prendre du recul et essayer de comprendre ce que votre client veut vraiment. Il est souvent utile de savoir que quelqu'un a essayé un mot de passe incorrect et comment cela mot de passe a été entré, pas nécessairement quel ce mot de passe était. Peut-être que le client veut juste assez d'informations pour distinguer les menaces bénignes, telles que le fait de toucher votre propre mot de passe, des menaces plus suspectes, telles que la devinette des mots de passe de l'autre côté du pays sur un appareil qui ne s'est jamais connecté auparavant.
Demandez donc à votre client quel est le modèle de menace et voyez si les informations suivantes sont suffisantes:
- iD utilisateur pour lequel l'authentification a échoué (afin que vous puissiez savoir qui avertir pour chaque échec)
- date et l'heure
- adresse IP du client, agent utilisateur et géolocalisation approximative
- si le client exécute JavaScript (les attaquants ne s'en soucient pas souvent)
- si le client a présenté un cookie pour s'être connecté avec succès dans le passé
Présentez ensuite un avertissement basé sur ces informations lorsqu'un utilisateur réussit à se connecter après un ou plusieurs échecs.
J'hésite à ajouter ici les excellentes réponses, mais il y a un autre point important. À moins que vous ne soyez absolument certain que les utilisateurs ne se connectent au site que via HTTPS (et honnêtement, même pas alors), vous ne devriez même jamais avoir la possibilité d'afficher les mots de passe incorrects ... car ils ne devraient jamais être transmis (cryptés ou non) dans le première place. Les systèmes clients doivent uniquement transmettre quelque chose comme un hachage salé, pas le mot de passe réel (dans une mise en œuvre appropriée, pour garantir que le hachage lui-même ne devienne pas le mot de passe, c'est-à-dire quelque chose qui peut être volé et réutilisé), pour empêcher les attaques d'écoute clandestine.
Et peu importe que le site ne traite pas de transactions financières. Vous ne voulez toujours pas qu'il devienne le maillon le plus faible d'une chaîne.
Je suis donc entièrement avec votre développeur principal sur celui-ci. Je me battrais bec et ongles contre cette "fonctionnalité".
Une solution possible: étant donné que le problème ici est de stocker des tentatives de mot de passe incorrectes en texte brut, évitez-le. Lorsque le mot de passe d'un utilisateur est défini, générez une paire de clés publiques et privées. Stockez la clé publique et la clé privée chiffrées avec le mot de passe. Lorsque vous enregistrez des mots de passe incorrects, chiffrez-les avec la clé publique (et ajoutez du sel). De cette façon, seul l'utilisateur qui connaît le mot de passe correct peut voir les mots de passe incorrects.
Votre système disposera d'une grande base de données déchiffrable de mots de passe. En recherchant les mots de passe incorrects pour l'utilisateur X, vous obtiendrez des mots de passe presque corrects pour le compte de X, des mots de passe corrects pour différents comptes de l'utilisateur X, ainsi que des mots de passe corrects pour les comptes d'utilisateurs ayant presque le même nom d'utilisateur que X.
Avec l'hypothèse raisonnable qu'un pirate informatique pourrait s'introduire dans votre système et obtenir une copie déchiffrée de la base de données, ce serait désastreux. Même en supposant que l'accès à votre système par la mauvaise personne n'est pas trop critique, cette base de données contiendra les mots de passe de vos utilisateurs pour différents systèmes qui pourraient être beaucoup plus critiques.
Il me semble que dans une authentification correctement construite, le mot de passe que l'utilisateur a tapé n'est même pas transmis au site hôte, donc la question du stockage des tentatives incorrectes est sans objet.
Il peut être acceptable d'avoir une case à cocher "voir le mot de passe" dans l'interface, qui est strictement une fonction locale, et peut être utilisée soit lors de la saisie du mot de passe, soit après une tentative infructueuse. Les informations enregistrées devraient probablement être effacées après un court laps de temps pour empêcher la récolte des mots de passe des consoles abandonnées.