FR2897489A1 - Authentification en toute confiance d'un utilisateur par un serveur - Google Patents
Authentification en toute confiance d'un utilisateur par un serveur Download PDFInfo
- Publication number
- FR2897489A1 FR2897489A1 FR0650542A FR0650542A FR2897489A1 FR 2897489 A1 FR2897489 A1 FR 2897489A1 FR 0650542 A FR0650542 A FR 0650542A FR 0650542 A FR0650542 A FR 0650542A FR 2897489 A1 FR2897489 A1 FR 2897489A1
- Authority
- FR
- France
- Prior art keywords
- user
- server
- authentication
- password
- seal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 27
- 230000008569 process Effects 0.000 claims description 6
- 230000004913 activation Effects 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 claims description 3
- 239000000243 solution Substances 0.000 description 25
- 230000006870 function Effects 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- AMAOXEGBJHLCSF-CQSZACIVSA-N (5r)-5-ethyl-3-[6-(3-methoxy-4-methylphenoxy)pyridin-3-yl]imidazolidine-2,4-dione Chemical compound O=C1[C@@H](CC)NC(=O)N1C(C=N1)=CC=C1OC1=CC=C(C)C(OC)=C1 AMAOXEGBJHLCSF-CQSZACIVSA-N 0.000 description 5
- 101100057204 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) ATG3 gene Proteins 0.000 description 5
- 238000012360 testing method Methods 0.000 description 4
- 101150034092 ATG4 gene Proteins 0.000 description 3
- 238000013515 script Methods 0.000 description 3
- 230000009897 systematic effect Effects 0.000 description 3
- 239000003637 basic solution Substances 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 244000045947 parasite Species 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 241000607479 Yersinia pestis Species 0.000 description 1
- 230000002155 anti-virotic effect Effects 0.000 description 1
- 239000002585 base Substances 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003014 reinforcing effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 150000003839 salts Chemical class 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000002747 voluntary effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Storage Device Security (AREA)
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.
Description
AUTHENTIFICATION EN TOUTE CONFIANCE D'UN UTILISATEUR PAR UN SERVEUR
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).
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.
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.
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.
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.
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.
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.
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.
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).
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.
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
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)
25 Quelques explications :
- 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.
Pour plus de détails, on peut consulter le site 15 "srp.stanford.edu".
Les informations échangées sont en définitive les suivantes :
20 - ID - Message d'accueil + 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
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
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.
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.
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.
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
Claims (5)
1. 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é comprenant : - une première étape de reconnaissance, par 5 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 10 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 15 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 20 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 25 auquel il désire se connecter, - les contrôles effectués par l'application de confiance sont les suivants : - existence d'une session SSL ou TLS avec le serveur, 30 - correspondance du certificat du serveur accédé avec le nom de domaine saisi, - 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é, • 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 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 serveur mettant en 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 20 compromission du mot de passe de l'utilisateur.
2. Procédé selon la revendication 1 dans lequel, 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 25 et le serveur, de sorte à confirmer à l'utilisateur qu'il est en relation avec le serveur désiré.
3. Procédé selon la revendication 1 ou 2 dans lequel, pour se prémunir contre une usurpation de session préalablement ouverte et pour laquelle l'utilisateur s'est préalablement 30 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.
4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel pour valider une transaction au cours d'une session préalablement ouverte : - le serveur présente les données de la transaction à 5 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, 10 - l'application de confiance transmet un sceau calculé à 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. 15
5. Procédé selon l'une des revendications précédentes dans lequel on renforce l'authentification par mot de passe, par une authentification avec un second 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 20 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. 25
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0650542A FR2897489B1 (fr) | 2006-02-15 | 2006-02-15 | Authentification en toute confiance d'un utilisateur par un serveur |
| PCT/FR2007/050722 WO2007093721A2 (fr) | 2006-02-15 | 2007-01-31 | Authentification en toute confiance d'un utilisateur par un serveur |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0650542A FR2897489B1 (fr) | 2006-02-15 | 2006-02-15 | Authentification en toute confiance d'un utilisateur par un serveur |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2897489A1 true FR2897489A1 (fr) | 2007-08-17 |
| FR2897489B1 FR2897489B1 (fr) | 2008-04-25 |
Family
ID=37188627
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0650542A Active FR2897489B1 (fr) | 2006-02-15 | 2006-02-15 | Authentification en toute confiance d'un utilisateur par un serveur |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2897489B1 (fr) |
| WO (1) | WO2007093721A2 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050015594A1 (en) * | 2003-07-17 | 2005-01-20 | International Business Machines Corporation | Method and system for stepping up to certificate-based authentication without breaking an existing SSL session |
| WO2006014358A1 (fr) * | 2004-07-02 | 2006-02-09 | Rsa Security, Inc. | Module de protection de mot de passe |
-
2006
- 2006-02-15 FR FR0650542A patent/FR2897489B1/fr active Active
-
2007
- 2007-01-31 WO PCT/FR2007/050722 patent/WO2007093721A2/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050015594A1 (en) * | 2003-07-17 | 2005-01-20 | International Business Machines Corporation | Method and system for stepping up to certificate-based authentication without breaking an existing SSL session |
| WO2006014358A1 (fr) * | 2004-07-02 | 2006-02-09 | Rsa Security, Inc. | Module de protection de mot de passe |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2007093721A2 (fr) | 2007-08-23 |
| FR2897489B1 (fr) | 2008-04-25 |
| WO2007093721A3 (fr) | 2007-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20200404019A1 (en) | Mutual authentication security system with detection and mitigation of active man-in-the-middle browser attacks, phishing, and malware and other security improvements | |
| US7346775B2 (en) | System and method for authentication of users and web sites | |
| EP2567502A2 (fr) | Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service | |
| US20050210270A1 (en) | Method for authenticating a user profile for providing user access to restricted information based upon biometric confirmation | |
| Khan et al. | Comparative study of authentication techniques | |
| EP2614458B1 (fr) | Procede d'authentification pour l'acces a un site web | |
| KR20080033541A (ko) | 확장된 일회용 암호 방법 및 장치 | |
| Ghazizadeh et al. | Trusted computing strengthens cloud authentication | |
| WO2015007958A1 (fr) | Procéde d'authentification forte | |
| US20090177892A1 (en) | Proximity authentication | |
| EP3923542A1 (fr) | Dispositif informatique et procédé pour l'authentification d'un utilisateur | |
| Watters et al. | This would work perfectly if it weren’t for all the humans: Two factor authentication in late modern societies | |
| Ng | Contemporary Identity and Access Management Architectures: Emerging Research and Opportunities: Emerging Research and Opportunities | |
| US20090271629A1 (en) | Wireless pairing ceremony | |
| Popescu et al. | An hybrid text-image based authentication for cloud services | |
| Manjula et al. | Pre-authorization and post-authorization techniques for detecting and preventing the session hijacking | |
| GB2449240A (en) | Conducting secure online transactions using CAPTCHA | |
| Madhuravani et al. | A comprehensive study on different authentication factors | |
| FR2897489A1 (fr) | Authentification en toute confiance d'un utilisateur par un serveur | |
| Iliyev et al. | Website forgery prevention | |
| Richardson et al. | WebID+ biometrics with permuted disposable features | |
| Jenkinson et al. | I bought a new security token and all I got was this lousy phish—Relay attacks on visual code authentication schemes | |
| Vila et al. | An Analysis of n-factor Authentication in e-Banking Environments. | |
| Rajan et al. | Electronic and Remote Voting Systems: Solutions to Existing Problems–An Experimental Approach to Secure Voting Platforms on Endpoints | |
| da Paula Manteigueiro | Authentication and Identity Management for the EPOS Project |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |