Vigilance sécuritéMots de passe et cartes de crédit, deuxième partie

Jesper M. Johansson

Sommaire

Processus d'ouverture de session pseudo-multifacteur
Le problème des compléments de navigateur
L'authentificateur ne doit jamais changer
Vers des mots de passe moins sûrs
Contournement de l'ouverture de session pseudo-multifacteur
Les problèmes des mots de passe compromis
Quelques points positifs
Tromper les utilisateurs avec un mirage de sécurité
Ouvrir ou ne pas ouvrir
Fournir des communications sécurisées
Question de confidentialité

Bienvenue dans la deuxième des trois parties de ma série d'articles sur la façon dont, lorsqu'il s'agit de problèmes de sécurité, l'industrie informatique perturbe les consommateurs plus qu'elle ne les aide. Dans l'édition de juillet 2008 de TechNet Magazine, j'ai décrit des conseils de sécurité inefficaces et inexacts ainsi que des flux de travail d'ouverture de session déroutants. (Si vous n'avez pas encore lu la Partie 1, vous la trouverez

à l'adresse technet.microsoft.com/magazine/cc626076.). J'y expliquais à quel point des conseils en sécurité extrêmement courants bien qu'inadaptés et des flux de travail d'ouverture de session incorrects semaient la confusion chez les consommateurs et minaient leurs efforts pour protéger leurs informations personnelles.

Dans cette édition, je poursuis cette discussion avec de nouveaux exemples pratiques issus du monde de la sécurité des particuliers. La dernière partie de cette série, qui inclura un « appel aux armes » destiné aux professionnels de la sécurité du monde entier, paraîtra dans la prochaine édition de TechNet Magazine.

Processus d'ouverture de session pseudo-multifacteur

Au mois d'octobre 2005, le FFIEC (Federal Financial Institutions Examination Council) a publié ses consignes « Authentication in an Internet Banking Environment » (Authentification dans un environnement bancaire sur Internet)(voir www.ffiec.gov/press/pr101205.htm). Le calendrier pour sa mise en œuvre était de seulement 14 mois et les institutions financières américaines ont commencé à se démener pour essayer de trouver comment respecter ces nouvelles consignes.

La plupart des institutions n'ont pas tenu ce calendrier. Bon nombre des institutions qui ont finalement respecté les directives y sont parvenues grâce à des mesures qui n'ont d'autre but que de respecter les consignes. En d'autres termes, les institutions ont pris des mesures qui n'améliorent absolument pas la sécurité des clients (ce sont simplement des pratiques de « comédie sécuritaire »). Parmi les exemples de solutions inutiles, celles qui tentent de créer une authentification multifacteur sans être réellement multifacteur figurent parmi les plus intéressantes.

Considérons par exemple la technologie qui mesure la cadence de frappe lorsqu'un utilisateur tape son mot de passe. Utilisée sur un site Web, cette solution présente une boîte de dialogue d'ouverture de session qui ressemble en tous points à l'ancienne. Cette boîte de dialogue, cependant, est maintenant un objet Adobe Flash.

L'objet Flash enregistre la cadence de frappe de l'utilisateur, notamment les caractéristiques de temps de pression sur les touches et de temps entre les frappes de touche. Ces données sont envoyées au site Web avec le mot de passe, où elles sont comparées aux valeurs stockées. Tant que les données de cadence de frappe restent dans une certaine variance des données stockées, et que le mot de passe correspond, l'ouverture de session est acceptée. L'idée générale est que ceci permet au site d'utiliser une méthode d'authentification pseudo-biométrique, sans devoir installer de matériel tiers sur le client.

J'appellerai ceci l'authentification pseudo-multifacteur. Il ne s'agit pas d'une véritable authentification multifacteur, qui mesure deux des facteurs canoniques suivants ou plus :

• Quelque chose que l'utilisateur a (comme une carte à puce)
• Quelque chose que l'utilisateur sait (comme un mot de passe)
• Quelque chose l'utilisateur est (comme une empreinte digitale)

Au lieu d'inclure plusieurs facteurs dans le processus d'authentification, l'authentification pseudo-multifacteur lit plusieurs paramètres à partir d'un facteur unique : le mot de passe. Il utilise alors ces paramètres supplémentaires pour faire des déductions sur quelque chose que l'utilisateur est.

La technologie utilisée pour l'authentification pseudo-multifacteur souffre de nombreuses failles. Considérées ensemble, ces failles rendent la technologie largement inefficace pour la résolution des problèmes de sécurité qu'elle prétend résoudre.

Le problème des compléments de navigateur

Les systèmes d'authentification pseudo-multifacteur s'appuient sur des compléments de navigateur pour fournir le traitement côté client sophistiqué dont ils ont besoin. Tout logiciel, bien sûr, contient des bogues, et certains de ces bogues causent des vulnérabilités. Ces vulnérabilités deviennent un vrai problème lorsque le logiciel est difficile à mettre à jour et que l'utilisateur ne sait même pas si une mise à jour a été installée.

Les compléments de navigateur présentent malheureusement ces deux caractéristiques : ils sont difficiles à mettre à jour et ne fournissent pas à l'utilisateur d'informations suffisantes pour déterminer si la version installée est à jour. Par conséquent, l'utilisateur doit exposer sur Internet un morceau de logiciel qui ne serait peut-être pas nécessaire autrement.

Dans certains cas, l'actualisation d'un complément nécessitera des visites régulières sur son site Web pour le téléchargement des mises à jour. Il va sans dire qu'il est peu probable que cela arrive pour la plupart des utilisateurs. Tout système nécessitant qu'un utilisateur final expose à Internet un logiciel supplémentaire non apparenté simplement pour fournir une fonctionnalité de sécurité doit faire l'objet d'une réflexion poussée.

L'authentificateur ne doit jamais changer

Le facteur « quelque chose que vous êtes » a une particularité, peut-être même un défaut, qui n'affecte pas les deux autres facteurs. Tandis que vous pouvez modifier les mots de passe (quelque chose que vous savez) et fabriquer de nouveaux jetons de sécurité (quelque chose que vous avez), le nombre d'authentificateurs biométriques que vous pouvez utiliser est assez limité. Dans le cas des empreintes digitales, par exemple, vous en avez dix, généralement pour la vie. Et si vous perdez un de ces « codes » dans un accident, vous ne pourrez généralement pas le remplacer.

Examinons à présent comment ceci s'applique à l'exemple d'ouverture de session pseudo-multifacteur. La mesure collectée sous forme d'élément d'un autre facteur ne peut pas être facilement remplacée ou modifiée. Bien sûr, lorsque le mot de passe change, la façon dont l'utilisateur le tape change, mais sa façon générale d'appuyer sur les touches du clavier ne change pas. C'est exactement ce sur quoi repose cette technique. Si ces mesures étaient compromises, il pourrait être possible de les synthétiser. Tout au moins, un attaquant peut capturer ces mesures et les rejouer.

Vers des mots de passe moins sûrs

Il est tout à fait judicieux d'utiliser des mots de passe longs et de modifier vos mots de passe fréquemment. Et, comme je l'ai expliqué dans la première partie de cette série, il est également recommandé (contrairement à ce que d'aucuns conseillent) d'enregistrer vos mots de passe, de façon sécurisée, bien sûr. Cependant, ces pratiques ne sont pas favorables à la saisie manuelle de votre mot de passe. Un mot de passe long est plus difficile à taper, et un mot de passe enregistré est bien plus utile lorsque vous pouvez le copier et le coller. L'une des meilleures façons de tenir à jour une centaine de mots de passe ou plus consiste à utiliser un utilitaire logiciel tel que Password Safe (disponible sur le site sourceforge.net/projects/passwordsafe). Ce type d'outil vous permet de générer des mots de passe entièrement aléatoires, de les enregistrer sous une forme chiffrée et de les coller dans les boîtes de dialogue d'ouverture de session. En fait, avec ce type d'outil, vous n'avez pas même besoin de connaître votre mot de passe.

Mais voilà où le bât blesse : vous ne pouvez pas mesurer la cadence de frappe si l'utilisateur ne tape pas le mot de passe. Et si vous devez taper le mot de passe dans un objet qui mesure la cadence de frappe, cette technique de gestion des mots de passe commence à montrer ses faiblesses. En effet, il n'est pas simple de taper correctement d'un mot de passe de 15 caractères entièrement aléatoires. Les utilisateurs choisiront donc généralement de simplifier leurs mots de passe lorsqu'ils seront confrontés à ce type de système. Pourtant, un mot de passe de 15 caractères entièrement aléatoires est à lui seul beaucoup plus sûr qu'un mot de passe plus court associé à un système d'authentification pseudo-multifacteur.

En fait, l'authentification pseudo-multifacteur, implémentée de façon exclusive, oblige les utilisateurs à utiliser des mots de passe moins sûrs. Malheureusement, comme vous le verrez bientôt, la prise en charge des utilisateurs qui utilisent des techniques de gestion des mots de passe correctes annule pratiquement tout avantage offert par les systèmes d'authentification pseudo-multifacteur.

Contournement de l'ouverture de session pseudo-multifacteur

Même si un site implémente l'authentification pseudo-multifacteur, il toujours doit prendre en charge une façon de contourner ce système. Tout d'abord, peu de sites peuvent demander à tous leurs utilisateurs d'installer une technologie d'une « quarte partie » pour pouvoir accéder au site. Certains utilisateurs (certains auteurs de TechNet Magazine, par exemple) refuseront toujours d'installer ce type de logiciel.

Ensuite, la cadence de frappe peut varier pour de nombreuses raisons et les sites doivent par conséquent s'adapter à cette donnée. Par exemple, imaginons qu'un utilisateur se foule le poignet et que sa cadence de frappe change temporairement. Comment alors accédera-t-il au site si celui-ci analyse sa cadence et pense qu'une autre personne essaie de se connecter avec ses informations d'identification ? Si la blessure était permanente, l'utilisateur pourrait réinitialiser la valeur de cadence stockée. Cependant, dans le cas d'une blessure temporaire, l'utilisateur ne voudra probablement pas réinitialiser la valeur stockée, et supposera que sa cadence de frappe reviendra bientôt à peu près à ce qu'elle était au début.

Enfin, tous les utilisateurs ne sont pas capables d'utiliser les systèmes d'authentification pseudo-multifacteur. Par exemple, une personne handicapée qui interagit avec l'ordinateur par une interface de reconnaissance vocale ne pourra peut-être pas renseigner la boîte de dialogue, selon qu'elle empêche ou non la saisie par programmation. Dans ce cas, un système alternatif prenant en charge les utilisateurs handicapés sera probablement exigé par la loi.

La façon la plus simple et la plus directe de s'adapter à tous ces scénarios consiste à prendre parallèlement en charge l'authentification par mot de passe standard.

Les problèmes des mots de passe compromis

Les systèmes d'authentification pseudo-multifacteur sont supposés répondre à divers problèmes liés à l'authentification par mot de passe. Toutefois, ces systèmes ne parviennent pas à apporter une réponse à toutes les façons dont les mots de passe peuvent être compromis. Il existe cinq méthodes principales permettant de compromettre les systèmes basés sur l'authentification par mot de passe, où « compromettre » signifie qu'un attaquant obtient et utilise le mot de passe d'un autre utilisateur :

• Déduction d'un mot de passe
• Enregistreurs de frappe
• Attaques par phishing
• Interrogation de l'utilisateur
• Pénétration dans un système stockant tout ou partie d'un mot de passe

La déduction de mot de passe n'est plus une méthode d'attaque très courante pour les criminels ; elle a été considérablement éclipsée par les enregistreurs de frappe et le phishing. La déduction de mot de passe n'est en outre atténuée que partiellement par l'authentification pseudo-multifacteur. Une approche conventionnelle de la déduction de mot de passe a peu de chances de fonctionner contre un système d'authentification pseudo-multifacteur puisque l'attaquant doit deviner le mot de passe et la cadence de frappe. Bien qu'il soit théoriquement possible de synthétiser les caractéristiques de frappe, il est rarement nécessaire de le faire parce que les véritables données peuvent généralement être capturées par une attaque par phishing ou un enregistreur de frappe. Par ailleurs, si le système fournit également une interface d'ouverture de session par mot de passe standard uniquement, il suffit à l'attaquant d'utiliser ce système pour deviner le mot de passe.

Qui plus est, les attaques par déduction du mot de passe sont largement mises en échec par les mots de passe forts. Si nous pouvons apprendre aux utilisateurs à utiliser des mots de passe plus forts, éventuellement à l'aide d'outils, l'authentification pseudo-multifacteur devient inutile. (Au contraire, les mots de passe simples qui sont généralement utilisés avec les systèmes d'authentification pseudo-multifacteur font en fait de la déduction de mot de passe une approche plus viable.) Ainsi, l'intérêt qu'on pourrait trouver ici à atténuer les attaques par déduction de mot de passe n'existe vraiment que si la mise en œuvre ne prend pas en charge les ouvertures de session par mot de passe uniquement. Et, comme je l'ai dit, ceci n'est pour ainsi dire jamais possible. En d'autres termes, si les utilisateurs utilisent des mots de passe plus faibles en présence de systèmes d'authentification pseudo-multifacteur, la déduction de mot de passe peut redevenir une méthode d'attaque viable ; l'authentification pseudo-multifacteur réduirait ainsi la sécurité, au lieu de l'augmenter. Il est nécessaire d'étudier davantage cette question.

L'authentification pseudo-multifacteur ne résout pas non plus le problème des enregistreurs de frappe. Je ne connais pas d'enregistreur de frappe qui soit couramment utilisé aujourd'hui pour capturer la cadence de frappe, mais cela ne veut absolument pas dire qu'aucun n'a jamais été conçu. Un enregistreur de frappe est un élément matériel placé entre le clavier et l'ordinateur, ou un logiciel qui capture les frappes. Dans les deux cas, l'enregistreur dispose d'un accès complet à toutes les données utilisées par la solution d'authentification pseudo-multifacteur.

En fait, l'enregistreur de frappe peut même accéder à plus de données dans la mesure où une solution d'authentification s'exécute en mode utilisateur tandis qu'un enregistreur de frappe se trouve à un niveau bien inférieur. Sans un chemin approuvé entre le clavier et l'objet Web utilisé pour capturer le mot de passe, il est impossible d'empêcher ce type de compromission. Si les solutions d'authentification pseudo-multifacteur deviennent suffisamment courantes, vous pouvez être certain que quelqu'un créera un tel enregistreur de frappe.

De même, les attaques par phishing ne sont pas mises en échec par l'authentification pseudo-multifacteur. Au lieu d'utiliser juste un faux écran d'ouverture de session, l'attaquant peut utiliser un objet Flash pour capturer le mot de passe ainsi que la cadence de frappe.

Certes, l'authentification pseudo-multifacteur peut être utile dans certains scénarios où la technique de l'attaquant lui permettra seulement de connaître le mot de passe de l'utilisateur. Par exemple, la façon la plus simple d'obtenir le mot de passe d'un utilisateur consiste à le lui demander. Malheureusement, ceci s'est révélé être une technique efficace, que ce soit en demandant aux gens directement, par téléphone ou par des messages de phishing.

Bien sûr, demander à un utilisateur sa cadence de frappe sera extrêmement moins efficace. De même, si une base de données de mots de passe d'une entreprise est compromise, l'attaquant n'aura probablement accès qu'aux mots de passe. Mais une fois encore, ces attaques ne seront atténuées que si le système ne fournit pas l'authentification standard par mot de passe uniquement.

Je dois également attirer votre attention sur le fait que si la base de données de mots de passe même est compromise, cela signifie que l'attaquant a probablement compromis le système beaucoup plus profondément encore qu'il ne le serait possible avec un seul mot de passe de compte utilisateur normal, ou même plusieurs. Par conséquent, il est relativement vain de tenter d'atténuer ce qu'un attaquant en possession d'une base de données de mots de passe peut faire.

Quelques points positifs

Pour être juste, je dois admettre que l'authentification pseudo-multifacteur peut aider à résoudre certains problèmes (à supposer que le système ne fournit pas l'option d'ouverture de session standard par mot de passe uniquement). Par exemple, elle peut être utilisée pour empêcher le partage de mot de passe. Cependant, ceci peut être un inconvénient pour les systèmes où il est légitime que plusieurs utilisateurs partagent des comptes, par exemple des comptes en banque communs.

En outre, une boîte de dialogue de connexion interactive correctement construite (pas une connexion à un site Web) pourrait forcer un utilisateur à franchir des étapes d'authentification supplémentaires si sa cadence de frappe ne correspondait pas. Ceci peut fournir une sécurité supplémentaire contre un compte compromis dans un environnement extrêmement sensible.

Tromper les utilisateurs avec un mirage de sécurité

L'une des meilleures façons de semer la confusion dans l'esprit des utilisateurs consiste à fournir des indications de sécurité inexactes. La plus courante est probablement l'image de cadenas affichée sur une page Web, comme illustré à la figure 1. Cette page va même jusqu'à afficher le mot « Secure » près du cadenas.

Figure 1 Exemple d'abus de l'icône de cadenas, une tendance préoccupante (Cliquez sur l'image pour l'agrandir)

Comme vous le savez sûrement, la simple présence d'une image de cadenas et du mot « Secure » sur une page n'en fait pas une page sécurisée. Pourtant, et c'est d'ailleurs très inquiétant, la pratique est courante, même parmi les sites Web de très bonne réputation, qui sont les plus ciblés. Par conséquent, de nombreux utilisateurs sont conditionnés à rechercher ces indicateurs visuels de sécurité dans le corps de la page Web au lieu de regarder là où ces indicateurs ont effectivement un sens : dans la barre d'adresse. (Le Wiki de contexte de sécurité Web W3C contient une entrée sur ce problème et est disponible à l'adresse w3.org/2006/WSC/wiki/PadlockIconMisuse.)

Il est malheureux qu'il y ait toujours autant d'exemples de cet usage inapproprié. La recherche a montré que les utilisateurs sont incapables d'identifier les sites Web malveillants même lorsque les certificats sont très évidents (voir www.usablesecurity.org/papers/jackson.pdf). Tout dépend de la capacité de distinguer facilement le faux du vrai, même lorsque vous ne disposez pas du vrai pour comparer. Ceci demande des connaissances ; le mirage de sécurité qui plane sur les pages Web freine le développement de cette compétence car les utilisateurs sont conduits vers la mauvaise information.

Une variante particulièrement dérangeante de ce problème est illustrée à la figure 2. Ici, la page qui affiche les informations n'est en fait pas sécurisée. Si vous regardez la barre d'adresses, vous voyez la mention « http » indiquant le protocole. Ce site utilise une technique d'optimisation très commune : au lieu de chiffrer la page contenant le formulaire d'ouverture de session, seul l'envoi du formulaire est chiffré. La connexion est sécurisée, comme la page le dit, si vous supposez que « sécurisé » est synonyme de « chiffré ». Cependant (et ceci est extrêmement important), l'utilisateur n'a aucun moyen de vérifier où les informations d'identification sont envoyées avant qu'elles le soient ! Le site n'affiche pas de certificat authentifiant le site à l'utilisateur avant que le formulaire ne soit envoyé. Il s'agit d'un jeu de confiance, comme se laisser tomber en arrière en pensant que la personne derrière vous vous rattrapera. Au moment où le formulaire est envoyé, les dommages sont peut-être déjà faits.

Figure 2 Mirage de sécurité sur une page non sécurisée (Cliquez sur l'image pour l'agrandir)

Le protocole SSL (Secure Sockets Layer), qui fournit la sécurité dans HTTPS, sert deux objectifs importants. D'abord, il authentifie le serveur à l'utilisateur. Ensuite, il fournit un mécanisme simple pour négocier une clé de chiffrement de session pouvant être utilisée entre le client et le serveur.

Lorsque seul l'envoi du formulaire est chiffré, le premier objectif, et le plus important, n'est pas atteint. Les sites employant cette optimisation utilisent SSL uniquement comme un moyen de négocier les clés. Ironiquement, ils pourraient le faire simplement en employant un protocole de négociation de clés standard, évitant ainsi le coût et le traitement du protocole SSL.

Le site illustré à la figure 2 n'est pas seul en son genre. De nombreux sites fournissent la protection SSL uniquement pour l'envoi d'un formulaire, pas pour le formulaire lui-même. Ce site particulier, cependant, présente une caractéristique encore plus troublante. Si vous tapez https://www.<site>.com (notez l'indicateur https sécurisé) dans la barre d'adresse du navigateur, le site vous redirigera vers sa version non-SSL ! Même si vous essayez d'inspecter un certificat avant d'envoyer vos informations d'identification au site, le site refuse de vous afficher le certificat.

Tous les sites ne sont pas aussi mal conçus, mais de nombreux sites le sont. Et deux des plus grandes sociétés émettrices de cartes de crédit aux États-Unis comptent parmi les coupables. En fait, parmi les trois grandes sociétés émettrices de cartes de crédit que j'utilise, seul American Express fournit un certificat sur le formulaire d'ouverture de session. American Express redirige même les requêtes HTTP vers HTTPS. Bien joué !

Une dernière réflexion concernant le mirage de sécurité et l'absence de certificats sur le formulaire d'ouverture de session. Vous pouvez vous demander pourquoi un site ferait cela. Simplement par souci d'économie. La présentation de certificats nécessite le chiffrement de la page, et le chiffrement de la page génère une charge de traitement. Cette charge de traitement signifie qu'un plus grand nombre d'ordinateurs sont nécessaires pour assurer la même charge de travail. Et plus d'ordinateurs coûtent plus d'argent. Malheureusement, lorsqu'il s'agit de choisir entre protéger les informations personnelles des clients et augmenter les profits, beaucoup d'organisations optent pour la hausse des profits.

Ouvrir ou ne pas ouvrir

Récemment, j'ai reçu un étonnant message électronique de ma société d'assurance maladie. Quiconque a utilisé un ordinateur au cours des 10 dernières années sait qu'il ne doit jamais ouvrir de pièces les jointes d'un message non sollicité. Imaginez donc ma surprise lorsque j'ai reçu le message illustré à la figure 3.

Figure 3 Message électronique contenant une « pièce jointe sécurisée » (Cliquez sur l'image pour l'agrandir)

Apparemment j'avais posé une question sur le site Web de la société d'assurance maladie (ce que j'avais eu le temps d'oublier lorsque le message suspect est arrivé). Voici comment la société d'assurance répondait. Au début, j'ai pensé que c'était une manœuvre de phishing astucieuse. Quand je me suis rendu compte c'était un message légitime, les poils ont commencé à se dresser sur ma nuque.

La toute première instruction est de double-cliquer sur la pièce jointe pour commencer à décrypter le message. La communauté des spécialistes de la sécurité et les administrateurs informatiques au sens large ont passé les 10 dernières années à essayer d'apprendre aux gens à ne PAS double-cliquer sur les pièces jointes. Sur ce, une entreprise arrive (permettez-moi de préciser que mon prestataire de soins de santé n'est pas la seule organisation utilisant cette approche) et dit que je dois cliquer sur la pièce jointe pour ma sécurité. Comment l'utilisateur doit-il agir dans cette situation ? Quel comportement apprend-il ou désapprend-il ?

Ensuite, j'ai utilisé la fonctionnalité d'aperçu de Microsoft® Office Outlook® 2007 pour l'afficher. Comme vous pouvez le voir dans la Figure 4, Outlook a supposé que ce message pouvait être une attaque et m'a conseillé de ne pas l'ouvrir !

Figure 4 Outlook 2007 considère le document sécurisé comme hostile (Cliquez sur l'image pour l'agrandir)

Il est à la fois ironique et triste qu'une société d'assurance maladie viole les vérifications de sécurité les plus élémentaires utilisées dans le client de messagerie le plus populaire au monde. Dans la mesure où cette entreprise n'a même pas pris la peine de tester sa nouvelle solution de sécurité avec Outlook, je dois me demander ce qu'elle fait d'autre dans le but de protéger mes informations personnelles. Ou, pour être plus direct, quelles autres solutions sont implémentées par l'entreprise dans le seul but d'éviter d'être accusée de ne pas protéger suffisamment les informations confidentielles de ses clients ? Cela ressemble à la comédie sécuritaire jouée par les institutions financières. Dans ce cas, je pense que l'objectif principal de la solution est d'éviter les accusations, pas de protéger les clients.

J'ai voulu voir ce que la pièce jointe était vraiment. Elle s'est avérée être un objet de contrôle ActiveX®. Pour voir la pièce jointe, j'ai dû l'ouvrir dans Internet Explorer® et installer l'objet. J'ai alors vu s'afficher l'écran rassurant illustré à la figure 5. Comme vous pouvez le voir, les concepteurs ont fait beaucoup d'efforts pour donner au message l'aspect d'une enveloppe postale conventionnelle ; elle porte même un tampon stipulant que l'enveloppe est fiable.

Figure 5 Le document Secure affiche une enveloppe estampillée « Trusted » (Fiable) (Cliquez sur l'image pour l'agrandir)

Ce type de technologie est préoccupant pour de nombreuses raisons. Premièrement, il renforce un très mauvais comportement de la part de l'utilisateur : l'ouverture de pièces jointes non sollicitées. Deuxièmement, dans le message lui-même, il donne de très mauvais conseils en recommandant de configurer le système pour toujours ouvrir des pièces jointes sans invite. Troisièmement, vu les messages contradictoires de l'ordinateur, où le message électronique dit qu'il est fiable et Outlook dit qu'il ne l'est pas, le message paraît très suspect. Enfin, la vraie pièce jointe contient un mirage de sécurité sans importance pour convaincre l'utilisateur qu'elle est effectivement fiable. Si l'utilisateur apprend à faire confiance à ces types de messages, il n'y a plus qu'un petit pas à franchir avant l'approbation de messages malveillants d'un aspect similaire.

Fournir des communications sécurisées

Certes, le problème que cette technologie prétend combattre est très important. Communiquer avec les clients de façon fiable est difficile. Cependant, cette solution particulière est trop sophistiquée. Elle sèmera probablement la confusion chez le client et mènera potentiellement au résultat opposé à ce qu'elle visait : la compromission du système du client.

Les sites Web les mieux conçus utilisent maintenant un « centre de messages ». Dans cette conception, lorsque l'entreprise a besoin de communiquer avec le client, il envoie un message électronique disant quelque chose comme : « Vous avez un message dans le centre de messages. Veuillez vous rende sur notre site Web, ouvrir une session et cliquer sur le lien Centre de messages pour afficher le message ». Une entreprise reçoit des points de bonus si elle utilise S/MIME (Secure Multipurpose Internet Mail Extensions) pour signer tous les messages électroniques présentés aux clients, de sorte que l'utilisateur puisse authentifier la source. Il y a un autre bonus si le texte n'inclut pas d'éléments « Cliquez sur ce lien » dans le message électronique. L'utilisateur doit taper l'URL de l'entreprise manuellement pour garantir qu'il accède au site prévu.

Avec un centre de messages et un message signé, une entreprise peut emprunter un chemin fiable pour communiquer avec le client. Tout ce que le client voit pendant le flux de travail de message est authentifié, et l'entreprise ne favorise pas de mauvaises pratiques en termes de sécurité.

Question de confidentialité

J'ai passé les deux premières parties de cette série à décrire comment les professionnels de la sécurité rendent en fait un mauvais service aux utilisateurs. C'est notre travail de maintenir la sécurité. Mais beaucoup des décisions prises et des solutions implémentées créent une confusion chez les utilisateurs, en leur apprenant à faire de mauvais choix et en leur donnant un sens de la sécurité erroné. Nous ne devons pas submerger les utilisateurs par ces idées contradictoires.

Comme je l'ai dit auparavant, pour la majorité des utilisateurs, la sécurité consiste simplement à protéger les mots de passe et les numéros de carte de crédit. Ils veulent que la technologie fonctionne et soit digne de confiance. Malheureusement, ils doivent prendre des décisions, et il est de notre devoir d'assurer qu'ils le fassent en toute connaissance de cause.

Dans la dernière partie de cette série, j'expliquerai comment certaines des technologies les plus importantes accessibles au grand public ne remplissent pas toutes les attentes. Je présenterai également mon appel aux armes. N'oubliez donc pas de lire également l'édition de septembre 2008 de Vigilance sécurité.

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 gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans 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. La reproduction partielle ou totale sans autorisation est interdite.