FR3096479A1 - Procédé de vérification qu’un utilisateur d’un site web est un être humain, et plateforme de vérification associée - Google Patents

Abstract

P rocédé de vérification qu’un utilisateur d’un site web est un être humain, et plateforme de vérification associée L’invention concerne un procédé de vérification qu’un utilisateur (U) d’un site web hébergé par un serveur (130) est un être humain, ledit procédé comprenant les étapes suivantes, mises en œuvre par une plateforme (110) de vérification : - authentification de l’utilisateur (U) et, si l’authentification est réussie, envoi de données permettant une obtention, par un terminal (120) de l’utilisateur (U), d’un premier code de sécurité, puis, suite à un accès de l’utilisateur audit site web au moyen du terminal (120) : - réception d’un deuxième code de sécurité, suite à un envoi dudit deuxième code de sécurité par le terminal (120), - détermination de la validité du deuxième code de sécurité, le deuxième code étant valide si ledit deuxième code correspond au premier code, et - si le deuxième code de sécurité est valide, envoi d’une confirmation que l’utilisateur (U) est un être humain audit serveur (130) hébergeant le site web. Figure pour l’abrégé : Fig. 1.

Description

Description Titre de l'invention : Procédé de vérification qu'un utilisateur d'un site web est un être humain, et plateforme de vérification associée Domaine technique

[0001] La présente invention se rapporte au domaine général de la sécurité sur les réseaux informatiques, et concerne plus particulièrement un procédé de vérification qu'un utilisateur d'un site web hébergé par un serveur est un être humain.

Technique antérieure

[0002] Afin de contrôler l'accès à certains services web, des tests CAPTCHA (pour « Completely Automated Public Turing test to tell Computers and Humans Apte », en terminologie anglo-saxonne) peuvent être utilisés.

[0003] Un test CAPTCHA est un test de défi-réponse utilisé en informatique pour vérifier que l'utilisateur n'est pas un ordinateur potentiellement malveillant.

Ce test peut être basé sur la capacité d'analyse d'images ou de sons de l'être humain, ou sur des comportements humains.

[0004] Des exemples connus de test CAPTCHA comprennent l'affichage d'une image déformée comprenant une séquence de caractères tels que des lettres et/ou des chiffres, ou l'émission d'un message audio comprenant une telle séquence, l'utilisateur devant alors saisir la séquence dans une fenêtre réservée à cet effet.

[0005] Un autre exemple connu comprend l'affichage d'une image comprenant une question mathématique, l'utilisateur devant alors saisir la réponse à la question dans une fenêtre réservée à cet effet.

[0006] D'autres tests comprennent l'affichage d'une pluralité d'images dont certaines re- présentent un même élément, l'utilisateur devant alors sélectionner les images représentant ce même élément.

[0007] Les tests CAPTCHA permettent par exemple d'éviter qu'un serveur hébergeur de sites web soit victime d'une attaque informatique ayant pour but de rendre un service indisponible, telle qu'une attaque par inondation de requêtes.

[0008] Cependant, l'efficacité des tests CAPTCHA est limitée.

En effet, de tels tests peuvent maintenant être contournés par des algorithmes d'analyse d'images ou de sons, comme par exemple des programmes de reconnaissance optique de caractères, qui peuvent ainsi se faire passer pour des êtres humains.

[0009] D'autres algorithmes utilisent des attaques telles que l'attaque dite « par force brute » qui consiste à tester, une à une, toutes les combinaisons possibles de caractères, ou encore l'attaque dite « par dictionnaire » qui consiste à tester une série de textes potentiels, les uns à la suite des autres, en espérant que la suite de caractère attendue soit 2 contenue dans cette série.

De telles attaques peuvent par ailleurs être facilitées par les algorithmes d'analyse d'images ou de sons.

[0010] En outre, la complexité de certains tests pénalise les utilisateurs ceux-ci étant parfois contraints de soumettre plusieurs réponses avant de réussir le test, par exemple lorsque l'image est trop déformée de sorte que la séquence est difficilement lisible, ou lorsque le calcul à faire est trop difficile.

Ces tests peuvent en outre être impossibles à réussir pour certaines personnes, par exemple les déficients visuels, qui ne peuvent ainsi pas accéder aux services web protégés par ces tests.

[0011] Il existe donc un besoin d'améliorer l'efficacité des tests de différenciation d'un uti- lisateur humain d'un ordinateur, tout en simplifiant ces tests pour l'utilisateur.

Exposé de l'invention

[0012] La présente invention concerne un procédé de vérification qu'un utilisateur d'un site web hébergé par un serveur est un être humain, ledit procédé comprenant les étapes suivantes mises en oeuvre par une platcforme de vérification : - authentification de l'utilisateur et, si l'authentification est réussie, envoi de données permettant une obtention, par un terminal de l'utilisateur, d'un premier code de sécurité, puis, suite à un accès de l'utilisateur audit site web au moyen du terminal : - réception d'un deuxième code de sécurité, suite à un envoi dudit deuxième code de sécurité par le terminal, - détermination de la validité du deuxième code de sécurité, le deuxième code de sécurité étant valide si ledit deuxième code de sécurité correspond au premier code de sécurité, et - si le deuxième code de sécurité est valide, envoi d'une confirmation que l'utilisateur est un être humain audit serveur hébergeant le site web.

[0013] Le procédé de vérification selon l'invention offre, via les étapes d'authentification de l'utilisateur et de détermination de la validité du deuxième code de sécurité, un double niveau de vérification que l'utilisateur est un être humain, ne pouvant être contourné par des algorithmes d'analyse d'images ou de sons.

[0014] En outre, le procédé de vérification selon -1' invention permet de vérifier que l'utilisateur est un être humain en limitant les actions de l'utilisateur, relatives à cette vérification, lors de son accès au site web.

[0015] L'invention permet ainsi de vérifier efficacement que l'utilisateur d'un site web est un être humain, cette vérification restant simple pour l'utilisateur.

[0016] Dans un mode de réalisation particulier, le procédé comprend les étapes suivantes : - réception d'un élément d'authentification de l'utilisateur, - détermination de si l'élément d'authentification est valide, l'authentification étant 3 réussie en cas de validité de l'élément d'authentification.

[0017] L'authentification de l'utilisateur est ainsi réalisée en limitant les actions de l'utilisateur.

La vérification est ainsi simplifiée du point de vue utilisateur.

[0018] Dans un mode de réalisation particulier, l'élément d'authentification est un IMSI d'un élément sécurisé incorporé dans le terminal de l'utilisateur.

[0019] L'IMSI (pour « International Mobile Subscribcr Identity », en terminologie anglo- saxonne), étant un numéro unique permettant à un réseau de téléphonie mobile d'identifier un utilisateur, la détermination de la validité de l'IMSI permet de prouver que l'utilisateur est un être humain et non un ordinateur.

[0020] L'authentification de l'utilisateur est ainsi réalisée sans intervention de l'utilisateur, la vérification que l'utilisateur est un être humain étant alors totalement transparente pour l'utilisateur, ce qui simplifie encore la vérification du point de vue de l'utilisateur.

[0021] Dans un mode de réalisation particulier, l'authentification de l'utilisateur est réussie lorsque la plateforme reçoit un message d'authentification envoyé par un équipement de terminaison de réseau, l'envoi dudit message d'authentification étant réalisé suite à la connexion de l'utilisateur audit équipement de terminaison de réseau au moyen d'un identifiant de connexion et d'un mot de passe.

[0022] L'authentification de l'utilisateur est ainsi réalisée en limitant les actions de l'utilisateur, ces actions étant limitées à la saisie d'un identifiant et d'un mot de passe, pouvant d'ailleurs être réalisées par l'utilisateur afin de bénéficier d'un autre service proposé par l'équipement de terminaison de réseau.

La vérification est ainsi simplifiée du point de vue utilisateur.

[0023] Dans un mode de réalisation particulier, les données permettant l'obtention d'un premier code de sécurité comprennent des données d'installation d'un module de gestion de code de sécurité, ledit module de gestion étant apte à obtenir ledit premier code de sécurité.

[0024] L'installation d'un module dédié à la gestion de code de sécurité, après avoir au- thentifié l'utilisateur, permet de renforcer l'efficacité du procédé de vérification selon l'invention, le module de gestion permettant au terminal d'obtenir le premier code de sécurité avant que l'utilisateur accède au site web.

[0025] Dans un mode de réalisation particulier, les données permettant l'obtention d'un premier code de sécurité comprennent le premier code de sécurité.

[0026] Le premier code de sécurité est donc obtenu par le terminal une fois l'authentification de l'utilisateur réussie, ceci permettant un double niveau de vérification que l'utilisateur est un être humain.

[0027] Dans un mode de réalisation particulier, le procédé comprend en outre, après les étapes d'authentification et d'envoi de données, une étape d'envoi d'un nouveau premier code de sécurité, de sorte que si l'utilisateur accède au site web après l'envoi du nouveau premier code de sécurité, le deuxième code de sécurité est déterminé comme étant valide si ledit deuxième code de sécurité correspond au nouveau premier code de sécurité.

[0028] L'envoi d'un nouveau premier code de sécurité permet de sécuriser d'avantage le procédé de vérification, et ainsi d'améliorer son efficacité.

[0029] Dans un mode de réalisation particulier, l'étape de détermination de la validité du deuxième code de sécurité comprend un déchiffrage du deuxième code de sécurité.

[0030] Le chiffrage du deuxième code de sécurité permet de sécuriser d'avantage le procédé de vérification, et ainsi d'améliorer son efficacité.

[0031] L'invention concerne de plus une plateforrne de vérification apte à vérifier qu'un uti- lisateur d'un site web hébergé par un serveur est un être humain, ladite plateforme comprenant : - un module d'authentification apte à authentifier l'utilisateur, - un premier module d'envoi apte à envoyer, si l'authentification est réussie, des données permettant une obtention, par un terminal de l'utilisateur, d'un premier code de sécurité, - un module de réception apte à réceptionner un deuxième code de sécurité, suite à un envoi dudit deuxième code de sécurité par le terminal, suite à un accès de l'utilisateur audit site web au moyen du terminal, - un module de détermination apte à déterminer la validité du deuxième code de sécurité, le deuxième code de sécurité étant valide si ledit deuxième code de sécurité correspond au premier code de sécurité, et - un deuxième module d'envoi apte à envoyer, si le deuxième code de sécurité est valide, une confirmation que l'utilisateur est un être humain audit serveur hébergeant le site web.

[0032] Dans un mode particulier de réalisation, les différentes étapes du procédé de véri- fication sont déterminées par des instructions de programmes d'ordinateurs.

[0033] En conséquence, l'invention vise aussi un programme d'ordinateur, sur un support d'informations, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de vérification selon l'invention.

[0034] Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

[0035] L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

[0036] Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme.

Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur.

[0037] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens.

Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

[0038] Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins

[0039] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif.

Sur les figures :

[0040] [fig.11 La figure 1 représente, de manière schématique, un système comprenant une plateforme de vérification selon un exemple de mode de réalisation de l'invention ;

[0041] [fig.21 La figure 2 représente, de manière schématique, la plateforme de vérification du système de la figure 1 ;

[0042] [fig.31 La figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé de vérification, selon un exemple de mode de réalisation de l'invention ;

[0043] [fig.4A-4131 Les figures 4A et 4B représentent, de manière schématique, des variantes de réalisation d'une étape d'authentification du procédé de vérification de la figure 3 ;

[0044] [fig.5A-5131 Les figures 5A et 5B représentent, de manière schématique, des variantes de réalisation d'une étape d'obtention du procédé de vérification de la figure 3;

[0045] [fig.6A-6131 Les figures 6A et 6B représentent, de manière schématique, des variantes de réalisation d'une étape de vérification du procédé de vérification de la figure 3 ;

[0046] [fig.71 La figure 7 représente, de manière schématique, un exemple de réalisation d'une étape de prise en compte du résultat de l'étape de vérification du procédé de vérification de la figure 3.

Description des modes de réalisation 100471 La figure I représente, de manière schématique, un système 100 comprenant une plateforme 110 de vérification, apte à mettre en oeuvre un procédé de vérification qu'un utilisateur d'un site web est un être humain, selon un exemple de mode de réalisation de l'invention.

100481 La plateforme 110 est une plateforme informatique, c'est-à-dire un environnement 6 dans lequel un logiciel peut être exécuté.

La plateforme 110 comprend un module d'authentification 112, un premier module d'envoi 114, un module de réception 116, un module de détermination 118, et un deuxième module d'envoi 119, dont les rôles seront décrits ci-après, en référence aux figures 3 à 7.

[0049] Le système 100 comprend en outre un terminal 120, un serveur 130 tel qu'un serveur web, et peut comprendre un équipement de terminaison de réseau 140.

[0050] La plateforme 110, le terminal 120, le serveur 130 et/ou l'équipement de terminaison de réseau 140 sont typiquement aptes à communiquer au moyen d'un réseau 150 de télécommunications.

[0051] Le terminal 120 peut être un terminal fixe ou un terminal mobile, tel qu'un téléphone portable, par exemple de type « smartphone », une tablette numérique, ou un ordinateur personnel.

Un élément sécurisé 122, typiquement de type « UICC » (« Universal Integrated Circuit Card » en terminologie anglo-saxonne), ou « cUICC » (pour « embedded Universal Integrated Circuit Card » en terminologie anglo-saxonne) peut ainsi être incorporé dans le terminal 120.

[0052] Le serveur 130 héberge au moins un site web pour lequel il est nécessaire de vérifier que les utilisateurs de cc site web sont des humains.

Le serveur 130 héberge typiquement une pluralité de sites web.

Le serveur 130 comprend typiquement une interface de programmation applicativc ou API (pour « Application Programming Interface » en terminologie anglo-saxonne) dédiée à la vérification susmentionnée.

[0053] De plus, l'équipement de terminaison de réseau 140 peut typiquement être une box d'accès au réseau.

[0054] Comme décrit ci-après en référence aux figures 5A, 5B, un module de gestion 124, 144 de code de sécurité peut être installé sur le terminal 120 (typiquement au niveau d'un navigateur du terminal 120) ou sur l'équipement de terminaison de réseau 140.

[0055] En outre, le réseau de télécommunication 150 peut être un réseau de télécommu- nications filaire ou sans fil, mobile ou fixe, et donc peut être un réseau Internet, un réseau Wifi, ou un réseau de téléphonie fixe ou mobile (de type 3G, 4G etc.).

[0056] Comme le montre la figure 2, la plateforme 110 présente l'architecture conven- tionnelle d'un ordinateur.

La plateforme 110 comporte notamment un processeur 200, une mémoire morte 202 (de type « ROM »), une mémoire non volatile réinscriptible 204 (de type « EEPROM » ou « Flash NAND » par exemple), une mémoire volatile ré-inscriptible 206 (de type « RAM »), et une interface de communication 208.

[0057] La mémoire morte 202 de la plateforme 110 constitue un support d'enregistrement conforme à un exemple de mode de réalisation de l'invention, lisible par le processeur 200 et sur lequel est enregistré un programme d'ordinateur PI conforme à un exemple de mode de réalisation de l'invention.

En variante, le programme d'ordinateur PI est stocké dans la mémoire non volatile réinscriptible 204. 7

[0058] Le programme d'ordinateur P1 permet à la plateforme 110 de mettre en oeuvre un procédé de vérification conforme à un exemple de mode de réalisation de l'invention, ou au moins une partie de cc procédé.

[0059] Ce programme d'ordinateur P1 peut ainsi définir des modules fonctionnels et logiciels de la plateforme 110, configurés pour mettre en oeuvre les étapes d'un procédé de vérification conforme à un exemple de mode de réalisation de l'invention, ou au moins une partie de ces étapes.

Ces modules fonctionnels s'appuient sur ou commandent les éléments matériels 200, 202, 204, 206 et 208 de la plateforme 110 cités précédemment.

Ils peuvent comprendre notamment ici le module d'authentification 112, le premier module d'envoi 114, le module de réception 116, le module de détermination 118, et le deuxième module d'envoi 119.

[0060] En outre, le terminal 120, le serveur 130 et l'équipement de terminaison de réseau 140 peuvent aussi chacun présenter l'architecture conventionnelle d'un ordinateur, et ainsi notamment comporter un processeur, une mémoire morte (de type « ROM »), une mémoire non volatile réinscriptible (de type « EEPROM » ou « Flash NAND » par exemple), une mémoire volatile réinscriptible (de type « RAM »), et une interface de communication.

[0061] Chaque mémoire morte peut constituer un support d'enregistrement conforme à un exemple de mode de réalisation de l'invention, lisible par le processeur associé et sur lequel est enregistré un programme d'ordinateur conforme à un exemple de mode de réalisation de l'invention.

En variante, le programme d'ordinateur est stocké dans la mémoire non volatile réinscriptible associée.

Le programme d'ordinateur peut permettre la mise en oeuvre d'au moins une partie du procédé de vérification conforme à un exemple de mode de réalisation de l'invention.

[0062] La figure 3 représente un procédé de vérification qu'un utilisateur d'un site web hébergé par un serveur est un être humain, selon un exemple de mode de réalisation de l'invention.

[0063] Le procédé est typiquement mis en oeuvre par le système 100 décrit en référence à la figure I.

Le serveur hébergeant le site web est alors le serveur 130 du système 100 de la figure 1.

[0064] Le procédé comprend une phase préliminaire Pl, permettant au terminal 120 d'obtenir un premier code de sécurité avant qu'un utilisateur U du terminal 120 accède au site web.

[0065] Cette phase préliminaire PI comprend une étape S310 d'authentification de l'utilisateur U du terminal 120, cette étape d'authentification visant à prouver que l'utilisateur U du terminal 120 est un être humain.

[0066] L'étape S310 d'authentification comprend typiquement une étape E411 de réception, par le terminal 120, d'une requête d'authentification RA envoyée par la plateforme 8 110, via le réseau 150 (étape F411, voir figure 4A).

En variante, la requête d'authentification RA est envoyée par l'équipement de terminaison de réseau 140, par exemple après une mise à jour dudit équipement de terminaison de réseau 140.

[0067] Le terminal 120 peut envoyer à la plateforme 110, via le réseau 150, un élément d'authentification EA de l'utilisateur U (étape E412).

Après réception F412 de l'élément d'authentification EA, le module d'authentification 112 de la plateforme 110 détermine F414 si l'élément d'authentification EA est valide, l'authentification étant réussie en cas de validité de l'élément d'authentification EA.

[0068] Lorsqu'un élément sécurisé 122 est incorporé dans le terminal 120, l'élément d'authentification EA est par exemple l'IMSI (pour « International Mobile Subscribcr Identity », en terminologie anglo-saxonne) de l'élément sécurisé 122 incorporé dans le terminal 120 de l'utilisateur U.

[0069] En effet, l'IMSI étant un numéro unique, comprenant 16 à 19 chiffres et permettant à un réseau de téléphonie mobile d'identifier un utilisateur, la détermination de la validité de l'IMSI permet de prouver que l'utilisateur est un être humain et non un ordinateur.

Plus précisément, la plateforme 110 vérifie que l'IMSI est valide, et peut aussi vérifier que l'IMSI correspond à un contrat de type « utilisateur » (i.e. liant un être humain à un opérateur téléphonique) et qu'il ne correspond ainsi pas à un contrat de type « M2M (pour « Machine to Machine », en terminologie anglo-saxonne).

L'authentification est alors réussie si l'IMSI est valide et si l'IMSI correspond à un contrat de type « utilisateur ».

[0070] En variante, l'élément d'authentification EA est un code d'authentification envoyé, préalablement à l'étape E412, à l'utilisateur U.

Plus précisément, le code d'authentification peut être envoyé par la platefonne 110, par exemple au terminal 120 de l'utilisateur U.

Le code d'authentification est typiquement incorporé dans un message de type « SMS » (pour « Short Message Service », en terminologie anglo-saxonne), un message de type « MMS » (pour « Multimedia Messaging Service », en terminologie anglo-saxonne), un email, un message de messagerie instantanée, etc.

[0071] L'utilisateur U peut alors lire ou entendre le code d'authentification puis saisir le code d'authentification au moyen d'une interface homme/machine du terminal 120.

Le terminal 120 envoie ensuite le code d'authentification à la plateforme 110, dans l'étape E412.

Le module d'authentification 112 de la plateforme 110 détermine alors si le code d'authentification reçu correspond au code d'authentification envoyé, le code d'authentification reçu étant valide en cas de correspondance.

[0072] En variante, l'authentification de l'utilisateur est réalisée au moyen de l'IMSI et d'un code d'authentification envoyé à l'utilisateur.

Le terminal 120 envoie alors à l'étape E412 deux éléments d'authentification EA, le premier élément d'authentification étant l'IMSI et le deuxième étant le code d'authentification envoyé.

L'authentification est 9 alors réussie si l'IMST et le code d'authentification sont valides, et éventuellement si l'IMST correspond à un contrat de type « utilisateur ».

[0073] En variante aux étapes E411, E412, F412 et F414, l'étape S310 d'authentification peut comprendre une étape E416 dans laquelle l'utilisateur U se connecte, via le terminal 120, à l'équipement de terminaison de réseau 140 (voir figure 4B).

Plus précisément, l'utilisateur U saisit un identifiant de connexion TC et un mot de passe MP au moyen de l'interface homme/machine du terminal 120, puis le terminal 120 envoie l'identifiant de connexion et le mot dc passe à l'équipement de terminaison de réseau 140.

[0074] L'équipement dc terminaison de réseau 140 peut alors déterminer si l'identifiant de connexion et le mot de passe sont valides.

Dans l'affirmative, l'utilisateur U est alors connecté à l'équipement de terminaison de réseau 140, et l'équipement de terminaison de réseau 140 peut, dans une étape G418, envoyer un message d'authentification MA à la plateforme 110, via le réseau 150.

La réception F418 du message d'authentification MA par la plateforme 110 permet au module d'authentification 112 de la plateforme 110 d'authentifier avec succès l'utilisateur U du terminal 120 (authentification réussie).

[0075] Lorsqu'à l'issue de l'étape S310 d'authentification, l'utilisateur U du terminal 120 est authentifié avec succès, la phase préliminaire Pl peut comprendre une étape S320 d'obtention d'un premier code dc sécurité CS1.

L'étape 5320 d'obtention comprend une étape F521 dans laquelle le premier module d'envoi 114 de la plateforme 110 envoie des données DCS permettant une obtention, par le terminal 120 de l'utilisateur U, du premier code de sécurité CS1.

[0076] Les données DCS comprennent par exemple des données d'installation du module de gestion 124, 144 de code de sécurité, par exemple des données correspondant à une application apte à installer le module de gestion.

Les données DCS peuvent alors être envoyées par le premier module d'envoi 114 de la plateforme 110 au terminal 120, via le réseau 150.

Suite à la réception E521 des données DCS, le terminal 120 installe, dans une étape E522, le module de gestion 124 de code de sécurité sur le terminal 120 (voir figure 5A).

Le terminal installe par exemple l'application au moyen des données DCS, l'application installant ensuite le module de gestion 124, 144 de code de sécurité, par exemple au niveau d'un navigateur du terminal 120.

Afin d'installer le module de gestion 124, 144, l'application peut demander à l'utilisateur un identifiant de l'utilisateur et un mot de passe, typiquement l'identifiant de connexion IC et le mot de passe MP.

Un contrôle supplémentaire au moyen d'un code d'authentification incorporé dans un message peut aussi être réalisé.

[0077] En variante, les données permettant l'obtention peuvent être envoyées, via le réseau 150, par le premier module d'envoi 114 de la plateforme 110 à l'équipement de ter- minaison de réseau 140, l'équipement de terminaison dc réseau 140 installant ensuite, dans une étape 0522, le module de gestion 144 de code de sécurité sur l'équipement de terminaison de réseau 114 (voir figure 5B).

[0078] Une fois installé, le module dc gestion 124, 144 de code de sécurité peut envoyer, dans une étape E524, 0524 une requête d'obtention RO du premier code dc sécurité CS1 à la plateforme 110, via le réseau 150.

Sous réception F524 de la requête d'obtention, la plateforme 110 envoie, dans une étape F526, le premier code de sécurité CS1.

[0079] Avant d'envoyer le premier code de sécurité CS1, la plateforme 110 génère ty- piquement le premier code dc sécurité CS1, puis l'enregistre dans sa mémoire (par exemple dans la mémoire non volatile réinscriptible 214).

La plateforme 110 peut en outre chiffrer le premier code de sécurité CS1 au moyen d'une clé de chiffrage, ou utiliser un jeton d'authentification (« token », en terminologie anglo-saxonne), ce jeton pouvant être sur 15 chiffres et pouvant être renouvelé, soit à une heure donnée chaque jour, soit éventuellement à chaque utilisation.

[0080] Le module de gestion 124, 144 obtient alors, dans une étape E526. 0526, le premier code de sécurité CS1.

Dans le cas où le module de gestion 124 est installé sur l'équipement de terminaison de réseau 140, l'équipement de terminaison de réseau 140 transfère le premier code de sécurité CS1 au terminal 120, de sorte que le terminal 120 obtienne le premier code de sécurité CS1 (étape 0528).

[0081] En variante, le module de gestion 124, 144 génère le premier code de sécurité CS1, puis l'envoie à la plateforme 110 via le réseau 150, typiquement après avoir chiffré le premier code de sécurité au moyen d'une clé de chiffrage, ou en utilisant un jeton d'authentification.

La plateforme 110 enregistre alors le premier code de sécurité CS1 dans sa mémoire (par exemple dans la mémoire non volatile réinscriptible 204), typiquement après l'avoir déchiffré.

[0082] En variante, les données DCS permettant l'obtention du premier code de sécurité CS1 peuvent comprendre le premier code de sécurité CS1.

Le module de gestion 124, 144 obtient alors le premier code de sécurité CS1 lors de son installation, puis, dans le cas où le module de gestion 144 est installé sur l'équipement de terminaison de réseau 140, le transfère au terminal 120.

[0083] Après obtention du premier code de sécurité par le terminal 120, ledit premier code de sécurité CSI peut être enregistré (étape E529) dans la mémoire du terminal 120, par exemple dans la mémoire non volatile réinscriptible du terminal 120.

[0084] Le procédé comprend aussi une phase d'utilisation P2, durant laquelle l'utilisateur U du terminal 120 souhaite accéder, via le terminal 120, à un site web pour lequel il est nécessaire de vérifier que l'utilisateur est un être humain.

[0085] La phase d'utilisation comprend typiquement une étape S330 de vérification d'un 11 code de sécurité appelé deuxième code de sécurité CS2, décrite en référence aux figures 6A, 6B.

[0086] L'utilisateur accède typiquement à une première page wcb, affichée par le terminal 120 et correspondant au site web indiquant qu'il est nécessaire de vérifier que l'utilisateur est un être humain, la page wcb pouvant comprendre un élément demandant une action de l'utilisateur U, par exemple une case devant être cochée, ou encore un bouton à cliquer.

[0087] Comme le montrent les figures 6A et 6B, la réalisation de l'action demandée par la page wch peut déclencher l'émission E631 d'une commande de gestion CG envoyée au module de gestion 124, 144.

En variante, l'émission E631 de la commande de gestion CG peut être déclenchée par l'affichage de la première page web.

[0088] Sous réception de la commande de gestion CG, le module de gestion 124, 144 obtient E632. 0632 le deuxième code de sécurité CS2.

[0089] Dans le cas où la phase préliminaire P1 s'est déroulée avec succès, c'est-à-dire que l'utilisateur U du terminal 120 est authentifié avec succès à l'étape S310 et que le premier code de sécurité CS1 est enregistré dans la mémoire du terminal 120, le deuxième code de sécurité CS2 correspond au premier code de sécurité CS1.

Le deuxième code de sécurité CS2 est ainsi typiquement identique au premier code de sécurité CS1.

[0090] Ainsi, lorsque le module de gestion 124 est installé dans le terminal 120, le module de gestion 124 consulte la mémoire du terminal 120 afin de récupérer le premier code de sécurité CSI (voir figure 6A).

Lorsque le module de gestion 144 est installé sur l'équipement de terminaison de réseau 140, le module de gestion 144 envoie une requête d'obtention au terminal 120, le terminal envoyant le premier code de sécurité au module de gestion sous réception de cette requête d'obtention (voir figure 6B).

[0091] Le module de gestion 124, 144 envoie ensuite, au serveur 130, via le réseau 150, le deuxième code de sécurité CS2 (étape E634, 0634).

Sous réception H634 du deuxième code de sécurité CS2 et de l'éventuel identifiant du terminal 120, le serveur transfère H336, typiquement via son API, le deuxième code de sécurité CS2 à la plateforme 110, afin que la validité du deuxième code de sécurité CS2 soit vérifiée.

[0092] En variante, le module de gestion 124, 144 envoie le deuxième code de sécurité CS2 à la plateforme 110, le deuxième code de sécurité C52 ne transitant alors pas par le serveur 130.

[0093] Après réception F636 du deuxième code de sécurité CS2 par le module de réception 116 de la plateforme 110, le module de détermination 118 de la plateforme 110 détermine, dans une étape F638, si le deuxième code de sécurité CS2 est valide, le deuxième code de sécurité CS2 étant valide si ledit deuxième code de sécurité CS2 correspond au premier code de sécurité CS1. 12

[0094] Plus précisément, le module de détermination 118 recherche dans la mémoire de la plateforme 110 un code de sécurité correspondant au deuxième code de sécurité CS2, typiquement en comparant le deuxième code de sécurité CS2 à un ou plusieurs codes stockés dans la mémoire de la plateforme 110.

Dans le cas où le deuxième code de sécurité CS2 correspond au premier code de sécurité CS1, par exemple parce qu'ils sont identiques, le module de détermination 118 trouve le premier code de sécurité CS1 dans la mémoire de la plateforme 100, et détermine alors que le deuxième code de sécurité CS2 est valide.

[0095] Dans le cas où le deuxième code de sécurité CS2 est chiffré (par exemple parce qu'il correspond au premier code de sécurité CS1 chiffré obtenu par le module de gestion 124, 144), le module de détermination 118 peut déchiffrer le deuxième code de sécurité CS2 avant de le rechercher dans la mémoire de la plateforme 110.

[0096] Le module de détermination 118 de la plateforme 110 peut aussi contrôler une ou plusieurs caractéristiques relatives au terminal 120, telles que par exemple le type de navigateur, le type d'écran ou l'adresse IP du terminal 120.

Si une de ces caractéristiques est modifiée entre l'étape S310 et l'étape S330, un contrôle supplémentaire peut être réalisé, par exemple au moyen d'un code d'authentification incorporé dans un message envoyé au terminal 120.

[0097] La phase d'utilisation P2 peut ensuite comprendre une étape S340 de prise en compte du résultat de l'étape S330 de vérification de la validité du deuxième code de sécurité CS2, décrite ci-dessous en référence à la figure 7.

[0098] Comme le montre la figure 7, si le deuxième code de sécurité CS2 est valide, le deuxième module d'envoi 119 de la plateforme 110 envoie F742 une confirmation que l'utilisateur U est un être humain au serveur 130 hébergeant le site web.

[0099] Sous réception H742 de cette confirmation, le serveur 130 peut, typiquement via son API, autoriser H744 le terminal 120, et donc l'utilisateur U du terminal 120, à accéder au site web.

Plus précisément, le serveur 130 peut autoriser H744 le terminal 120, et donc l'utilisateur U du terminal 120, à accéder à une deuxième page web correspondant au site web, pouvant alors être affichée par le terminal 120.

[0100] On considère maintenant un cas où un ordinateur potentiellement malveillant tente d'accéder au site web, ou un cas d'échec d'authentification de l'utilisateur à l'étape S310 d'authentification.

Aucun premier code de sécurité n'est alors obtenu à l'étape S320, car il ne peut être prouvé que l'utilisateur est un être humain.

Aussi, aucun deuxième code de sécurité C52 n'est reçu par la plateforme 110.

En variante, un deuxième code de sécurité C52 est reçu par la plateforme 110 à l'étape F636 mais ce deuxième code de sécurité C52 ne correspond alors pas au premier code de sécurité CS1.

Le deuxième code de sécurité CS2 n'est ainsi pas valide.

[0101] La plateforme 110 envoie au serveur 130 un avertissement indiquant que l'utilisateur 13 du site web est potentiellement un ordinateur.

Sous réception de cet avertissement, le serveur 130 peut, typiquement via son APT, interdire à l'utilisateur l'accès au site web (typiquement à la deuxième page web), ce qui peut permettre au serveur 130 d'être victime d'une attaque informatique ayant pour but de rendre le site web indisponible, telle qu'une attaque par inondation de requêtes.

[0102] Les étapes S310 et/ou S320 peuvent être réitérées une ou plusieurs fois, chacune de ces itérations pouvant être mise en oeuvre avant l'étape S330 ou après l'étape S330.

La réitération des étapes S310 et/ou S320 est typiquement mise en oeuvre de manière périodique.

[0103] La réitération de l'étape S320 permet l'obtention d'un nouveau premier code de sécurité, de sorte que si l'utilisateur U accède au site web après l'envoi du nouveau premier code de sécurité, le deuxième code de sécurité est déterminé comme étant valide si ledit deuxième code de sécurité correspond au nouveau premier code de sécurité.

[0104] En outre, les étapes S330 et/ou S340 peuvent être réitérées une ou plusieurs fois, à chaque fois que l'utilisateur U souhaite accéder, via le terminal 120, au site web hébergé par le serveur 130, et/ou à un autre site web nécessitant de vérifier que l'utilisateur est un être humain, hébergé par le serveur 130 ou un autre serveur.

14 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]

Claims (1)

1. REVENDICATIONSProcédé dc vérification qu'un utilisateur ((J) d'un site web hébergé par un serveur (130) est un être humain, ledit procédé comprenant les étapes suivantes, mises en oeuvre par une plateforme (110) de vérification : - authentification (F414, F418) de l'utilisateur (U) et, si l'authentification est réussie, envoi (F521) de données (DCS) permettant une obtention, par un terminal (120) de l'utilisateur (U), d'un premier code dc sécurité (CS1), puis, suite à un accès de l'utilisateur (U) audit site web au moyen du terminal (120) : - réception (F636) d'un deuxième code de sécurité (CS2), suite à un envoi dudit deuxième code de sécurité (CS2) par le terminal (120), - détermination (F638) de la validité du deuxième code de sécurité (CS2), le deuxième code de sécurité (CS2) étant valide si ledit deuxième code de sécurité (CS2) correspond au premier code de sécurité (CS1), et - si le deuxième code de sécurité (CS2) est valide, envoi (F742) d'une confirmation que l'utilisateur (U) est un être humain audit serveur (130) hébergeant le site web. Procédé de vérification selon la revendication 1, comprenant les étapes suivantes : - réception (F412) d'un élément d'authentification (EA) de l'utilisateur, - détermination (F414) de si l'élément d'authentification (EA) est valide, l'authentification étant réussie en cas de validité de l'élément d'authentification. Procédé de vérification selon la revendication 2, dans lequel l'élément d'authentification (EA) est un IMSI d'un élément sécurisé (122) incorporé dans le terminal (120) de l'utilisateur (U). Procédé de vérification selon la revendication 1, dans lequel l'authentification de l'utilisateur est réussie lorsque la plateforme (110) reçoit (F418) un message d'authentification (MA) envoyé par un équipement de terminaison de réseau (140), l'envoi dudit message d'authentification (MA) étant réalisé suite à la connexion de l'utilisateur (U) audit équipement de terminaison de réseau (140) au moyen d'un identifiant de connexion (IC) et d'un mot de passe (MP). Procédé selon l'une quelconque des revendications 1 à 4, dans lequel les données (DCS) permettant l'obtention d'un premier code de sécurité comprennent des données d'installation d'un module de gestion (124, 15 [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] 144) de code de sécurité, ledit module de gestion (124, 144) étant apte à obtenir ledit premier code de sécurité. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel les données (DCS) permettant l'obtention d'un premier code de sécurité comprennent le premier code de sécurité (CS1). Procédé selon l'une quelconque des revendications 1 à 6, comprenant en outre, après les étapes d'authentification (F414, F418) et d'envoi (F521) de données (DCS), une étape d'envoi d'un nouveau premier code de sécurité, de sorte que si l'utilisateur (U) accède au site weh après l'envoi du nouveau premier code de sécurité, le deuxième code de sécurité (CS2) est déterminé comme étant valide si ledit deuxième code de sécurité (CS2) correspond au nouveau premier code de sécurité. Procédé de vérification selon l'une quelconque des revendications 1 à 7, dans lequel l'étape (F638) de détermination de la validité du deuxième code de sécurité (CS2) comprend un déchiffrage du deuxième code de sécurité (CS2). Plateforme (110) de vérification apte à vérifier qu'un utilisateur (U) d'un site web hébergé par un serveur (130) est un être humain, ladite plateforme (110) comprenant : - un module d'authentification (112) apte à authentifier l'utilisateur (U), - un premier module d'envoi (114) apte à envoyer, si l'authentification est réussie, des données (DCS) permettant une obtention, par un terminal (120) de l'utilisateur (U), d'un premier code de sécurité (CS1), - un module de réception (116) apte à réceptionner un deuxième code de sécurité (CS2), suite à un envoi dudit deuxième code de sécurité (CS2) par le terminal (120), suite à un accès de l'utilisateur (U) audit site web au moyen du terminal (120), - un module de détermination (118) apte à déterminer la validité du deuxième code de sécurité (CS2), le deuxième code de sécurité (CS2) étant valide si ledit deuxième code de sécurité (CS2) correspond au premier code de sécurité (CS1), et - un deuxième module d'envoi (119) apte à envoyer, si le deuxième code de sécurité (CS2) est valide, une confirmation que l'utilisateur (U) est un être humain audit serveur (130) hébergeant le site web. Programme d'ordinateur (P1) comportant des instructions pour l'exécution des étapes du procédé de vérification selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par un or- 16 [Revendication 11] dinateur. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (P1) comprenant des instructions pour l'exécution des étapes du procédé de vérification selon l'une quelconque des revendications 1 à 8.