Brevet FR3022375A1 — publié le 20151218

PROCEDE ET DISPOSITIF DE SECURISATION D'UN SYSTEME PROTEGE PAR MOT DE PASSE DOMAINE TECHNIQUE DE L'INVENTION La présente invention se rapporte au domaine des systèmes client-serveur mettant en oeuvre un serveur et une application client installée sur un terminal d'un utilisateur, dans lesquels les utilisateurs doivent s'identifier par un mot de passe via l'application client pour obtenir des ressources du serveur. Un tel système est par exemple un système de messagerie électronique distribué sur un serveur de messagerie et une application client de messagerie. ARRIERE PLAN TECHNOLOGIQUE DE L'INVENTION On appelle système client-serveur un système mettant en oeuvre un serveur et un client communiquant selon un protocole de communication (par exemple le protocole http « HyperText Transfer Protocol »). Un client est un logiciel (ou par extension un terminal sur lequel est exécuté le logiciel) apte à demander l'exécution d'une opération par un serveur par envoi d'une requête contenant le descriptif de l'opération à exécuter. Un serveur est un logiciel (ou par extension un ordinateur sur lequel est exécuté le logiciel) apte à accomplir une opération sur requête d'un client, et lui transmettant le résultat par envoi d'une réponse contenant le résultat de l'opération. Certains systèmes client-serveur nécessitent une identification de l'utilisateur par transmission d'un nom et d'un mot de passe utilisateur au sein de la requête. Les clients sous la forme d'applications client paramétrées pour effectuer des connexions régulières vers leurs serveurs, nécessitent alors généralement une sauvegarde dudit mot de passe utilisateur. On note qu'on appelle application un logiciel d'application. De telles applications client sont par exemple des applications client de messagerie paramétrées pour effectuer des connexions régulières vers des serveurs de messagerie. On appelle application client de messagerie une application qui sert à lire et envoyer des courriers électroniques, et serveur de messagerie un logiciel qui sert à transférer des messages électroniques. Dans le cas d'une application client de messagerie, le mot de passe utilisateur est transmis à chaque requête vers le serveur de messagerie, c'est-à-dire à chaque vérification des messages électroniques, en général toutes les minutes voire moins. Lorsque le mot de passe est stocké par l'application client, il peut être récupéré par un tiers, par exemple si le terminal utilisateur sur lequel l'application client est installée est volé ou perdu. Or ce même mot de passe pourrait être utilisé pour accéder à toute autre application ou la session d'ordinateur de l'utilisateur, si celles-ci sont protégées par le même mot de passe. Pour sécuriser de tels systèmes client-serveur, il est connu de mettre en place des mécanismes d'identification à base de mots de passe non rejouables, aussi appelés mots de passe à usage unique (en anglais OTP « One-Time Password »). Un procédé et un dispositif pour permettre des identifications à base de mots de passe non rejouables sont par exemple décrits dans la demande de brevet CA 2611549 Al. Or, la mise en place de ces mécanismes nécessite de modifier l'application client et le serveur : il n'est donc pas possible d'utiliser les applications natives ou installées sur les terminaux utilisateurs sans les modifier. DESCRIPTION GENERALE DE L'INVENTION L'objet de l'invention offre une solution au problème évoqué précédemment, en proposant un procédé et un dispositif permettant de renforcer la sécurité d'un système serveur-client protégé par un mot de passe utilisateur, ledit système mettant en oeuvre un serveur et une application client installée sur un terminal utilisateur, ledit procédé et dispositif ne nécessitant pas de sauvegarde du mot de passe utilisateur sur le terminal, et cela sans modifier l'application client, le serveur ou leur protocole de communication. Selon un premier aspect, l'invention concerne donc un procédé de sécurisation d'un système client-serveur protégé par un mot de passe utilisateur, ledit système mettant en oeuvre un serveur et une application client installée sur un terminal d'un utilisateur, le procédé comportant les étapes suivantes : - Une passerelle mandataire réceptionne une première requête provenant de l'application client, ladite première requête comprenant un élément d'authentification intermédiaire préalablement mis à disposition de l'application client - La passerelle mandataire vérifie l'élément d'authentification intermédiaire compris dans la première requête - Si l'élément d'authentification intermédiaire est correct : - la passerelle mandataire obtient le mot de passe utilisateur - la passerelle mandataire envoie, à destination du serveur, une deuxième requête, ladite deuxième requête comprenant le mot de passe utilisateur obtenu - la passerelle mandataire réceptionne une réponse provenant du serveur - la passerelle mandataire envoie ladite réponse à l'application client. On appelle passerelle mandataire un dispositif placé entre l'application client et le serveur, et adapté pour intercepter et traiter les requêtes provenant de l'application client à destination du serveur. Grâce au procédé selon l'invention, l'application client n'a pas besoin de stocker le mot de passe utilisateur, puisque la passerelle mandataire se charge de l'obtenir et le transmettre au serveur. Le mot de passe utilisateur n'est donc pas stocké dans le terminal, ce qui évite qu'il soit compromis en cas de vol, perte ou piratage du terminal. De plus, le procédé est transparent pour l'application client et le serveur puisque l'application client dispose d'un élément d'authentification (par exemple un mot de passe dit « mot de passe intermédiaire » ou un certificat électronique dit « certificat électronique intermédiaire ») qu'elle peut envoyer dans chaque requête destinée au serveur (première requête), et puisque les requêtes (deuxièmes requêtes) reçues par le serveur comprennent le mot de passe utilisateur. L'application client et le serveur ne sont donc pas modifiés par l'invention. On note qu'on appelle certificat électronique (ou certificat numérique, ou certificat de clef publique) un élément d'authentification numérique utilisé pour identifier une personne physique ou morale, délivré par un tiers de confiance. Un certificat électronique est un ensemble de données comprenant au moins une clef publique, des informations d'identification (par exemple un nom, une localisation, une adresse e-mail) et au moins une signature. La génération des certificats électroniques et leurs cycles de vie sont généralement gérés au sein d'infrastructures à clefs publiques (en anglais PKI pour « Public Key Infrastructure »). Le procédé de sécurisation selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles. Dans un mode de réalisation, l'élément d'authentification intermédiaire est mis à disposition de l'application client selon les étapes suivantes : - Un serveur d'authentification reçoit une demande d'élément d'authentification intermédiaire provenant d'une application obtentrice installée sur le terminal - Le serveur d'authentification authentifie l'application obtentrice - Si l'application obtentrice est authentifiée : - Le serveur d'authentification envoie des attributs de l'élément d'authentification intermédiaire à une base de données intermédiaire - Le serveur d'authentification envoie l'élément d'authentification intermédiaire à l'application obtentrice - L'application obtentrice met à disposition de l'application client l'élément d'authentification intermédiaire. Dans un mode de réalisation où l'élément d'authentification est un mot de passe appelé « mot de passe intermédiaire », le serveur d'authentification génère également ledit mot de passe intermédiaire. Les attributs du mot de passe intermédiaire envoyés à la base de données intermédiaire comportent alors le mot de passe intermédiaire lui-même. Dans un mode de réalisation où l'élément d'authentification est un certificat électronique, appelé « certificat électronique intermédiaire », le serveur d'authentification génère le certificat électronique intermédiaire ou bien une infrastructure à clefs publiques le génère puis le communique au serveur d'authentification. Les attributs du certificat électronique intermédiaire comportent alors des informations d'identification et au moins une signature. On note que le certificat électronique intermédiaire est envoyé à l'application obtentrice dans un container standard et sécurisé, par exemple selon la norme PKCS#12. Le container comporte également une clef publique, une clef privée, et un certificat d'une autorité de certification. Dans les deux cas, l'élément d'authentification intermédiaire est généré indépendamment de l'utilisateur, du mot de passe utilisateur, et de l'application client. L'application obtentrice est authentifiée pour s'assurer que la demande d'élément d'authentification intermédiaire provient bien du terminal. De plus, l'élément d'authentification intermédiaire est vérifiable grâce au stockage des attributs sur la base de données intermédiaire. Dans un mode de réalisation, l'élément d'authentification intermédiaire est un mot de passe intermédiaire, et les attributs du mot de passe intermédiaire comportent le mot de passe intermédiaire lui-même. Avantageusement dans ce mode de réalisation, l'application obtentrice met à disposition de l'application client l'élément d'authentification intermédiaire selon les étapes suivantes : - L'application obtentrice affiche le mot de passe intermédiaire sur un écran du terminal - L'utilisateur entre ledit mot de passe intermédiaire dans une interface utilisateur de l'application client - L'application client sauvegarde ledit mot de passe intermédiaire dans une mémoire du terminal. Il s'agit d'une manière simple et rapide de fournir le mot de passe intermédiaire à l'application sans avoir à la modifier. Dans un autre mode de réalisation, l'élément d'authentification intermédiaire est un certificat électronique intermédiaire, et les attributs du certificat électronique intermédiaire comportent des informations d'identification et une signature. Avantageusement dans ce mode de réalisation, l'application obtentrice met à disposition de l'application client le certificat électronique intermédiaire selon les étapes suivantes : - L'application obtentrice extrait le certificat électronique intermédiaire d'un conteneur d'envoi - L'application obtentrice installe le certificat intermédiaire dans une base de certificats électroniques du terminal, accessible par l'application client. Comme indiqué précédemment, le container d'envoi est un container standard et sécurisé (par exemple selon la norme PKCS#12) et contient une clef publique, une clef privée, le certificat électronique intermédiaire et un certificat d'une autorité de certification. Dans un mode de réalisation, la passerelle mandataire vérifie l'élément d'authentification intermédiaire au moyen des attributs de l'élément d'authentification stockés dans la base de données intermédiaire, par interrogation de la base de données intermédiaire. Dans un mode de réalisation, l'élément d'authentification intermédiaire est supprimé de la base de données intermédiaire en fonction d'une politique de sécurité, et un nouvel élément d'authentification intermédiaire est mis à disposition de l'application client. Supprimer l'élément d'authentification intermédiaire et fournir un nouvel élément d'authentification intermédiaire revient à modifier l'élément d'authentification intermédiaire. Cela permet d'améliorer la sécurité du système. La politique de sécurité peut par exemple prévoir que l'élément d'authentification intermédiaire soit supprimé après un nombre déterminé d'échanges entre l'application client avec le serveur. On appelle échange la transmission d'une requête et d'une réponse. La politique de sécurité peut alternativement ou en supplément prévoir que l'élément d'authentification intermédiaire soit supprimé au bout d'une durée de temps déterminée. La politique de sécurité peut également prévoir que l'élément d'authentification intermédiaire soit supprimé sur requête en cas de vol ou perte du terminal utilisateur. Dans le cas particulier où les éléments d'authentification intermédiaires sont des certificats électroniques intermédiaires, la politique de sécurité peut prévoir que les certificats électroniques intermédiaires sont remplacés à intervalle déterminé par leur date de validité, ou sont répudiés par le serveur d'authentification, ou par l'infrastructure à clefs publiques, ou par la passerelle mandataire. Dans un mode de réalisation, la passerelle mandataire obtient le mot de passe utilisateur en interrogeant une base de mots de passe utilisateurs, et le serveur vérifie le mot de passe utilisateur compris dans la deuxième requête en interrogeant ladite base de mots de passe utilisateurs. La base de mots de passe utilisateurs est classiquement utilisée par le serveur pour vérifier les mots de passe utilisateur transmis dans les requêtes qu'il reçoit. La nouveauté réside dans le fait que la passerelle mandataire est adaptée pour récupérer le mot de passe utilisateur associé à l'utilisateur de l'application client. Selon un deuxième aspect, l'invention concerne un dispositif de sécurisation pour mettre en oeuvre le procédé selon le premier aspect de l'invention. Le dispositif de sécurisation sert à sécuriser un système client-serveur protégé par un mot de passe utilisateur, ledit système mettant en oeuvre un serveur et une application client installée sur un terminal utilisateur. Le dispositif comporte une passerelle mandataire comprenant : - Des moyens de réception d'une première requête provenant de l'application client, ladite première requête comprenant un élément d'authentification intermédiaire stocké par l'application client - Des moyens de vérification de l'élément d'authentification intermédiaire compris dans la première requête - Des moyens d'obtention du mot de passe utilisateur - Des moyens d'envoi, à destination du serveur, d'une deuxième requête, ladite deuxième requête comprenant le mot de passe utilisateur obtenu - Des moyens de réception d'une réponse provenant du serveur - Des moyens d'envoi de la réponse vers l'application client. Dans un mode de réalisation, le dispositif de sécurisation comporte un serveur d'authentification comprenant : - Des moyens d'envoi d'attributs de l'élément d'authentification vers une base de données intermédiaire - Des moyens d'envoi de l'élément d'authentification intermédiaire vers une application d'obtention installée sur le terminal. Dans un mode de réalisation, le dispositif de sécurisation comporte la base de données intermédiaire, qui comprend : - des moyens de réception d'attributs d'un élément d'authentification intermédiaire envoyés par le serveur d'authentification - des moyens de sauvegarde desdits attributs de l'élément d'authentification intermédiaire - des moyens de communication avec la passerelle mandataire. Dans un mode de réalisation, la passerelle mandataire comporte des moyens d'interrogation de la base de données intermédiaire. L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. BREVE DESCRIPTION DES FIGURES Les figures ne sont présentées qu'a titre indicatif et nullement limitatif de l'invention. Les figures montrent : - A la figure 1, une représentation schématique d'un dispositif de sécurisation d'un système client-serveur, selon un mode de réalisation non limitatif de l'invention, dans un contexte selon lequel le système est un système de messagerie électronique, dans un mode de réalisation dans lequel l'élément d'authentification intermédiaire est un mot de passe intermédiaire ; - A la figure 2, une représentation schématique d'un procédé de sécurisation du système client-serveur de la figure 1, selon un mode de réalisation non limitatif de l'invention dans lequel l'élément d'authentification intermédiaire est un mot de passe intermédiaire. DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION DE L'INVENTION Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. Le mode de réalisation décrit en référence aux figures concerne un système de messagerie électronique mettant en oeuvre un serveur de messagerie électronique, une application client de messagerie électronique installée sur le terminal d'un utilisateur, et un protocole de communication selon lequel le serveur et l'application client communiquent. Cependant, il est entendu que ce mode de réalisation est généralisable à tous les systèmes client-serveur mettant en oeuvre une partie cliente, un serveur, et un protocole de communication, dès lors que le serveur doit identifier l'utilisateur de la partie cliente par un mot de passe utilisateur. Comme le montre la figure 1, le système de messagerie décrit comporte : - Un serveur de messagerie 7 ayant pour vocation : - d'envoyer des messages électroniques à des applications client de messagerie ou à d'autres serveurs de messagerie, et - de recevoir des messages électroniques provenant d'applications client de messagerie ou provenant d'autres serveurs de messagerie. - Une application client de messagerie 2 installée sur un terminal 1 d'un utilisateur U. Le terminal 1 est par exemple un téléphone mobile ou une tablette tactile. Les applications client de messagerie 2 sont généralement conçues et configurées de sorte à effectuer une relève régulière des courriers électroniques reçus, toutes les minutes voire moins. Chaque requête de relève des courriers électroniques reçue par le serveur de messagerie 7 doit comporter un mot de passe utilisateur MPS, ledit mot de passe utilisateur MPS étant vérifié par le serveur 7 afin d'autoriser ou non le transfert des messages électroniques reçus vers l'application client de messagerie 2. - Une base de mots de passe utilisateurs 8 consultable par le serveur de messagerie 7, regroupant les mots de passe utilisateur MPS des utilisateurs utilisant les applications client de messagerie 2 associées au serveur de messagerie 7. A titre d'exemple, lorsque le serveur de messagerie 7 est un serveur OWA pour « Outlook Web Access » de Microsoft, le serveur de messagerie 7 identifie les utilisateurs grâce à leurs mots de passe « Active Directory » stockés dans la base de mots de passe utilisateurs 8, en utilisant les mécanismes standards Microsoft. La base de mots de passe utilisateurs 8 est classiquement une base de données ou un annuaire LDAP (« Lightweight Directory Access Protocol »). Selon un aspect de l'invention, un dispositif de sécurisation est mis en place pour améliorer la sécurité du système de messagerie. Comme le montre la figure 1, ledit dispositif comporte : - Une application d'obtention 3 installée sur le terminal 1 de l'utilisateur U pour obtenir un élément d'authentification intermédiaire E différent du mot de passe utilisateur MPS. L'application d'obtention 3 comporte ainsi des moyens d'envoi 30 d'une demande d'un élément d'authentification intermédiaire E, des moyens de réception 31 de l'élément d'authentification intermédiaire E. En outre, lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, l'application d'obtention 3 comporte des moyens d'affichage 32 dudit mot de passe intermédiaire MPI sur un écran du terminal 1. Par ailleurs, lorsque l'élément d'authentification intermédiaire E est un certificat électronique intermédiaire CXI, l'application d'obtention 3 comporte des moyens d'installation dudit certificat électronique intermédiaire CXI dans une base de certificats du terminal 1. - Un serveur d'authentification 5 pour générer ou recevoir un élément d'authentification intermédiaire E généré en externe, sur demande de l'application d'obtention 3. Le serveur d'authentification 5 comporte ainsi des moyens de réception 50 d'une demande d'élément d'authentification intermédiaire E provenant de l'application d'obtention 3, des moyens d'authentification 51 de ladite application d'obtention 3, des moyens de génération ou de réception 52 d'un élément d'authentification intermédiaire E et des moyens d'envoi 53 de l'élément d'authentification intermédiaire E à l'application d'obtention 3. De plus, le serveur d'authentification 5 comporte des moyens d'envoi 54 d'attributs ATT de l'élément d'authentification intermédiaire E vers une base de données intermédiaire 6, ceci afin de permettre une vérification de l'élément d'authentification intermédiaire E lors d'opérations de vérification. Lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, les attributs ATT comportent le mot de passe intermédiaire MPI lui-même. Lorsque l'élément d'authentification intermédiaire E est un certificat électronique intermédiaire CXI, les attributs ATT comportent notamment des informations d'identification et au moins une signature. - Une base de données intermédiaire 6 comportant des moyens de réception 60 pour recevoir les attributs AU envoyés par le serveur d'authentification 5, et des moyens de stockage 61 desdits attributs AU. La base de données intermédiaire 6 est par exemple une base de données ou un annuaire LDAP. - Une passerelle mandataire 4 comportant des moyens d'interception 40 pour intercepter des requêtes RQ1 provenant de l'application client de messagerie électronique 2, et des moyens de réception 41 de réponses auxdites requêtes provenant du serveur de messagerie électronique 7. Un exemple d'une telle passerelle mandataire 4 est décrit pour le protocole de communication HTTP/HTTPS (« HyperText Transfert Protocol ») dans le brevet US 7430600 B2. La passerelle mandataire 4 comporte également d'autres moyens dont les fonctions seront explicitées plus loin, à savoir : des moyens de vérification 42 d'un élément d'authentification intermédiaire E, des moyens d'obtention 43 d'un mot de passe utilisateur MPS, des moyens d'envoi 44 de requêtes au serveur de messagerie électronique 7, et des moyens d'envoi 45 de réponses à l'application client de messagerie électronique 2. Un procédé 90 selon un aspect de l'invention est schématiquement illustré à la figure 2. Le procédé 90 comporte les étapes suivantes : - Etape initiale 100, appelée étape d'enrôlement : l'application obtentrice 3 s'enregistre auprès du serveur d'authentification 5, par exemple par échange de clés de chiffrement ou de secrets partagés. Cet enregistrement initie une relation de confiance entre l'application obtentrice 3 et le serveur d'authentification 5. - Première étape 101: l'application obtentrice 3 envoie une demande DD d'obtention d'un élément d'authentification intermédiaire E au serveur d'authentification 5, via les moyens d'envoi 30. Le serveur d'authentification 5 réceptionne la demande DD via les moyens de réception 50. - Deuxième étape 102 : le serveur d'authentification 5 authentifie l'application obtentrice 3 via les moyens d'authentification 51. L'authentification consiste en une vérification du lien de confiance établi entre l'application obtentrice 3 et le serveur d'authentification 5. - Troisième étape 103 : si l'application obtentrice 3 est correctement authentifiée par le serveur d'authentification 5, une connexion sécurisée 11 entre l'application obtentrice 3 et le serveur d'authentification 5 est mise en place. Le serveur d'authentification 5 génère ou reçoit alors un élément d'authentification intermédiaire E via les moyens de génération ou de réception 52. Lorsque l'élément d'authentification E est un mot de passe intermédiaire MPI, le serveur d'authentification 5 génère lui-même le mot de passe intermédiaire MPI. La génération des mots de passe intermédiaires MPI est aléatoire et respecte une politique de format de mot de passe, définissant par exemple une taille et des listes de caractères à utiliser. Lorsque l'élément d'authentification E est un certificat électronique intermédiaire CXI, le certificat d'authentification 5 génère lui-même le certificat d'authentification CXI, ou bien délègue la génération à une infrastructure à clefs publique PKI interfacée avec le serveur d'authentification 5. Les certificats électroniques intermédiaires CXI ont une durée de validité courte, typiquement de 24 heures. - Quatrième étape 104: l'élément d'authentification intermédiaire E généré est envoyé à l'application obtentrice 3 via la connexion sécurisée 11, via les moyens d'envoi 53 du serveur d'authentification 5. Lorsque l'élément d'authentification intermédiaire E est un certificat électronique intermédiaire CXI, le certificat électronique intermédiaire CXI est transmis à l'application obtentrice 3 dans un containeur standard et sécurisé, par exemple selon la norme PKCS#12, avec une clef publique, une clef privée, et un certificat de l'autorité de certification. - Cinquième étape 105 : des attributs de l'élément d'authentification intermédiaire E généré sont envoyés à la base de données intermédiaire 6, via une connexion 10d, via les moyens d'envoi 54 du serveur d'authentification 5. La connexion 10d est par exemple une connexion LDAP/LDAPS (« Lightweight Directory Access Protocol ») si la base de mots de passe intermédiaires 6 est un annuaire. On note que la quatrième étape 104 et la cinquième étape 105 peuvent avoir lieu simultanément, ou la cinquième étape 105 peut avoir lieu avant la quatrième étape 104. - Sixième étape 106 : lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, il est affiché sur l'écran du terminal 1 via les moyens d'affichage 32 de l'application d'obtention 3. Lorsque l'élément d'authentification intermédiaire E est un certificat électronique intermédiaire CXI, il est installé par l'application d'obtention 3 dans la base de certificats du terminal 1, accessible par l'application client 2. On note qu'une validation manuelle de l'utilisateur U peut être nécessaire et dépend du système d'exploitation du terminal 1. En effet, le certificat électronique intermédiaire CXI doit être validé dans l'application client 2, ce qui peut être réalisé complètement automatiquement ou bien manuellement, en fonction du système d'exploitation. - Septième étape 107 : Lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, l'utilisateur U entre ledit mot de passe intermédiaire MPI dans l'interface utilisateur de l'application client de messagerie 2, par exemple en utilisant les mécanismes de copier/coller fourni par le système d'exploitation du terminal 1. Utiliser le mécanisme copier-coller permet un gain de temps et diminue les risques d'entrer un mot de passe intermédiaire erroné. De plus, puisque le mot de passe intermédiaire MPI est entré manuellement par l'utilisateur U dans l'application client de messagerie 2, l'application obtentrice 3 n'a pas besoin de communiquer avec l'application client de messagerie 2, laquelle n'a donc pas besoin d'être modifiée. - Huitième étape 108 : Lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, le mot de passe intermédiaire MPI est stocké par l'application client de messagerie 2 dans une mémoire du terminal 1. Il est transparent pour l'application client de messagerie 2 de stocker le mot de passe intermédiaire MPI ou le mot de passe utilisateur MPS, l'application client de messagerie 2 ne faisant pas de différence entre les deux mots de passe. - Neuvième étape 109: l'application client de messagerie 2 envoie une première requête RQ1 à destination du serveur de messagerie 7 pour demander les nouveaux messages électroniques reçus. La première requête RQ1 comporte l'élément d'authentification intermédiaire E. - Dixième étape 110: la passerelle mandataire 4 intercepte la première requête RQ1 via les moyens d'interception 40. Une connexion 9a est alors initiée entre l'application client de messagerie 2 et la passerelle mandataire 4. - Onzième étape 111 : la passerelle mandataire 4 analyse la première requête RQ1, en extrait l'élément d'authentification intermédiaire E, et le vérifie via les moyens de vérification 42. La vérification comprend une interrogation de la base de données intermédiaire 6, après établissement d'une connexion 10c avec la base de données intermédiaire 6, pour en extraire les attributs AU stockés. Lorsque l'élément d'authentification intermédiaire E est un mot de passe intermédiaire MPI, le mot de passe de la requête RQ1 est comparé avec le mot de passe stocké dans la base de données intermédiaire 6. Lorsque l'élément d'authentification intermédiaire E est un certificat électronique intermédiaire CXI, le certificat électronique intermédiaire CXI est vérifié en utilisant les attributs (par exemple date de validité, informations d'identification, autorité de certification, chiffrement, signature...) stockés dans la base de données intermédiaire 6. - Douzième étape 112 : si l'élément d'authentification intermédiaire E est correct, alors la passerelle mandataire 4 obtient le mot de passe utilisateur MPS via les moyens d'obtention 43 du mot de passe utilisateur. Pour cela, la passerelle mandataire 4 réalise une connexion 10a vers une interface d'accès à la base de mots de passe utilisateur 8. - Treizième étape 113 : la passerelle mandataire 4 envoie, à destination du serveur de messagerie 7, une deuxième requête R02 comprenant le mot de passe utilisateur MPS, via les moyens d'envoi 44 de requête. - Quatorzième étape 114: le serveur de messagerie 7 réceptionne la deuxième requête RQ2, l'analyse, et en extrait le mot de passe utilisateur MPS. Que l'application client de messagerie 2 ait utilisé l'élément d'authentification intermédiaire E et non le mot de passe utilisateur MPS est donc sans effet sur le serveur de messagerie 7, qui reçoit une requête comprenant le mot de passe attendu (la deuxième requête RQ2). - Quinzième étape 115 : le serveur de messagerie 7 vérifie le mot de passe utilisateur MPS par connexion 10b à la base de mots de passe utilisateurs 8. - Seizième étape 116: le serveur de messagerie 7 délivre une réponse RP comportant les nouveaux messages électroniques reçus, en utilisant la connexion 9b initiée par la passerelle mandataire 4. La passerelle mandataire 7 reçoit la réponse RP via les moyens de réception 41 de réponse. - Dix-septième étape 117: la passerelle mandataire 4 transmet la réponse RP à l'application client de messagerie 2 en utilisant la connexion 9a initiée par l'application client de messagerie 2. On note que pour obtenir à nouveau les nouveaux messages électroniques, les étapes allant de la première 101 à la huitième étape 108 n'ont pas besoin d'être renouvelées, puisque le mot de passe intermédiaire MPI est stocké dans le terminal 1. Seules les étapes allant de la neuvième 109 à la dix-septième étape 117 sont à renouveler. - Dix-huitième étape 118: en fonction d'une politique de sécurité, par exemple au bout d'un certain nombre de répétition des étapes allant de la neuvième 109 à la dix-septième étape 117, et/ou au bout d'un certain temps, le serveur d'authentification 5 ou la passerelle mandataire 4 supprime l'élément d'authentification intermédiaire E de la base de données intermédiaire 6. Ainsi, lorsque l'application client de messagerie 2 cherche à obtenir les nouveaux messages électroniques, la vérification de l'élément d'authentification intermédiaire E ayant lieu lors de la onzième étape 111 montre que l'élément d'authentification intermédiaire E est incorrect, et l'accès aux nouveaux messages électroniques reçus est empêché. Les étapes allant de la première étape 101 à la huitième étape 108 ont alors à être renouvelées. On note que dans le cas où les éléments d'authentification intermédiaires E sont des certificats électroniques, les certificats électroniques intermédiaires CXI expirent à intervalle déterminé par leur date de validité ou sont répudiés par le serveur d'authentification 5, ou par l'infrastructure à clefs publiques PKI, ou par la passerelle mandataire 4. L'utilisateur U doit alors obtenir un nouveau certificat électronique intermédiaire CXI en utilisant l'application 3. Le renouvellement du certificat électronique intermédiaire CXI peut être déclenché automatiquement en se basant sur la date de validité du certificat précédent. Grâce au procédé et au dispositif selon l'invention, les mots de passe utilisateur MPS n'ont pas besoin d'être stockés dans le terminal 1. En cas de perte ou vol du terminal 1, le mot de passe utilisateur MPS n'est donc pas compromis. De plus, le remplacement régulier de l'élément d'authentification intermédiaire E augmente la sécurité du système. On note également que le procédé et le dispositif sont transparents pour l'application client de messagerie 2 et le serveur de messagerie 7. REVENDICATIONS1. Procédé (90) de sécurisation d'un système client-serveur protégé par un mot de passe utilisateur (MPS), ledit système mettant en oeuvre un serveur (7) et une application client (2) installée sur un terminal (1) d'un utilisateur (U), le procédé (90) comportant les étapes suivantes : Une passerelle mandataire (4) réceptionne (110) une première requête (RQ1) provenant de l'application client (2), ladite première requête (RQ1) comprenant un élément d'authentification intermédiaire (E) préalablement mis à disposition de l'application client (2) La passerelle mandataire (4) vérifie (111) l'élément d'authentification intermédiaire (E) compris dans la première requête (RQ1) Si l'élément d'authentification intermédiaire (E) est correct : - la passerelle mandataire (4) obtient (112) le mot de passe utilisateur (MPS) - la passerelle mandataire (4) envoie (113), à destination du serveur (7), une deuxième requête (R02), ladite deuxième requête (R02) comprenant le mot de passe utilisateur (MPS) obtenu - la passerelle mandataire (4) réceptionne (116) une réponse (RP) provenant du serveur (7) - la passerelle mandataire (4) envoie (117) ladite réponse (RP) à l'application client (2). 2. Procédé (90) de sécurisation selon la revendication précédente, dans lequel l'élément d'authentification intermédiaire (E) est mis à disposition de l'application client (2) selon les étapes suivantes : Un serveur d'authentification (5) reçoit (101) une demande d'élément d'authentification intermédiaire (E) provenant d'une application obtentrice (3) installée sur le terminal (1)Le serveur d'authentification (5) authentifie (102) l'application obtentrice (3) Si l'application obtentrice (3) est authentifiée : - Le serveur d'authentification (5) envoie (105) des attributs (AU) de l'élément d'authentification intermédiaire (E) à une base de données intermédiaire (6) - Le serveur d'authentification (5) envoie (104) l'élément d'authentification intermédiaire (E) à l'application obtentrice (3) - L'application obtentrice (3) met à disposition de l'application client (2) l'élément d'authentification intermédiaire (E). 3. Procédé (90) de sécurisation selon la revendication précédente, dans lequel l'élément d'authentification intermédiaire (E) est un mot de passe intermédiaire (MPI), et les attributs (AU) du mot de passe intermédiaire (MPI) sont le mot de passe intermédiaire (MPI) lui-même. 4. Procédé (90) de sécurisation selon la revendication précédente, dans lequel l'application obtentrice (3) met à disposition de l'application client (2) le mot de passe intermédiaire (MPI) selon les étapes suivantes : L'application obtentrice (3) affiche (106) le mot de passe intermédiaire (MPI) sur un écran du terminal (1) L'utilisateur (U) entre (107) ledit mot de passe intermédiaire (MPI) dans une interface utilisateur de l'application client (2) L'application client (2) sauvegarde (108) ledit mot de passe intermédiaire (MPI) dans une mémoire du terminal (1). 5. Procédé (90) de sécurisation selon la revendication 2, dans lequel l'élément d'authentification intermédiaire (E) est un certificat électronique intermédiaire (CXI), et les attributs (ATT) du certificat électronique intermédiaire (CXI) comportent des informations d'identification et une signature. 6. Procédé (90) de sécurisation selon la revendication précédente, dans lequel l'application obtentrice (3) met à disposition de l'application client (2) le certificat électronique intermédiaire (CXI) selon les étapes suivantes : L'application obtentrice (3) extrait le certificat électronique intermédiaire (CXI) d'un conteneur d'envoi L'application obtentrice (3) installe le certificat intermédiaire (CXI) dans une base de certificats (12) du terminal (1) accessible par l'application client (2). 7. Procédé (90) de sécurisation selon l'une des revendications 2 à 6, dans lequel la passerelle mandataire (4) vérifie (111) l'élément d'authentification intermédiaire (E) au moyen des attributs (AU) de l'élément d'authentification (E) stockés dans la base de données intermédiaire (6), par interrogation de la base de données intermédiaire (6). 8. Procédé (90) de sécurisation selon l'une des revendications 2 à 7, dans lequel les attributs (AU) de l'élément d'authentification intermédiaire (E) sont supprimés (118) de la base de données intermédiaire (6) en fonction d'une politique de sécurité, et un nouvel élément d'authentification intermédiaire (E) est mis à disposition de l'application client (2). 9. Procédé (90) de sécurisation selon l'une des revendications précédentes, dans lequel la passerelle mandataire (4) obtient (112) le mot de passe utilisateur (MPS) en interrogeant une base de mots de passe utilisateurs (8), et le serveur (7) vérifie (115) le mot de passe utilisateur (MPS) compris dans la deuxième requête (R02) en interrogeant ladite base de mots de passe utilisateurs (8). 10. Dispositif de sécurisation pour mettre en oeuvre un procédé selon l'une des revendications 1 à 9.