Vigilance sécuritéMots de passe et cartes de crédit, première partie

Jesper M. Johansson

Sommaire

Conseils de sécurité inopérables
Inopérable et incorrect
Conseils incompréhensibles
Les pièges d'authentification de site basée sur les images

J'ai été récemment contacté par l'Université du Minnesota afin d'avoir un entretien pour son magazine. Apparemment, ils voulaient exécuter une fonctionnalité sur des anciens étudiants ayant réussi et, comme ils n'en ont trouvé aucun, ils m'ont choisi. L'enquêtrice m'a demandé sur quoi je travaillais et j'ai essayé pendant quelques minutes de décrire les logiciels

d'infrastructure de sécurité. Elle s'est alors écriée, « Cela me paraît très compliqué ! Pour moi, la sécurité a trait aux mots de passe et aux cartes de crédit ».

J'ai médité sur cette réaction pendant quelques minutes et me suis rendu compte qu'elle avait raison. La sécurité a trait effectivement aux mots de passe et cartes de crédit. Au moins pour l'utilisateur final. Ceux d'entre nous qui travaillent au sein d'une l'entreprise pensent que la sécurité concerne les algorithmes cryptographiques, le problème de savoir si Kerberos est un meilleur choix que TLS ou NTLMv2, les avantages de WS*, le problème de savoir si les hachages de mot de passe doivent utiliser une valeur aléatoire et tous les autres sujets ésotériques que nous aimons aborder. Bien sûr, nous avons un point de vue très différent et plus profond que les utilisateurs finaux, mais nous avons, généralement perdu de vue une chose fondamentale : la sécurité, pour ceux que nous devons aider, a trait aux mots de passe et cartes de crédit.

Certes, tout cet ésotérisme dont nous aimons discuter et les nouvelles technologies que nous aimons inventer sont destinés à protéger les données de l'utilisateur final. Pourtant, je pense que nous avons perdu le cap. En tant que sous-culture de sécurité du monde de l'informatique, nous existons pour répondre à un besoin particulier de nos ressources, celui de conserver les données en sécurité. Cela, inclut bien sûr, la garantie que les éléments informatiques peuvent être utilisés en toute sécurité. C'est exactement ce dont il s'agit.

Dans les rubriques précédentes, j'ai fait remarquer que personne ne décide d'acheter un ordinateur pour exécuter un logiciel antivirus. L'utilisateur achète un ordinateur pour effectuer des opérations bancaires en ligne, jouer à des jeux électroniques, écrire des messages électroniques, exécuter son travail ou certaines autres fonctions importantes. De la même manière, aucune entreprise ne subventionne un groupe de sécurité informatique simplement pour pouvoir implémenter NTLMv2. Les entreprises subventionnent les groupes de sécurité informatique afin que ceux-ci protègent les biens de l'organisation, permettant à l'entreprise dans son ensemble d'utiliser ses ressources informatiques en toute sécurité et d'atteindre ses objectifs métier.

Nous n'existons que pour aider.

Par conséquent, je dois demander si nous « aidons » vraiment de nos jours. Ou bien sommes-nous, en tant que sous-culture de sécurité, une entrave plus qu'une aide ? Les législateurs et les autorités de réglementation contribuent-ils à faire de nous des freins ? Je ne suis pas convaincu que toute cette nouvelle technologie que nous mettons en place aide vraiment les utilisateurs finaux. Donc, j'aimerais explorer quelques domaines où nous, fournisseurs informatiques du monde entier, faisons plus de mal que de bien.

Certains jours, il semble que la plupart des recommandations de sécurité et un grand nombre des technologies de sécurité que nous imposons à nos utilisateurs soient inopérables, incorrectes, incompréhensibles ou (dans de nombreux cas) les trois à la fois. Dans cette série en trois parties, j'examinerai les façons nous déroutons les utilisateurs en donnant des conseils et en déployant des technologies qui sont responsables d'un ou de plusieurs de ces trois « i ».

Conseils de sécurité inopérables

Une des meilleures façons de dérouter les gens c'est de donner des conseils de sécurité inopérables. S'ils sont incorrects en plus, vous gagnez des points de bonus. La figure 1 illustre un conseil courant éprouvé théoriquement judicieux et totalement inutile.

Figure 1 Conseils de sécurité inopérables (cliquer sur l'image pour l'agrandir)

Vous connaissez cette recommandation qui dit d'utiliser un mot de passe différent pour chaque compte en ligne que vous possédez ? Il y a trente ans cette recommandation avait un sens. Le nombre de personnes qui se connectaient sur ce qui est devenu finalement Internet n'était que de quelques centaines et c'était des personnes très intelligentes qui ne choisissaient pas de bons mots de passe. Malheureusement, ce conseil est maintenu et ne cesse de se répéter et il n'y a pas eu d'effort apparent pour adapter ce conseil à l'utilisation actuelle des ordinateurs.

Combien de comptes en ligne possédez-vous ? Personnellement, j'en ai 115, plus ou moins quelques-uns dont je n'effectue pas le suivi. Le conseil de la figure 1 suggère non seulement que je dois posséder 115 mots de passe différents, mais aussi que je dois modifier ces 115 mots de passe tous les 30 à 60 jours. En d'autres termes, je dois modifier 2 à 4 mots de passe tous les jours. (Faites les calculs : Cela signifie également que j'aurais entre 690 et 1380 mots de passe dans une année).

Alors que le personnel technique sur certains sites offrant ce conseil peut proposer 4 bons mots de passe par jour et conserver 115 mots de passe actuels dans la mémoire à court terme, vous pouvez être certain que 99,99 % du public surfant sur le Web ne pourront pas le faire.

Le conseil de ne pas utiliser les mêmes mots de passe partout est correct et judicieux d'un point de vue purement théorique, de même que le conseil de modifier vos mots de passe tous les 30 à 60 jours. Mais ce conseil est également inopérable. Étant donné le nombre de mots de passe que possèdent les utilisateurs actuellement, ils ne peuvent tout simplement pas suivre ce conseil sans une aide quelconque, comme un papier ou un logiciel. Entrez l'exemple suivant.

Inopérable et inexact

Le conseil illustré à la figure 2, qui vient du site Web d'une des plus grandes banques monde, est inopérable et incorrect. Les informations fournies sous le titre « Read our password advice » (Lire nos conseils sur les mots de passe) répètent la ligne « different passwords everywhere » (pas les mêmes mots de passe partout). Elles recommandent également de ne jamais les écrire.

Figure 2 Conseils inopérables et incorrects (cliquer sur l'image pour l'agrandir)

Donc maintenant je possède 115 mots de passe différents, je dois créer 4 nouveaux mots de passe chaque jour et je ne suis pas autorisé à les écrire. Pendant un moment, je pensais que j'étais stupide puisque je ne pouvais pas me rappeler tous mes mots de passe. Puis j'ai découvert que tout le monde était pareil. Les êtres humains ne peuvent tout simplement pas se rappeler 115 mots de passe. Nous pouvons nous rappeler et traiter environ sept informations, c'est comme cela que nous sommes programmés. Si vous suivez la plupart des conseils sur les mots de passe que vous trouvez sur Internet, ils ne suffisent même pas pour un seul mot de passe (voir « The Magical Number Seven, Plus or Minus Two : Some Limits on Our Capacity for Processing Information » de George A. Miller, qui est disponible à l'adresse musanim.com/miller1956).

Malheureusement, lorsqu'il s'agit de conseils sur les mots de passe, notre secteur trompe régulièrement les utilisateurs. Si la sous-culture de sécurité conseille de ne pas utiliser les mêmes mots de passe partout, nous devons également leur dire comment, et cela veut dire qu'il faut enregistrer et stocker ces mots de passe dans un endroit sécurisé. Écrivez-les sur une feuille de papier, utilisez un document sécurisé ou utilisez un outil spécialisé, comme PasswordSafe (sourceforge.net/projects/passwordsafe). Admettez-le, nous enregistrons nos mots de passe ou nous utilisons le même mot de passe partout. En fait, une enquête récente a montré que 88 % des utilisateurs ont le même mot de passe sur tous les systèmes où ils doivent être authentifiés (voir msnbc.msn.com/id/24162478).

Le conseil de ne pas écrire votre mot de passe est certainement un facteur contribuant à cette tendance. Ce que nous devons faire, c'est apprendre aux utilisateurs à gérer les mots de passe (et les autres données sensibles), au lieu de leur apprendre à ne pas gérer ces informations du tout. Ils seront alors beaucoup moins susceptibles de compromettre leurs informations d'identification.

Conseil incompréhensible

Les deux premières figures répètent le vieux conseil qui fonctionnait bien dans les années 60, 70 et 80, avant que les utilisateurs de base ne se connectent et n'utilisent les services Web. Depuis, personne ne s'est plaint de ce type de conseil car il est généralement admis.

Ce type de conseil déroute les utilisateurs qui peuvent se sentir coupable de stocker leurs mots de passe quelque part. En donnant ce type de conseil, au lieu d'aider les utilisateurs à effectuer des actions correctes, les professionnels de sécurité font du mal. Après tout, ce n'est pas la responsabilité de l'utilisateur de déterminer comment gérer leur sécurité. C'est le rôle des professionnels de sécurité. Nous devons déterminer des moyens acceptables pour nos utilisateurs de gérer tous leurs comptes en ligne. Mais comme la plupart des recommandations répètent les mêmes conseils démodés, les utilisateurs ont recours aux pense-bêtes et aux tableurs pour assurer le suivi de leurs nombreux mots de passe.

Comme mécanisme d'authentification, les mots de passe ont beaucoup à offrir. Cependant, le problème principal avec les mots de passe est que les êtres humains ont du mal à s'en souvenir. Au lieu d'essayer de résoudre un problème de nature humaine, le monde de l'informatique continue à inventer toutes sortes de nouveaux mécanismes pour remplacer les mots de passe, ou pire encore, pour augmenter leur nombre. Les utilisateurs sont encore plus déroutés.

Imaginez ma surprise la dernière fois que j'ai accédé à un certain site de services financiers et que l'écran d'ouverture de session contenait seulement une zone de texte de nom d'utilisateur (voir la figure 3).

Figure 3 Où dois-je taper mon mot de passe ?

Tout d'abord j'ai pensé que j'avais atterri sur un site Web malveillant. Ensuite, j'ai validé rapidement le site, cette étape était facile puisque le site présentait un certificat et je me suis rendu compte qu'en fait j'étais au bon endroit. Le problème est que les gens sont habitués à voir deux champs de texte, le nom d'utilisateur et le mot de passe, présentés ensemble lors de la connexion à un site. Depuis des années ils rencontrent le même flux de travail courant. Ainsi lorsque vous êtes brusquement confronté à un site qui demande uniquement votre nom d'utilisateur, vous êtes stupéfait. Il s’avère que dans ce cas le fournisseur avait implémenté une technologie qui utilise des images permettant d'identifier le site pour les utilisateurs afin d'empêcher les attaques de phishing. Lorsque vous remplissez votre nom d'utilisateur, le site fait apparaître un écran avec une image identifiable, comme illustré à la figure 4.

Figure 4 Certains sites utilisent maintenant des images permettant d'authentifier le site pour un utilisateur (cliquer sur l'image pour l'agrandir)

Théoriquement vous savez quelle image va avec quel site. Si l'image correcte n'est pas affichée, vous pouvez identifier le site comme étant faux. Cela, en soi, est un concept solide. En supposant que l'utilisateur sait quelle image va avec quel site, cette stratégie a un sens.

Bien sûr, le lecteur astucieux remarque la barre d'adresses verte à la figure 4. Cela signifie que ce site utilise SSL et les certificats à validation étendue (EV), raison pour laquelle la barre d'adresses est verte. Cela signifie également que l'idée d'utiliser l'image pour identifier le site ne fournit pas de valeur supplémentaire. Au lieu de cela, l'image ne fait qu'ajouter plus de confusion au moins pour certains utilisateurs finaux. Le site s'est déjà identifié à l'utilisateur, il a fourni un certificat qui contient le nom de l'entreprise, l'adresse du site Web et le nom de l'émetteur de confiance. Le fait que la barre d'adresses est verte m'indique que l'entreprise a atteint l'étape supplémentaire de payer trois fois plus pour un certificat EV.

Alors, bien sûr, les images peuvent également être fausses. Si l'utilisateur peut soumettre sa propre image, il existe des moyens par lesquels l'attaquant peut probablement déterminer quelle image est utilisée. Il y a également de fortes chances que l'utilisateur emploie la même image sur chaque site, donc tout ce que l'attaquant aura à faire, c'est de créer un site avec un contenu que l'utilisateur évaluera (je vous laisse trouver vos propres exemples) et de demander à l'utilisateur une image à utiliser pour la vérification du site. Si l'utilisateur emploie la même image pour tous les sites, ce nouveau site aura maintenant accès à l'image employée par l'utilisateur, par exemple, son site bancaire.

Alors que certains sites vous permettent de choisir votre propre image, d'autres utilisent une bibliothèque de photos en stock. Le site de la figure 4, par exemple, possède 318 photos en stock parmi lesquelles choisir. L'astuce précédente ne fonctionne pas pour les sites qui ne permettent pas à l'utilisateur d'envoyer sa propre photo. Cependant, si l'utilisateur ne peut pas choisir sa propre image, la probabilité que l'utilisateur se rappelle quel site va avec quelle image sera peu probable pour les sites qu'il ne visite pas fréquemment. Honnêtement, je ne sais pas quelle image j'utilise sur le site affiché à la figure 4, même si je peux vous assurer que ce n'est pas celui qui est affiché dans la capture d'écran.

Le problème avec cette approche basée sur les images est qu'un attaquant peut afficher à peu près n'importe laquelle des 318 images ou choisir un cliché de Flickr au hasard et beaucoup d'utilisateurs supposeront que l'image est la bonne. Si la majorité des gens pouvait se souvenir de choses comme quelle image va avec quel site, nous n'aurions pas tous les problèmes liés au phishing et à la sécurité que nous avons aujourd'hui.

Alors pourquoi utiliser une image pour authentifier le site pour l'utilisateur lorsque le site s'est déjà authentifié à l'aide du certificat ? Pourquoi ne pas utiliser tout simplement ce certificat et aider les utilisateurs à apprendre à le valider ? Les certificats prouvent déjà l'identité du site à l'utilisateur.

Le processus pour obtenir un certificat est certainement beaucoup plus sécurisé que le processus pour obtenir une image d'authentification d'un site d'utilisateurs. S'il s'agit d'un certificat EV et que vous utilisez Internet Explorer® 7 ou Firefox 3, le navigateur mettra même en surbrillance les informations de certificat pertinentes dans la barre d'adresses. Malheureusement, la mise en surbrillance fonctionne seulement avec les certificats EV qui coûtent très cher.

Les pièges d'authentification de site basée sur les images

La technologie d'authentification d'image a de nombreux problèmes. Tout d'abord, il devient très facile de collecter des noms d'utilisateur d'un site. En effet, le site illustré à la figure 4 présentera la boîte de dialogue affichée à la figure 5 si vous entrez un nom d'utilisateur incorrect. Après avoir tapé un nom d'utilisateur correct pour un utilisateur qui a choisi une image secrète, l'image secrète de cette personne s'affiche. Évidemment, la connaissance de cette image peut être très précieuse pour un attaquant essayant de collecter des informations sur un utilisateur.

Figure 5 Les sites d'authentification d'images permettent la collecte facile de noms d'utilisateurs

Le type d'implémentation illustré ici n'a pratiquement pas de valeur de sécurité. L'attaquant peut simplement dupliquer le flux de travail d'ouverture de session sur un faux site. Le faux site demande un nom d'utilisateur et le transmet au vrai site. Vous pouvez même utiliser AJAX sur le client pour mettre à jour le formulaire en temps réel pour une présentation extra cool. En outre si le site légitime n'a pas atténué les attaques de contrefaçon de requête intersites sur le formulaire d'ouverture de session, le code AJAX peut même envoyer directement la requête au vrai site sauf si le navigateur possède des atténuations pour les requêtes XML-HTTP intersites.

Maintenant, une fois le résultat renvoyé, l'attaquant peut analyser les données, extraire l'image et l'afficher pour l'utilisateur final. En d'autres termes, n'importe quel attaquant pouvant présenter un faux site de connexion à l'utilisateur peut également afficher l'image secrète de l'utilisateur. Le résultat direct est qu'il n'y a absolument pas de valeur ajoutée à l'authentification de site basée sur les images. L'image est affichée avant l'authentification de l'utilisateur sur le site et, par conséquent, elle est disponible pour un attaquant qui possède, ou peut obtenir, le nom d'utilisateur.

En supposant que l'utilisateur n'a jamais appris à chercher un certificat avant d'envoyer des formulaires, et c'est une supposition sûre considérant que l'utilisation de l'authentification de site basée sur les images est elle-même basée sur cette même supposition, il est facile d'obtenir un nom d'utilisateur. Par ailleurs, puisque les schémas d'authentification de site basée sur les images répondent différemment à un nom d'utilisateur valide par rapport à un nom d'utilisateur non valide, la collecte de nom d'utilisateur est facile. L'attaquant peut même le faire hors bande, avant même qu'une attaque soit lancée.

Au final, nous avons des utilisateurs qui croient qu'ils sont plus sécurisés ou qui sont simplement plus déroutés. Nous avons dépensé des quantités importantes des fonds des actionnaires en implémentant l'authentification de site basée sur les images et nous ne l'avons pas rendu plus difficile pour les utilisateurs malveillants afin de convaincre les utilisateurs finaux d'envoyer leurs informations d'identification à de faux sites Web.

C'est tout ce que je voulais dire dans le cadre de cet article sur la Vigilance sécurité. Consultez le mois prochain la deuxième partie de cet article lorsque j'aborderai d'autres exemples de pratiques de sécurité incorrectes et de mauvaises implémentations d'authentification.

Jesper M. Johansson est architecte de logiciels, chargé des problèmes de sécurité logicielle et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en systèmes d'informations de gestion, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans le domaine de la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.