FR2897489A1

FR2897489A1 - AUTHENTICATION WITH CONFIDENCE OF A USER BY A SERVER

Info

Publication number: FR2897489A1
Application number: FR0650542A
Authority: FR
Inventors: Ulrik Bergsten
Original assignee: Credit Lyonnais SA
Current assignee: LCL SA
Priority date: 2006-02-15
Filing date: 2006-02-15
Publication date: 2007-08-17
Anticipated expiration: 2026-02-15
Also published as: WO2007093721A2; FR2897489B1; WO2007093721A3

Abstract

L'invention concerne un procédé d'authentification d'un utilisateur par un serveur, accédé par le réseau Internet. Ce procédé comprend :- une première étape de reconnaissance, par l'utilisateur, du serveur, et- une seconde étape d'authentification de l'utilisateur par le serveur.Le procédé fait intervenir un mot de passe, fourni par l'utilisateur ; l'utilisateur n'est pas contraint à utiliser un dispositif particulier autre qu'un terminal de connexion au réseau.The invention relates to a method for authenticating a user by a server, accessed via the Internet. This method comprises: a first step of recognition by the user of the server and a second step of authentication of the user by the server. The method involves a password provided by the user; the user is not forced to use a particular device other than a network connection terminal.

Description

AUTHENTIFICATION EN TOUTE CONFIANCE D'UN UTILISATEUR PAR UN SERVEURAUTHENTICATION WITH CONFIDENCE OF A USER BY A SERVER

L'objet de la présente description est, d'une part, d'analyser la problématique de l'authentification d'un utilisateur par un serveur accédé via Internet et, d'autre part, de proposer une solution innovante susceptible de répondre à cette problématique. I) Le problème posé L'authentification d'un utilisateur à travers le réseau Internet n'est pas un problème nouveau et de multiples mécanismes d'authentification sont d'ores et déjà utilisés, couramment ou non, pour tenter de répondre à ce besoin. Le mécanisme le plus basique et parmi les moins sécurisés et pourtant le plus utilisé est celui où le serveur demande à l'utilisateur de s'identifier par un identifiant, ID, et à s'authentifier en fournissant en complément un mot de passe, PW. Ce mécanisme est très souvent complété par la mise en oeuvre au préalable d'une session SSL ou TLS entre le poste utilisateur et le serveur. Cette solution est censée, d'une part, permettre à l'utilisateur d'authentifier le serveur et, d'autre part, mettre en place un canal de communication sécurisé entre l'utilisateur et le serveur. De cette façon, l'utilisateur et le serveur pourront échanger en toute confiance des informations confidentielles au cours de la session, à commencer par la communication par l'utilisateur de son identifiant (ID) et de son mot de passe (PW) à titre d'authentification. Bien évidemment, la seule utilisation d'un mot de passe pour authentifier un utilisateur reste a priori une solution fragile puisque la simple compromission du mot de passe permettra à un tiers d'usurper l'identité de l'utilisateur en question. Il s'agit ainsi d'un mécanisme d'authentification à facteur simple, le mot de passe mémorisé par l'utilisateur. Il existe des mécanismes d'authentification à facteurs multiples, d'autres facteurs d'authentification venant en général en complément du mot de passe : - quelque chose que possède l'utilisateur comme par exemple une carte à puce - une caractéristique propre à l'utilisateur, concrètement un facteur biométrique, comme par exemple son empreinte digitale. Mais ces mécanismes sont presque toujours coûteux à mettre en oeuvre et peuvent s'avérer excessivement contraignants 25 pour les utilisateurs, nomades ou non. C'est pourquoi, on se limite à la recherche de solutions ne nécessitant la mise en oeuvre d'aucun matériel additionnel à celui constitué par un poste utilisateur de base (par exemple un PC sous Windows ). La solution idéale recherchée correspond au meilleur 30 compromis possible entre sécurité et ergonomie. C'est pourquoi, on écarte du champ de la présente demande la piste des certificats logiciels (sans support matériel). 20 35 II) Analyse critique de l'état de l'art On analyse ci-après les risques de compromission d'un mot de passe destiné à l'authentification sur Internet d'un utilisateur : - sur le serveur, sans aborder la question de son intégrité (supposée maîtrisée), - par essai systématique de mots de passe plausibles (attaque par dictionnaire), - sur le réseau, - sur le poste utilisateur. Le serveur doit à l'évidence pouvoir vérifier que l'utilisateur connaît le PW. La solution la plus simple consiste donc pour le serveur à se faire communiquer le PW saisi par l'utilisateur et à le comparer au PW connu du serveur. Dans ce contexte, une attaque consiste à obtenir une copie du fichier des mots de passe. Le serveur sera bien sûr protégé contre ce type d'attaque mais il est difficile de l'exclure tout à fait et c'est pourquoi une meilleure solution consiste à ne pas conserver sur le serveur le PW mais seulement des informations permettant de vérifier que l'utilisateur a bien saisi le bon PW. Pour éviter les attaques par dictionnaire, il faut : - rendre impossible des tests systématiques du mot de passe - ou au minimum rendre de tels tests impraticables. Si le seul moyen de tester un PW est de tenter un accès au serveur, il est clair qu'une première parade consiste à limiter le nombre de tentatives qu'acceptera le serveur avant de bloquer le compte utilisateur en question. Il faut faire de même concernant un même PW testé contre un trop grand nombre de comptes utilisateurs. Si en revanche, le risque existe qu'un tiers ait pu obtenir une information calculée à partir du PW et d'autres informations non protégées, alors l'attaque par dictionnaire est possible sans avoir besoin de faire intervenir le serveur. La seule solution pour faire échouer ce type d'attaque est alors d'avoir imposé un mot de passe suffisamment fort pour que l'attaque par dictionnaire ne puisse pas aboutir avant un délai suffisamment long. Mais un utilisateur ne pourra jamais mémoriser un tel mot de passe et en fait, il faut alors protéger au moins une autre information entrant dans le calcul de l'information divulguée (par exemple un aléa de force suffisante). The purpose of the present description is, firstly, to analyze the problem of authentication of a user by a server accessed via the Internet and, secondly, to propose an innovative solution that can respond to this problem. problematic. I) The problem posed Authentication of a user through the Internet is not a new problem and multiple authentication mechanisms are already used, commonly or not, to try to meet this need. . The most basic mechanism and among the least secure and yet the most used is the one where the server asks the user to identify himself by an identifier, ID, and to authenticate by providing a password, PW . This mechanism is very often supplemented by the prior implementation of an SSL or TLS session between the user station and the server. This solution is supposed, on the one hand, to allow the user to authenticate the server and, on the other hand, to set up a secure communication channel between the user and the server. In this way, the user and the server will be able to confidently exchange confidential information during the session, starting with the communication by the user of his identifier (ID) and password (PW). authentication. Of course, the only use of a password to authenticate a user remains a priori a fragile solution since the mere compromise of the password will allow a third party to impersonate the user in question. This is a simple factor authentication mechanism, the password stored by the user. There are multi-factor authentication mechanisms, other authentication factors generally complementing the password: - something that the user owns, such as a smart card - a feature unique to the user. user, specifically a biometric factor, such as its fingerprint. But these mechanisms are almost always expensive to implement and may be excessively burdensome for users, nomadic or not. Therefore, we limit ourselves to the search for solutions that do not require the implementation of any additional hardware to that constituted by a basic user station (for example a Windows PC). The ideal solution sought is the best possible compromise between security and ergonomics. Therefore, the scope of this application is removed from the software certificate track (without hardware support). II) Critical analysis of the state of the art The following analyzes the risks of compromising a password intended for the authentication on the Internet of a user: on the server, without addressing the question its integrity (supposedly mastered), - by systematic testing of plausible passwords (dictionary attack), - on the network, - on the user station. The server must obviously be able to verify that the user knows the PW. The simplest solution is therefore for the server to be communicated the PW entered by the user and to compare it to the PW known to the server. In this context, an attack is to obtain a copy of the password file. The server will of course be protected against this type of attack but it is difficult to exclude it altogether and that is why a better solution is to not keep on the server the PW but only information to verify that the user has entered the correct PW. To avoid dictionary attacks, you must: - make systematic password tests impossible - or at least make such tests impractical. If the only way to test a PW is to try to access the server, it is clear that a first parry is to limit the number of attempts that will accept the server before blocking the user account in question. The same must be done for the same tested PW against too many user accounts. If, on the other hand, the risk exists that a third party could obtain information computed from the PW and other unprotected information, then the dictionary attack is possible without having to involve the server. The only solution to defeat this type of attack is then to have imposed a password strong enough that the dictionary attack can not succeed before a sufficiently long delay. But a user can never memorize such a password and in fact, it is then necessary to protect at least one other information used in the calculation of the disclosed information (for example a randomly sufficient hazard).

Pour éviter la compromission du PW sur le réseau, une première solution consiste à utiliser un canal de communication sécurisé, dont les informations échangées sont chiffrées. D'où l'intérêt d'utiliser une session SSL qui est supportée en standard par tous les navigateurs sérieux. To avoid the compromise of PW on the network, a first solution is to use a secure communication channel, the information exchanged are encrypted. Hence the advantage of using an SSL session that is supported as standard by all serious browsers.

Mais l'utilisation du protocole SSL n'élimine pas pour autant tous les risques, notamment celui d'être en communication avec un faux site se faisant passer pour le site légitime. On analyse les faiblesses de l'authentification par ID / PW dans une session SSL : Ces faiblesses proviennent essentiellement d'une gestion trop laxiste des navigateurs du marché. La situation s'améliore petit à petit, au fur et à mesure des évolutions des principaux navigateurs du marché, à commencer par Internet Explorer de Microsoft et Firefox de la fondation Mozilla. But the use of SSL does not eliminate all risks, including the risk of being in communication with a fake site posing as the legitimate site. The weaknesses of ID / PW authentication are analyzed in an SSL session: These weaknesses come mainly from a too lax management of the browsers of the market. The situation is gradually improving as the main browsers on the market evolve, starting with Microsoft's Internet Explorer and Firefox from the Mozilla Foundation.

En fait, l'utilisateur va se baser sur les indications fournies par le navigateur utilisé pour accepter ou non de saisir son PW. Autrement dit, un navigateur constitue une "application de confiance" puisque c'est le navigateur qui met en oeuvre le protocole SSL pour le compte de l'utilisateur. In fact, the user will rely on the indications provided by the browser used to accept or not to enter his PW. In other words, a browser is a "trusted application" since it is the browser that implements the SSL protocol on behalf of the user.

Mais la vigilance de l'utilisateur peut trop facilement être trompée : -l'utilisateur ne verra pas forcément qu'il manque le cadenas qui symbolise l'existence d'une session SSL, - il ne s'aperçoit pas toujours qu'il n'est pas sur le bon site serveur, - il ne vérifie pas en général le certificat du serveur et il n'a que rarement la compétence pour savoir si un certificat est valide ou non, - le navigateur alerte en principe l'utilisateur si le certificat n'a pas été émis par une Autorité de Certification (AC) de confiance mais il ne bloque pas, l'utilisateur répondant souvent mécaniquement par la positive à la question posée de savoir s'il fait ou non confiance à cette AC, et la non-révocation du certificat est rarement vérifiée, - enfin, une AC est considérée comme étant de confiance s'il en a été ainsi déclaré au préalable, ce qu'un utilisateur a pu faire sans se douter de la portée de cette déclaration ou pire, qu'un tiers ayant eu accès au poste utilisateur a pu faire à l'insu de l'utilisateur légitime. On rappelle qu'on s'intéresse à tous types d'utilisateurs dont les particuliers et pas seulement aux utilisateurs à titre professionnel à partir de leur bureau. Les 20 particuliers sont en général administrateurs de leur poste utilisateur et ils ont par définition tous les droits d'administration sans forcément en faire un usage prudent, sans compter leurs enfants, encore moins prudents, ce qui constitue à l'évidence un facteur d'aggravation des risques. 25 Il reste enfin le risque de compromission du mot de passe sur le poste utilisateur. On peut identifier quatre volets à ce risque : - l'écoute de la saisie du PW par un keylogger ou autre spyware (espions locaux), 30 -l'interception des données des scripts échangés avec le serveur, juste avant leur chiffrement SSL, dont le PW ou une donnée dont il est possible de déduire le PW, - l'utilisation à l'insu de l'utilisateur d'une session 35 SSL après authentification réussie de l'utilisateur, 10 15 - la compromission d'une application de confiance à l'exemple du navigateur qui a pu être soit modifié pour divulguer le PW, soit substitué par un spyware. Il existe des solutions logicielles anti-spyware mais comme en matière de solutions anti-virus et de firewall - leur mise en oeuvre est laissée à la seule initiative des utilisateurs, - les logiciels en question ne sont pas toujours gratuits, - ils ne sont pas nécessairement à jour, - et ils ne sont pas toujours efficaces contre toutes les menaces qui émergent. De façon synthétique, on constate que les risques de compromission des mots de passe ne sont que rarement et 15 imparfaitement contrés par des mesures qui restent parfois à imaginer et à développer : -keylogging et autres formes de spyware sur le poste utilisateur, - phishing passif via de faux sites, 20 - phishing actif par intermédiation via de faux sites ou par emprunt de session SSL sur le poste utilisateur. But the vigilance of the user can too easily be deceived: -the user will not necessarily see that he misses the lock that symbolizes the existence of an SSL session, - he does not always see that it n is not on the good server site, - it does not generally check the server certificate and it rarely has the competence to know if a certificate is valid or not, - the browser in principle alerts the user if the certificate was not issued by a trusted Certificate Authority (CA) but it does not block, the user often responding mechanically positively to the question asked whether or not he trusts this CA, and the non-revocation of the certificate is rarely verified, - finally, a CA is considered to be trusted if it has been so declared in advance, what a user could do without suspecting the scope of this statement or worse, that a third party having had access to the post used could have done without the knowledge of the legitimate user. We recall that we are interested in all types of users including individuals and not only users in a professional capacity from their office. The 20 individuals are generally administrators of their user station and they have by definition all the rights of administration without necessarily making a prudent use, not counting their children, still less cautious, which constitutes obviously a factor of aggravation of risks. Finally, there remains the risk of compromising the password on the user station. We can identify four components to this risk: - listening to the input of the PW by a keylogger or other spyware (local spies), 30 -interception of the data exchanged scripts with the server, just before their SSL encryption, which the PW or data from which the PW can be derived, - the user's unknowing use of an SSL session after successful authentication of the user, 10 15 - the compromise of an application of trust the example of the browser that could be modified to disclose the PW, or substituted by a spyware. There are anti-spyware software solutions but as for anti-virus and firewall solutions - their implementation is left to the initiative of users, - the software in question is not always free, - they are not necessarily up to date, - and they are not always effective against all emerging threats. In summary, it can be seen that the risks of compromising passwords are only rarely and imperfectly countered by measures that sometimes remain to be imagined and developed: - keylogging and other forms of spyware on the user station, - passive phishing via fake sites, 20 - active phishing by intermediation via fake sites or by SSL session borrowing on the user station.

25 III) Solution proposée La question est de savoir comment authentifier un utilisateur par mot de passe en limitant sérieusement le risque de compromission de ce mot de passe. L'analyse montre que l'un des principaux risques est 30 que l'utilisateur finisse par divulguer librement son mot de passe entre des mains malintentionnées ayant réussi à tromper sa confiance. La question devient donc de savoir comment permettre à un utilisateur de reconnaître le serveur légitime auprès de qui 35 il pourra dès lors s'authentifier en toute confiance. 25 III) Proposed solution The question is how to authenticate a user by password by seriously limiting the risk of compromise of this password. The analysis shows that one of the main risks is that the user may end up freely disclosing his password in malicious hands that have managed to cheat his trust. The question therefore becomes how to enable a user to recognize the legitimate server from whom he can then authenticate with confidence.

La solution selon l'invention répond à ce risque principal ainsi qu'aux autres risques identifiés. Tout d'abord, il convient d'écarter la fausse bonne idée d'une reconnaissance du serveur légitime par présentation à 5 l'utilisateur d'un signe de reconnaissance convenu à l'avance (phrase ou image). Il est en effet impossible de présenter un tel signe de reconnaissance à l'utilisateur sans qu'un spyware ne puisse à cette occasion prendre connaissance de ce secret. Il faut bien 10 au moins afficher le signe de reconnaissance et il est alors au minimum possible pour un spyware de faire à ce moment-là une copie d'écran. Le secret qu'est censé être le signe de reconnaissance est dès lors compromis, sans que l'utilisateur puisse le 15 soupçonner. Lors d'un prochain accès, il devient alors possible d'utiliser le signe de reconnaissance pour se faire passer pour le serveur légitime et l'utilisateur saisira en toute confiance son PW qui se trouve alors à son tour compromis. On a déjà signalé que les navigateurs sont des 20 "applications de confiance". En fait, il semble clair que la solution passe nécessairement par l'utilisation d'une telle application de confiance. On peut choisir d'attendre que les éditeurs des navigateurs résolvent le problème de l'authentification en toute 25 confiance ou adopter une position plus volontariste : - imaginer et concevoir une application de confiance venant temporairement en renfort des navigateurs actuels - espérer que les éditeurs des navigateurs adoptent la 30 solution selon l'invention et finissent par l'intégrer directement dans les navigateurs. En attendant l'intégration des fonctions de confiance directement dans les navigateurs, la solution transitoire passe par la définition d'une extension au navigateur (bien entendu, 35 son implémentation dépendra du navigateur cible mais notre propos est ici d'en décrire les fonctions, pas l'implémentation). Selon l'invention, on fait appel à une solution voisine de la technique PwdHash développée par l'Université de Stanford. Il s'agit d'une extension qui vient renforcer le navigateur dans sa dimension de confiance relative à l'authentification des utilisateurs. On rappelle que Pwdhash est une extension qui remplace le PW saisi par l'utilisateur par le haste (fonction de hachage) du PW et du nom de domaine du serveur tel qu'observé du poste utilisateur. De ce fait, si l'utilisateur est victime d'un faux site, il ne lui divulgue pas pour autant : - ni son PW -ni même une information réutilisable par le faux site 15 vis à vis du site légitime. Cette solution a un grand mérite mais ne répond pas complètement au problème posé. En fait, cette solution reste partielle mais surtout elle est à la main de chaque utilisateur qui souhaite se protéger contre les risques de compromission de 20 son PW; la solution restant tout à fait transparente vis à vis des serveurs. Or la problématique est en réalité à peu près inverse : c'est au serveur de protéger les données privatives qu'il renferme et en cas d'ordres en ligne, c'est encore le serveur qui a besoin de vérifier que l'ordre émane bien de son 25 client. Le client appréciera d'autant plus les services rendus par le serveur que celui-ci est capable de le protéger contre ces soucis d'usurpation d'identité. Cela dit, il est évident qu'aucune sécurité n'est possible en cas de comportement non responsable des 30 utilisateurs. Mais il incombe au serveur d'expliquer à ses utilisateurs ce qui est attendu d'eux et sans leur attribuer des responsabilités hors de portée ou déraisonnables. La solution recherchée n'a nullement besoin d'être transparente vis à vis des serveurs. Mais il est néanmoins 35 souhaitable de limiter les impacts sur le serveur dont on veut renforcer la sécurité des accès; d'où l'idée d'un impact limité à la fonction d'authentification laissant inchangés les traitements à proprement parler du serveur. On retire encore de Pwdhash l'idée d'une activation explicite et volontaire de l'extension de confiance par l'utilisateur. La frappe d'une touche fonction ("F2" par exemple) signale ainsi à l'extension de confiance qu'une séquence d'authentification est demandée pour la fenêtre du navigateur qui a le focus. The solution according to the invention responds to this main risk as well as to the other risks identified. First of all, the false good idea of recognizing the legitimate server should be discarded by presenting the user with an agreed sign of recognition (sentence or image). It is indeed impossible to present such a sign of recognition to the user without a spyware can not on this occasion take knowledge of this secret. It must at least 10 show the sign of recognition and then it is at least possible for a spyware to make at that time a screenshot. The secret that is supposed to be the sign of recognition is therefore compromised, without the user being able to suspect it. At a future access, it then becomes possible to use the recognition sign to pretend to be the legitimate server and the user will confidently enter his PW which is then in turn compromised. It has already been pointed out that browsers are "trusted applications". In fact, it seems clear that the solution necessarily involves the use of such a trusted application. We can choose to wait for browser editors to solve the problem of authentication with confidence or to adopt a more voluntarist position: - to imagine and design a trusted application temporarily reinforcing current browsers - hope that the publishers The browsers adopt the solution according to the invention and end up integrating it directly into the browsers. While waiting for the integration of the trust functions directly in the browsers, the transient solution passes by the definition of an extension to the browser (of course, its implementation will depend on the target browser but our purpose here is to describe the functions, not the implementation). According to the invention, a solution similar to the PwdHash technique developed by Stanford University is used. It is an extension that reinforces the browser in its dimension of trust relative to user authentication. It is recalled that Pwdhash is an extension that replaces the PW entered by the user with the haste (hash function) of the PW and the server's domain name as observed by the user station. Therefore, if the user is a victim of a fake site, it does not disclose: - neither its PW -ni even reusable information by the fake site 15 vis-à-vis the legitimate site. This solution has great merit but does not completely address the problem. In fact, this solution remains partial but above all it is in the hands of each user who wishes to protect himself against the risks of compromise of his PW; the solution remains completely transparent with respect to the servers. But the problem is in reality almost opposite: it is the server to protect the private data it contains and in case of online orders, it is still the server that needs to verify that the order emanates good of his client. The customer will appreciate all the more services rendered by the server that it is able to protect against these concerns of identity theft. That said, it is obvious that no security is possible in case of unresponsive behavior of the 30 users. But it is up to the server to explain to its users what is expected of them and without assigning them responsibilities out of reach or unreasonable. The solution sought does not need to be transparent with respect to the servers. However, it is nevertheless desirable to limit the impacts on the server whose access security is to be enhanced; hence the idea of an impact limited to the authentication function leaving unchanged the actual processing of the server. Pwdhash still removes the idea of an explicit and voluntary activation of the extension of trust by the user. Typing a function key ("F2" for example) signals to the trust extension that an authentication sequence is requested for the browser window that has the focus.

L'extension ouvre alors une nouvelle fenêtre, "popup", dédiée au processus d'authentification en toute confiance. Un peu de redondance ne fait pas de mal en matière de sécurité et l'extension commence par demander à l'utilisateur le nom du domaine auquel il souhaite accéder. The extension then opens a new window, "popup", dedicated to the authentication process with confidence. A bit of redundancy does not hurt security and the extension starts by asking the user for the name of the domain he wants to access.

A priori, c'est une information redondante puisque l'utilisateur s'est déjà rendu sur le site auquel il entend accéder, au moyen des mécanismes de son navigateur, dont : - la saisie de l'URL, voire directement de l'adresse I P, - la sélection d'un favori, - ou encore par le click souris sur un lien. Mais ces mécanismes ne garantissent pas que l'utilisateur soit arrivé sur le site qu'il croit. La saisie du nom de domaine (par exemple celui de sa Banque en Ligne "lcl.fr") introduit une redondance qui permet des contrôles avec les données du site réellement accédé : -existence d'une session SSL, - correspondance du certificat du serveur accédé avec le nom de domaine saisi, - validité du certificat en question. L'extension de confiance effectue ces contrôles sans le laxisme habituel des navigateurs : - la liste des AC racine ne sera pas modifiable par l'utilisateur (ce sera au serveur de s'y adapter), - un certificat expiré ou révoqué ne pourra pas être admis (on ne pose même pas la question à l'utilisateur). Ce n'est qu'après ces contrôles que l'utilisateur sera 5 sollicité pour saisir son ID et son PW, ce qu'il peut alors faire en confiance dans le popup de l'extension. L'extension intègre une fonction permettant d'empêcher les keyloggers et autres spywares d'écouter la saisie, notamment du PW. Différentes solutions existent pour réaliser cette 10 fonction anti-keylogger avec néanmoins des efficacités variables selon les solutions. L'utilisateur saura par ailleurs que la saisie de son PW n'est autorisée que dans cette séquence précise : - accès au serveur réalisé 15 - frappe de la touche fonction retenue - ouverture d'un popup -saisie du nom de domaine - saisie de l'ID et du PW. A noter qu'il peut être judicieux d'afficher entre la 20 saisie de l'ID et celle du PW, un message d'accueil en provenance du serveur du type "bonjour M. Ulrik BERGSTEN, votre dernier accès date de telle heure tel jour". Cela n'est pas critique mais ne peut que contribuer à une vigilance accrue de l'utilisateur en vue de la saisie cruciale de son PW. 25 Toujours inspiré de Pwdhash, la communication avec le serveur se fait via la fenêtre initiale et donc via les scripts transmis par le serveur. Mais dans la mesure où l'interface homme - machine est localisée dans le popup de l'extension de confiance, les champs de ces scripts n'ont pas à être 30 visualisés. Ces champs sont lus par l'extension pour les informations transmises par le serveur à l'intention de l'extension de confiance et sont renseignés par l'extension de confiance pour leur communication au serveur (le "post" étant 35 également déclenché par l'extension de confiance). A priori, it is redundant information since the user has already visited the site he intends to access, using the mechanisms of his browser, including: - the entry of the URL, or directly from the address IP, - the selection of a favorite, - or by clicking on a link. But these mechanisms do not guarantee that the user has arrived on the site that he believes. The entry of the domain name (for example that of its Online Bank "lcl.fr") introduces a redundancy that allows controls with the data of the site actually accessed: -existence of an SSL session, - correspondence of the server certificate accessed with the domain name entered, - validity of the certificate in question. The trust extension carries out these checks without the usual laxity of the browsers: - the list of root CAs will not be modifiable by the user (it will be up to the server to adapt to it), - an expired or revoked certificate will not be able to be admitted (we do not even ask the question to the user). It is only after these checks that the user will be asked to enter his ID and PW, which he can then do with confidence in the popup of the extension. The extension includes a function to prevent keyloggers and other spyware to listen to input, including the PW. Various solutions exist to achieve this anti-keylogger function with nevertheless varying efficiencies depending on the solutions. The user will also know that the entry of his PW is authorized only in this precise sequence: - access to the realized server 15 - keystroke of the selected function key - opening of a popup - entry of the domain name - entry of the ID and the PW. Note that it may be wise to display between the entry of the ID and that of the PW, a greeting from the server type "Hello Mr. Ulrik BERGSTEN, your last access date such time such day". This is not critical but can only contribute to an increased vigilance of the user for the crucial input of his PW. 25 Always inspired by Pwdhash, the communication with the server is done via the initial window and thus via the scripts transmitted by the server. But since the man-machine interface is located in the popup of the trusted extension, the fields of these scripts do not have to be viewed. These fields are read by the extension for the information transmitted by the server for the trust extension and are informed by the trust extension for their communication to the server (the "post" being also triggered by the server). extension of trust).

Un spyware pourra observer ces champs et c'est pourquoi, il convient de n'échanger par ce biais que des données non secrètes. Il faut en effet rappeler que même s'il y a bien mise en oeuvre du protocole SSL, celui-ci est un protocole de niveau transport des données et non pas de niveau applicatif (le chiffrement des données échangées n'intervient qu'après leur envoi applicatif par le "post" et on a le même problème en réception). Par ailleurs, on a déjà rappelé qu'il ne faut pas 10 communiquer le PW lui-même au serveur pour limiter les possibilités d'attaques au niveau du serveur. On voit ici qu'il convient de mettre en oeuvre une authentification en zero knowledge (ou divulgation nulle ). 15 La solution SRP (version 6a) de l'Université de Stanford est particulièrement bien adaptée à cette partie de notre problème. A spyware will be able to observe these fields and that is why, it is advisable to exchange in this way only non-secret data. It must be remembered that even if the SSL protocol is well implemented, it is a data transport level protocol and not an application level (encryption of the exchanged data only occurs after application sending by the "post" and we have the same problem in reception). Moreover, it has already been pointed out that the PW itself must not be communicated to the server in order to limit the possibilities of attacks on the server. We see here that it is necessary to implement an authentication in zero knowledge (or null disclosure). The SRP solution (version 6a) from Stanford University is particularly well suited to this part of our problem.

20 25 30 Voici donc en substance la nature des échanges entre l'extension de confiance et le serveur, après confirmation qu'on est bien au contact du serveur légitime : Extension de confiance Serveur 20 25 30 So here is essentially the nature of the exchanges between the trust extension and the server, after confirming that we are in contact with the legitimate server: Server trust extension

Saisie ID Transmission ID H> Préparation message d'accueil (ID) Recherche s et v (ID) Tirage aléa b Calcul B (b, v) Affichage message d'accueil F Transmission message d'accueil + s + B Saisie PW Tirage aléa a Calcul A (a) Calcul MK1 (a, B, s, PW) Calcul AUT1 (A, B, MK1) Transmission A + AUT1 H> Calcul MK2 (A, b, s, v) Calcul AUT2 (A, B, MK2) Contrôle d'accès OK (si AUT1 == AUT2) Entry ID Transmission ID H> Preparation Greeting (ID) Search s and v (ID) Random draw b Calculation B (b, v) Greeting message F Greeting message + s + B PW entry Random draw a Calculation A (a) Calculation MK1 (a, B, s, PW) Calculation AUT1 (A, B, MK1) Transmission A + AUT1 H> Calculation MK2 (A, b, s, v) Calculation AUT2 (A, B, MK2) Access control OK (if AUT1 == AUT2)

25 Quelques explications :25 Some explanations:

- v est le vérificateur connu du serveur et correspondant au PW de l'utilisateur identifié par ID, 30 - s est un sel choisi lors du calcul de v à partir du PW, c'est-à-dire un nombre choisi à l'initialisation du compte, - A est calculé à partir de a de telle façon que la connaissance de A ne permette pas de retrouver a, 15 20 - B est calculé à partir de b mais aussi à partir de A et de v, toujours de telle façon que la connaissance de B ne permette pas de retrouver b (ni v), - MK est une clé calculée de deux façons différentes, d'une part du côté de l'extension de confiance MK1 et d'autre part du côté serveur MK2 ; si le PW utilisé par l'extension de confiance correspond bien au vérificateur v utilisé côté serveur alors MK1 == MK2, - AUT est l'authentifiant permettant au serveur de reconnaître l'utilisateur ; il est calculé des deux côtés à partir respectivement de MK1 et de MK2 et si MK1 == MK2 alors AUT1 == AUT2. v is the known checker of the server and corresponding to the PW of the user identified by ID, 30 - s is a salt chosen when calculating v from the PW, that is to say a number chosen at initialization of the count, - A is calculated from a in such a way that the knowledge of A does not make it possible to find a, 20 - B is calculated from b but also from A and v, always from such way that the knowledge of B does not allow to find b (nor v), - MK is a key calculated in two different ways, on the one hand on the side of the MK1 trust extension and on the other hand on the MK2 server side ; if the PW used by the trust extension corresponds to the verifier v used on the server side then MK1 == MK2, - AUT is the authenticator allowing the server to recognize the user; it is calculated on both sides from respectively MK1 and MK2 and if MK1 == MK2 then AUT1 == AUT2.

Pour plus de détails, on peut consulter le site 15 "srp.stanford.edu". For more details, visit the site "srp.stanford.edu".

Les informations échangées sont en définitive les suivantes : The information exchanged is ultimately the following:

20 - ID - Message d'accueil + s + B - A + AUT1. 20 - ID - Greeting + s + B - A + AUT1.

L'interception possible de ces données ne révèle rien 25 de véritablement secret, ne permet pas de déduire les secrets à proprement parler (a, b, v , MK ou PW) et ne sont pas réutilisables pour un nouvel accès au serveur. Une fois que le serveur a reconnu l'utilisateur de cette façon, il n'a plus qu'à ouvrir l'accès à l'utilisateur via 30 la fenêtre initiale (l'envoi de ces données permet à l'extension de confiance de constater que son rôle est terminé et elle pourra fermer le popup). 10 35 IV) Extensions envisageables La solution de base peut faire l'objet d'extensions et en particuliers les suivantes : - empêcher l'emprunt par un parasite d'une session valablement ouverte, - valider des transactions en ligne, -renforcer l'authentification par un second facteur d'ordre biométrique. Extension pour résister aux parasites The possible interception of these data reveals nothing really secret, does not allow to deduce the secrets strictly speaking (a, b, v, MK or PW) and are not reusable for a new access to the server. Once the server has recognized the user in this way, it only has to open the access to the user via the initial window (sending this data allows the trust extension of find that her role is over and she can close the popup). 10 35 IV) Possible extensions The basic solution can be extended and in particular the following: - prevent the borrowing by a parasite from a validly open session, - validate transactions online, - strengthen the authentication by a second biometric order factor. Extension to resist pests

Une fois que le serveur a reconnu l'utilisateur, il suffit, dans cette variante, de continuer à s'appuyer sur 15 l'extension de confiance jusqu'à la fermeture de l'accès au serveur. L'extension de confiance intercepte chaque post émanant de la fenêtre ayant fait l'objet de l'authentification pour ajouter aux données transmises un sceau. 20 Ce sceau pourrait typiquement être le hash de MK1 et du hash des données applicatives, l'extension de confiance ayant gardé en mémoire la valeur de MK1. Le serveur sait si le sceau est exigé ou non; cela peut d'ailleurs être son choix, soit pour l'ensemble des 25 requêtes en provenance de l'utilisateur soit pour celles où il l'aura demandé. Le serveur aura également gardé en mémoire la valeur de MK2 de façon à pouvoir vérifier le cas échéant la présence effective d'un sceau et sa validité. De cette façon, un éventuel parasite greffé au 30 navigateur ne pourra pas emprunter la session ouverte pour accéder en parallèle au serveur au nom de l'utilisateur mais à son insu. 10 35 Extension pour valider des transactions en ligne Once the server has recognized the user, it is sufficient, in this variant, to continue to rely on the extension of trust until the closure of access to the server. The trust extension intercepts each post emanating from the window that has been authenticated to add a seal to the transmitted data. This seal could typically be the hash of MK1 and the application data hash, the trust extension having kept in memory the value of MK1. The server knows if the seal is required or not; this can also be his choice, either for all 25 requests from the user or for those where he has requested. The server will also have kept in memory the value of MK2 so that it can check if necessary the actual presence of a seal and its validity. In this way, any parasite grafted to the browser will not be able to borrow the open session to access the server in parallel in the name of the user but without his knowledge. 10 35 Extension to validate online transactions

Le serveur souhaite que l'utilisateur valide formellement une transaction en saisissant une nouvelle fois son PW au vu des données de la transaction ; celle-ci étant faite en ligne à travers une session valablement ouverte. Pour cela le serveur envoie le texte reprenant les données de la transaction à valider avec un indicateur de demande de validation destiné à l'extension de confiance. The server wants the user to formally validate a transaction by re-entering his PW based on the transaction data; this being done online through a validly open session. For this purpose, the server sends the text containing the data of the transaction to be validated with a validation request flag for the extension of trust.

Au vu de cet indicateur, l'extension de confiance ouvre à nouveau un popup mais il n'est pas utile de recommencer tout le processus d'authentification. L'extension de confiance affiche dans le popup le texte des données de la transaction à valider et demande à l'utilisateur de valider la transaction en saisissant de nouveau son PW. L'extension de confiance a gardé en mémoire les données ayant servi lors du processus d'authentification et en particulier les valeurs de ID, de s et de MK1 mais pas le PW trop sensible. Cela lui permet de calculer le vérificateur auquel correspond le couple ID / PW (à partir de ID, de s et de PW). A partir de là, l'extension de confiance calcule SE1 comme étant le hash de v, de MK1 et du hash du texte des données de la transaction à valider. La donnée SE1 est alors retournée au serveur. Le serveur calcule de façon indépendante SE2 de la même façon. La transaction sera considérée comme validée si SE1 SE2. Cela démontre en effet sans risque de divulgation de 30 secrets que : - le texte validé est le même que le texte à valider, le PW saisi est le bon. A noter qu'il est important de faire intervenir v car sinon le serveur ne pourrait pas vérifier que le PW nouvellement saisi est le bon. A noter aussi que c'est l'utilisation de MK1 qui empêche la divulgation de secrets (PW ou v). Extension avec authentification à deux facteurs En dépit de toutes les précautions prises, on ne peut jamais tout à fait exclure la compromission du PW, en particulier par compromission de l'extension de confiance ou tout simplement par négligence de l'utilisateur. Le PW constitue un premier facteur d'authentification 10 et l'idée de cette variante est d'y adjoindre un second facteur d'authentification. Nous avons énoncé que nous cherchons des solutions d'authentification qui ne nécessitent l'utilisation d'aucun matériel additionnel au poste utilisateur de base. 15 Il n'est donc pas possible d'utiliser comme second facteur "quelque chose que possède l'utilisateur" puisqu'il s'agirait justement de quelque chose de matériel comme par exemple une carte à puce + lecteur ou une clé USB ou une "calculette" capable de générer des mots de passe dynamiques ou 20 des réponses à challenge. On songe donc à utiliser une caractéristique propre à l'utilisateur , donc un facteur biométrique. Mais pour pouvoir capter cette caractéristique, il faut en général un périphérique adapté à cet effet, ce qu'on a 25 exclu du champ de la présente solution. Pourtant il reste bien une caractéristique propre à chaque utilisateur et qui ne nécessite aucun périphérique autre que ceux dont est doté tout poste utilisateur : la façon de saisir un texte sur un clavier d'ordinateur. 30 L'idée est ainsi dans cette variante de compléter l'authentification par PW par un procédé biométrique de cette nature et pourquoi pas par le procédé "Psylock" développé par IBI, Institute for Bank Innovation, et par l'Université de Regensburg, également en Allemagne. Given this indicator, the trust extension opens a popup again but it is not necessary to restart the entire authentication process. The trust extension displays in the popup the text of the data of the transaction to be validated and asks the user to validate the transaction by re-entering his PW. The trust extension has kept in memory the data used during the authentication process and in particular the values of ID, s and MK1 but not the too sensitive PW. This allows him to calculate the verifier to which the ID / PW pair corresponds (from ID, s and PW). From there, the trust extension calculates SE1 as the hash of v, of MK1 and the hash of the data text of the transaction to be validated. The data SE1 is then returned to the server. The server independently calculates SE2 in the same way. The transaction will be considered valid if SE1 SE2. This indeed shows without risk of disclosure of 30 secrets that: - the validated text is the same as the text to be validated, the entered PW is the correct one. Note that it is important to involve v because otherwise the server could not verify that the newly entered PW is the correct one. Also note that it is the use of MK1 that prevents the disclosure of secrets (PW or v). Extension with Two-Factor Authentication Despite all the precautions taken, one can never quite exclude the compromise of the PW, especially by compromising the extension of trust or simply by negligence of the user. The PW constitutes a first authentication factor 10 and the idea of this variant is to add a second authentication factor. We have stated that we are looking for authentication solutions that do not require the use of any additional hardware at the base user station. 15 It is therefore not possible to use as a second factor "something that the user possesses" since it would be just something material such as for example a smart card + reader or a USB key or a device. "calculator" capable of generating dynamic passwords or challenge responses. So we think about using a characteristic of the user, so a biometric factor. But in order to be able to capture this characteristic, it is generally necessary to have a device adapted for this purpose, which has been excluded from the scope of the present solution. Yet it remains a characteristic of each user that does not require any device other than those that is endowed any user station: how to enter text on a computer keyboard. The idea is thus in this variant to complete the authentication by PW by a biometric method of this nature and why not by the "Psylock" method developed by IBI, the Institute for Bank Innovation, and by the University of Regensburg, also in Germany.

On rappelle que ce procédé suppose que l'utilisateur se soit enregistré au préalable en saisissant typiquement une page et demi de texte, de façon à déterminer son profil de frappe clavier. Ce profil serait évidemment conservé par le serveur avec les autres données d'authentification (ou sur un serveur dédié à cet effet). Lors d'une authentification, l'utilisateur est appelé à saisir un texte plus court, de l'ordre d'une ou de deux lignes de textes, ce qui suffit alors à déterminer si on est ou non en présence de l'utilisateur enregistré. L'intérêt de ce procédé est que sa mise en oeuvre ne risque pas de divulguer de secrets et si on a choisi un texte variable, on peut aussi empêcher la réutilisation des données issues d'une authentification réussie. It is recalled that this method assumes that the user has registered beforehand by typing typically a page and a half of text, so as to determine his keypad typing profile. This profile would obviously be kept by the server with the other authentication data (or on a dedicated server for this purpose). During an authentication, the user is required to enter a shorter text, of the order of one or two lines of text, which is then sufficient to determine whether or not the registered user is present. . The advantage of this method is that its implementation is not likely to disclose secrets and if we chose a variable text, we can also prevent the reuse of data from a successful authentication.

En revanche, la fiabilité n'est peut-être pas suffisante pour authentifier un utilisateur au moyen de ce seul facteur biométrique. D'où la complémentarité toute naturelle, d'une part, avec la solution de base relative à l'authentification de l'utilisateur et, d'autre part, avec l'extension relative à la validation de transactions en ligne. Le recours à ce second facteur d'authentification pourra être soit systématique soit modulé selon une certaine fréquence ou selon l'enjeu. Ainsi, l'invention concerne un procédé d'authentification d'un utilisateur par un serveur, accédé par un réseau informatique, notamment le réseau Internet ; ce procédé comprend : - une première étape de reconnaissance, par l'utilisateur, du serveur désiré, et une seconde étape d'authentification de l'utilisateur par le serveur, le procédé, qui fait intervenir un mot de passe fourni par l'utilisateur, étant tel que l'utilisateur ne soit pas contraint à utiliser un dispositif particulier autre qu'un terminal de connexion au réseau informatique, • la première étape comportant : -l'accès au serveur par une adresse URL selon le protocole HTTPS avec établissement d'une session SSL ou TLS, - l'émission par le serveur d'une requête demandant à l'utilisateur de s'authentifier, - l'activation par l'utilisateur, après réception de cette requête, d'une application de confiance constituant une extension de son navigateur, - l'affichage, par l'application de confiance, d'une fenêtre destinée à gérer le processus d'authentification, - la demande à l'utilisateur, par l'application de confiance via la fenêtre, de saisir le nom de domaine du serveur auquel il désire se connecter, - les contrôles effectués par l'application de 15 confiance sont les suivants : - existence d'une session SSL ou TLS avec le serveur, - correspondance du certificat du serveur accédé avec le nom de domaine saisi, 20 - validité du certificat, le certificat n'étant considéré comme valide que s'il a été émis par une autorité de certification reconnue et que s'il est ni expiré, ni révoqué, de sorte que l'utilisateur a pu vérifier qu'il est connecté au serveur souhaité, 25 • la seconde étape du procédé comportant : - la demande, par l'application, de la saisie par l'utilisateur de son identifiant auprès du serveur, - la saisie du mot de passe par l'utilisateur, cette 30 saisie étant de préférence protégée contre l'espionnage local, l'application de confiance étant telle qu'elle ne communique directement le mot de passe ni au navigateur, ni au serveur, l'application de confiance et le serveurmettant en 35 oeuvre une authentification à divulgation nulle telle, d'une part, qu'un secret dynamique est partagé entre l'application de confiance et le serveur et que, d'autre part, l'authentification de l'utilisateur par le serveur est réalisée au moyen de ce secret partagé ; de sorte que l'authentification de l'utilisateur par le serveur est réalisée en minimisant les risques de compromission du mot de passe de l'utilisateur. Dans une réalisation, entre la saisie de l'identifiant et la saisie du mot de passe, un message d'accueil est fourni par le serveur contenant une information non publique liée à la relation entre l'utilisateur et le serveur, de sorte à confirmer à l'utilisateur qu'il est en relation avec le serveur désiré. Dans une réalisation pour laquelle pour se prémunir contre une usurpation de session préalablement ouverte et pour laquelle session, l'utilisateur s'est préalablement authentifié, le procédé fait appel au secret partagé entre l'application de confiance et le serveur pour calculer et ajouter un sceau aux données transmises par le navigateur vers le serveur, le serveur rejetant les données dépourvues de sceau ou avec un sceau incorrect. Dans une réalisation, pour valider une transaction au cours d'une session préalablement ouverte : - le serveur présente les données de la transaction à l'utilisateur via l'application de confiance, - l'application de confiance recueille le consentement de l'utilisateur en lui demandant de saisir de nouveau son mot de passe, ce dernier étant de préférence protégé contre l'espionnage local de saisie, -l'application de confiance transmet un sceau calculé 30 à partir des données de la transaction, du mot de passe nouvellement saisi et du secret partagé, le serveur vérifiant le sceau de façon à rejeter la transaction en l'absence de sceau ou avec un sceau incorrect. Dans une réalisation, on renforce l'authentification 35 par mot de passe, par une authentification avec un second 5 facteur de type biométrique, ce second facteur d'authentification consistant à reconnaître l'utilisateur par son comportement lors de la saisie d'un texte communiqué par le serveur via l'application de confiance, de sorte que la seconde authentification n'exige pas de périphérique additionnel à connecter au poste de l'utilisateur. 10 On the other hand, reliability may not be sufficient to authenticate a user with this single biometric factor. Hence the natural complementarity, on the one hand, with the basic solution relating to the authentication of the user and, on the other hand, with the extension relating to the validation of online transactions. The recourse to this second authentication factor can be either systematic or modulated according to a certain frequency or according to the stake. Thus, the invention relates to a method of authentication of a user by a server, accessed by a computer network, including the Internet; this method comprises: a first step of recognition, by the user, of the desired server, and a second step of authentication of the user by the server, the method, which involves a password provided by the user , being such that the user is not forced to use a particular device other than a computer network connection terminal, • the first step comprising: -access to the server by a URL address according to the HTTPS protocol with establishment of an SSL or TLS session, the issuance by the server of a request asking the user to authenticate, the activation by the user, after receiving this request, of a trusted application constituting an extension of its browser, - the display, by the trusted application, of a window intended to manage the authentication process, - the request to the user, by the trusted application via the window, of enter the name domain of the server to which it wishes to connect, the checks carried out by the trusted application are as follows: existence of an SSL or TLS session with the server, correspondence of the certificate of the server accessed with the domain name entered, 20 - validity of the certificate, the certificate being considered valid only if issued by a recognized certification authority and if it is neither expired nor revoked, so that the user could verify that it is connected to the desired server, • the second step of the method comprising: - the request, by the application, the entry by the user of his identifier with the server, - the password entry by the user. the user, this input being preferably protected against local spying, the trusted application being such that it does not directly communicate the password to the browser or the server, the trusted application and the server 35 oe a zero-disclosure authentication, on the one hand, that a dynamic secret is shared between the trusted application and the server and that, on the other hand, the authentication of the user by the server is performed at the server. way of this shared secret; so that the authentication of the user by the server is performed minimizing the risk of compromising the password of the user. In one embodiment, between the entry of the identifier and the entry of the password, a greeting is provided by the server containing non-public information related to the relationship between the user and the server, so as to confirm to the user that he is in relation with the desired server. In an embodiment for which, in order to guard against a session spoofing previously opened and for which session, the user has previously authenticated himself, the method uses the shared secret between the trusted application and the server to calculate and add a seal to the data transmitted by the browser to the server, the server rejecting data without a seal or with an incorrect seal. In one embodiment, to validate a transaction during a previously open session: - the server presents the transaction data to the user via the trusted application, - the trusted application collects the user's consent by asking him to enter his password again, the latter being preferably protected against local seizure, the trust application transmits a seal calculated from the transaction data, the password newly seized and the shared secret, the server checking the seal so as to reject the transaction in the absence of seal or with an incorrect seal. In one embodiment, password authentication is enhanced by authentication with a second biometric factor, the second authentication factor of recognizing the user by his or her behavior when entering a text. communicated by the server via the trusted application, so that the second authentication does not require additional device to connect to the user's computer. 10

Claims

1. A method of authenticating a user by a server, accessed by a computer network, in particular the Internet, this method comprising: a first step of recognition, by the user, of the desired server, and a second step; of user authentication by the server, the method, which involves a password provided by the user, being such that the user is not forced to use a particular device other than a connection terminal to the computer network, • the first step comprising: - access to the server by a URL address according to the HTTPS protocol with establishment of an SSL or TLS session, - the transmission by the server of a request requesting the user to authenticate, - the activation by the user, after receiving this request, a trusted application constituting an extension of his browser, - the display, by the trusted application, a window of managed to manage the authentication process, - the request to the user, by the trust application via the window, to enter the domain name of the server 25 to which he wishes to connect, - the checks carried out by the application are the following: - existence of a session SSL or TLS with the server, 30 - correspondence of the certificate of the server accessed with the domain name entered, - validity of the certificate, the certificate being considered valid only it has been issued by a recognized certification authority and if it has not been expired or revoked, so that the user has been able to verify that it is connected to the desired server, • the second stage of the process comprising: - the request, by the application, the entry by the user of his identifier from the server, - the input of the password by the user, this entry being preferably protected against local espionage, the application of trust being tell e it does not directly communicate the password to the browser or the server, the trusted application and the server implementing a zero-disclosure authentication such, on the one hand, a dynamic secret is shared between the trusted application and the server and that, on the other hand, the authentication of the user by the server is performed by means of this shared secret; so that the authentication of the user by the server is achieved by minimizing the risks of compromising the password of the user.

2. Method according to claim 1, wherein, between the entry of the identifier and the entry of the password, a greeting is provided by the server containing non-public information related to the relationship between the user and the user. the server, so as to confirm to the user that he is in relation with the desired server.

3. Method according to claim 1 or 2 wherein, to guard against a session spoofing previously opened and for which the user has previously authenticated, the method uses the shared secret between the trust application and the server to calculate and add a seal to the data transmitted by the browser to the server, the server rejecting data without a seal or with an incorrect seal.

4. Method according to any one of claims 1 to 3, in which to validate a transaction during a previously open session: the server presents the transaction data to the user via the trusted application; the trusted application collects the consent of the user by asking him to re-enter his password, the latter being preferably protected against local seizure, 10 - the trusted application transmits a seal calculated to from the transaction data, the newly entered password and the shared secret, the server checking the seal so as to reject the transaction in the absence of a seal or with an incorrect seal. 15

5. Method according to one of the preceding claims wherein the password authentication is reinforced by an authentication with a second biometric type factor, the second authentication factor of recognizing the user by his behavior when entering a text communicated by the server via the trusted application, so that the second authentication does not require additional device to connect to the user's computer. 25