FR 2940727 A1 20100702 FR 0904856 A 20091009 -1- Système d'Authentification Simplifié (SAS) Référence : MFL - BT R1 / 08 06682 Généralités L'objectif du S.A.S. est d'accélérer l'authentification forte d'un ou plusieurs utilisateurs de l'Internet. Ces données permettent à un utilisateur d'être authentifié sur un serveur du réseau Internet. Le S.A.S. est particulièrement destiné à sécuriser les accès aux sites internet disposant d'une banque de données de leurs utilisateurs ou abonnés. Il leur offre également la possibilité de communiquer de manière anonyme. L'authentification forte s'appuie sur trois éléments : ce que l'utilisateur détient (un jeton ou ticket) 15 et où l'utilisateur se situe (adresse IP) et quand l'utilisateur a le droit de se connecter (période de validité du ticket). L'invention concerne principalement un procédé destiné à authentifier rapidement des utilisateurs du réseau Internet sur une machine offrant un service basé sur le protocole HTTP1 ou HTTPS, 20 sans contraindre l'utilisateur à retenir un mot de passe. Dans un premier temps, lors de sa première demande d'enregistrement, l'utilisateur fournit au serveur son adresse de courrier électronique. Il est alors enregistré dans la base de comptes temporaire et reçoit un ticket contenant un lien hypertexte lui permettant de s'enregistrer 25 définitivement dans la base de comptes. Ce ticket contient également un lien permettant à l'utilisateur de se connecter ultérieurement, une fois enregistré. Dans un second temps, il clique sur le lien d'inscription et le serveur exécute alors la requête d'enregistrement définitive. Par la suite, l'utilisateur peut continuer à utiliser le ticket de connexion pour se connecter, jusqu'à expiration de la validité de celui-ci. Au delà de cette période, il devra à nouveau fournir son 'Hyper Text Transfer Protocol 30 2940727 -2- adresse de courriel afin de recevoir un nouveau ticket de connexion. Ces tickets envoient alors une simple requête de contrôle de l'appartenance de l'utilisateur à la base de comptes. Etat de l'Art 5 Au jour d'aujourd'hui, deux méthodes permettent à un utilisateur d'être identifié sur un serveur : la première fait appel à un identifiant associé à un mot de passe, la seconde, moins répandue, fait appel aux certificats numériques. La première est courante, bien comprise par le plus grand nombre, mais très peu fiable. La seconde est au contraire très sûre, mais pas évidente à 10 appréhender par le grand public. La gestion des certificats numériques et de leur révocation, risque d'être boudée par la plupart des utilisateurs grand public. Pour la méthode la plus répandue, que se passe-t-il lors d'une séquence complète d'authentification ? 1. Création d'un compte à partir de la saisie d'un nom d'utilisateur (identifiant ou � login �) et d'un mot de passe, dans le meilleur des cas en s'appuyant sur le protocole TLS2, mais c'est encore très rare. 2. Confirmation a- dans le meilleur des cas : envoi d'un courriel de confirmation à l'utilisateur, qui clique sur un lien, et provoque son inscription définitive. b- sinon, il existe encore quelques sites qui se contentent de ces informations (identifiant + mot de passe) pour inscrire l'utilisateur directement dans la base de comptes actifs, mais cela tend à disparaître. 3. l'utilisateur se logue régulièrement en faisant (le plus souvent) transiter ses identifiants en clair sur l'Internet. Quiconque réussit à deviner ses identifiants peut alors se loguer à sa place, en usurpant son identité, quelque soit sa situation géographique, et son point d'accès au réseau. 4. En cas de perte de mot de passe, le serveur renvoie, en clair, un nouveau mot de passe, ou, un lien permettant d'aller le modifier. L'interception de ce courriel, par écoute sur le réseau, ou attaque du compte POP3, peut alors provoquer l'usurpation du compte. 'Transport Layer Security ' Post Office Protocol 2940727 -3 Le S.A.S. s'appuie sur la boite aux lettre électronique BAL4 de l'internaute afin de lui faire parvenir tout ce dont il a besoin pour s'inscrire et ensuite ouvrir une session sur le serveur. Nous parlerons alors de "ticket" de connexion. Il s'agit d'un ticket au sens virtuel, c'est à dire juste d'un 5 simple enregistrement dans une table, couplé à un lien hypertexte contenu dans un courriel. Le ticket vaut pour une durée paramétrable, mais il meurt dès que l'internaute se déconnecte du site. 10 Le ticket contient une information sur l'adresse IP5 de la provenance de la demande de connexion (ordinateur ou routeur), et sur la durée de validité du ticket. Le ticket est systématiquement envoyé dans la BAL de l'internaute, qui a fourni son adresse électronique lors de sa première demande de connexion. 15 Le ticket contient un identifiant et un mot de passe temporaires, permettant de retrouver l'enregistrement qui lui corespond dans la base de données. Aussi, l'interception de ce ticket, même pendant la durée de la période autorisée, n'est possible que par une personne agissant sous couvert de la même adresse IP source (Attaque Man in the Middle). 20 Si l'utilisateur change ses paramètres réseau (point d'accès), se déconnecte, ou si la durée de validité du ticket est dépassée, alors le ticket est détruit. L'usurpation de l'IP de l'utilisateur, couplée à l'attaque de sa BAL, ou à l'écoute des flux, ne vaudra que pour la période de validité préalablement définie. 25 ° Boite Aux Lettres (électronique) 5 Internet Protocol (adresse IP, adresse logique de la machines sur un réseau donné) Détails techniques Le procédé S.A.S. s'articule autour de deux notions principales, à savoir une base de données et le compte de courrier électronique de l'utilisateur. La base de données contient deux tables principales, la première étant la table de comptes utilisateurs, et la seconde, la table des tickets de connexion. De plus, il est indispensable que l'utilisateur dispose d'une adresse de courrier électronique, protégée par un moyen correct, pour qu'il puisse être traité par le S.A.S. Cette adresse peut être hébergé sur n'importe quel service de courrier électronique, indépendamment du S.A.S. Une troisième table vient compléter les deux premières, dont le contenu est temporaire puisqu'il s'agit de la table de pré inscription des utilisateurs. Le serveur sur lequel tourne le S.A.S. est un serveur Web classique disposant d'un service HTTP pour la publication des pages web, et d'un service SMTP pour communiquer avec l'utilisateur. Le TLS n'est pas indispensable, mais conseillé pour les phases de connexion. Trois tables sont donc utilisées : - utilisateurs temporaires - utilisateurs approuvés - tickets La table des utilisateurs temporaires est similaire à celle des utilisateurs approuvés, sauf qu'elle est uniquement en relation avec la table des tickets, afin de permettre à l'utilisateur d'être inséré dans la table des utilisateurs lorsqu'il accédera au site à l'aide du lien faisant référence à son numéro de ticket. Elle contient comme la table des utilisateurs approuvés, un identifiant ainsi que l'adresse de courriel de utilisateur, cryptée à l'aide d'une clé située dans une zone privative du serveur (non accessible au public), le timestamp6 de l'inscription, et le code d'activation. Pour s'inscrire, l'utilisateur fournit son adresse de courriel sur un formulaire, il est conseillé à ce stade, de lui demander de recopier un petit code de sécurité pour limiter le risque d'abus. L'utilisateur nouvellement inscrit est enregistré dans la table des utilisateurs pré inscrits, et le condensat de l'identifiant unique de son enregistrement est calculé, on l'appellera � precli_code �. 'Temps en seconde depuis le 1er janvier 1970 à minuit UTC précise - 4 2940727 -5- Une fois l'utilisateur pré-enregistré dans la table de pré inscription, un enregistrement est ajouté dans la table des tickets. La table des utilisateurs pré inscrits contient : 5 - un identifiant unique et incrémentiel - l'adresse de courriel cryptée - le timestamp de l'enregistrement - l'adresse IP de l'utilisateur - un champ � code d'activation � qui est le résultat d'un cryptage réversible de l'adresse de 10 courriel - un champ � login � qui contiendra le code d'activation, une fois l'utilisateur enregistré dans la table des utilisateurs approuvés. La table des tickets contient des condensats (hash' ou empreinte irréversible) : 15 - un identifiant unique et incrémentiel, jamais réutilisé - le condensat de cet identifiant qui sera utilisé dans le lien envoyé à l'utilisateur. Le condensat évite la prédiction du futur numéro de ticket - un mot de passe auto généré selon les règles de qualité en vigueur, et une entropie forte, ce mot de passe sera également utilisé dans le lien 20 - un champ client qui contient la référence unique à un utilisateur une fois qu'il est présent dans la table des utilisateurs enregistrés - un champ �il)� qui n'est autre que le condensat de la dernière adresse IP de l'utilisateur - un champ � code d'activation � qui est une copie de celui de la table précédente (lorq'un utilisateur n'est pas encore inscrit définitivement) 25 - le champ � precli_code � calculé précédemment (hash de l'identifiant de son enregistrement dans la table des utilisateurs pré inscrits) - le timestamp de l'enregistrement - un champ � mailcode � optionnel destiné à l'échange de courriel anonyme entre les utilisateurs 30 Le condensat (hash irréversible de l'identifiant de l'enregistrement précédent (table tickets) est ensuite envoyé par courriel à l'adresse fournie initialement par l'utilisateur. Cet identifiant est transmis comme une variable associée à l'URLB contenue dans le lien. Ce lien permet de revenir 'Le résultat d'une fonction de hachage selon l'algorithme d'une fonction à sens unique SUniform Resource Locator 2940727 -6- sur le site web avec comme paramètre cet identifiant de ticket, soit une variable agissant selon le mode HTTP GET9. Le lien contient également une variable "mot de passe", généré aléatoirement, selon l'état de l'art de la génération d'un mot de passe (longueur minimum, choix des caractères, casse). L'utilisateur interroge alors sa boite à lettre électronique et télécharge le courriel. Il clique en suite sur le lien qui le dirige sur la page principale du site web. Au niveau des entêtes de cette page, les variables sont analysées et l'internaute redirigé vers une page d'aiguillage, qui opère encore au niveau des entêtes http. 10 Une requête SQL10 � SELECT �" permet d'aller vérifier la présence d'un enregistrement dans la table des tickets avec comme identifiant, la valeur renvoyée par l'internaute. S'il est trouvé, alors la valeur des champs � precli_code � et � code d'activation � et � ip � sont enregistrés dans des variables de session, puis les champs � precli_code � et � code d'activation � sont remis à zéro. 15 Le condensat de l'adresse IP est alors comparé à la valeur du champ correspondant dans la table des tickets, et le timestamp actuel à celui de la valeur du champ correspondant dans cette même table, compte tenu d'une période de validité définie préalablement. Si ces deux valeurs (espace û temps) sont correctes, alors la page est ensuite redirigée vers une nouvelle qui procède à l'interrogation de la table des utilisateurs pré inscrits. Cette requête vérifie l'existence de la valeur 20 du � code d'activation � dans cette table. Si un enregistrement est trouvé, alors un enregistrement est inséré dans la table des utilisateurs approuvés, et l'enregistrement correspondant de la table des pé inscriptions est supprimé. Dans le même temps, la table des tickets est mise à jour afin d'associer le ticket à un utilisateur enregistré, en inscrivant l'id de ce dernier dans le champ � client �. La valeur du champ � code d'activation � est déplacée du champ correspondant vers le 25 champ � login �. Ainsi, lorsque l'utilisateur re-cliquera sur le lien initial, il sera redirigé vers une page qui permettra de rechercher s'il est inscrit dans la table des utilisateurs approuvés à condition que les valeurs de contrôle espace-temps (IP/timstamp) soient correctes. Il faut également prévoir les cas où l'utilisateur utilise son lien d'activation trop tard ou sous une 30 adresse IP source différente, et lui en renvoyer un nouveau après avoir remis à jour la table des pré inscriptions (effacement et nouvelle insertion). 'Requête de la ressource située à l'URL spécifiée (passage d'une variable dans l'URL) 10Structured Query Language "Sélection d'enregistrements répondants à des critères spécifiques 5 2940727 -7- Par la suite, l'utilisateur pourra réutiliser son lien pour se connecter tant que la période de validité est correcte, au delà, son ticket est effacé de la table, et un nouveau ticket est inscrit, mais directement indexé sur la table des utilisateurs approuvés, c'est à dire en renseignant seulement les champs � login �, � client �, � ip � et � timestamp �. 5 Un lien sur le site doit permettre à l'utilisateur de de déconnecter � en dur � c'est à dire de faire effacer son ticket. Il se trouvera alors dans la même situation que s'il était hors période de validité ou si son adresse IP avait changé. Un nouveau ticket lui sera envoyé lorsqu'il se reconnectera sur le site, soit grâce à son ancien ticket, soit en renseignant de nouveau le 10 formulaire avec son adresse de courriel. L'utilisateur peut être désinscrit en effaçant l'enregistrement correspondant dans la table des utilisateurs approuvés. S'il change d'adresse de courriel sans prévenir, et ne possède plus son ancienne adresse, il faut pouvoir, à sa demande (écrite ou téléphonique), régénérer le code 15 d'activation manuellement ou grâce à un script qui devra être désactivé une fois utilisé (ou effacé du serveur, ou mieux encore, généré localement). Aussi, cette possibilité n'est envisageable que si l'utilisateur a fourni, lors de son inscription, de quoi le contacter (adresse postale, numéro de téléphone), ce qui dépend de la politique du site web, sinon, cela n'est pas possible. 20 Une option "perte de ticket", sur la page d'identification, doit pouvoir permettre à l'utilisateur de régénérer son ticket en cas de perte, vol, ou simplement doute. Pour cela, un lien d'annulation d'urgence peut être communiqué à l'utilisateur dès sa première inscription. Il devra le conserver précieusement. Il reste encore la possibilité d'envoyer un courriel à l'administrateur du site. Aussi, la procédure de changement d'adresse de courriel ne doit pouvoir se faire que par un 25 moyen sûr, en vérifiant l'ancienne adresse. Le webmaster doit en avertir explicitement les utilisateurs pour ne pas occasionner de blocages. Si les utilisateurs désirent communiquer entre eux sans que leur adresse de courriel ne soit divulgué, des tickets peuvent être envoyés sur le même principe, en renseignant un champ 30 expéditeur et un champ destinataire avec les adresses électroniques sous forme cryptées symétrique. Le simple fait de renseigner ces deux champs détermine le type d'action à réaliser par le serveur, qui sera dans ce cas, non plus une authentification, mais un envoi de courriel. Les tickets permettront ainsi aux utilisateurs de dialoguer anonymement, grâce à un formulaire de contact. 2940727 -8- Le procédé S.A.S. permet non seulement aux utilisateurs de protéger leurs données de connexion, mais également de communiquer entre eux de manière anonyme par la suite. La S.A.S. accélère la procédure d'enregistrement d'un nouvel utilisateur, et ne nécessite pas 5 d'intervention humaine, hormis pour la maintenance classique mais pas spécifique. Le S.A.S peut traiter des demandes d'enregistrement ou d'autorisation multiples sur une même période. Les courriels envoyés aux internautes doivent scrupuleusement respecter l'état de l'art (RFC en vigueur) pour ne pas être considérés comme des courriel suspects (spam ou pourriel). 2940727 ANNEXE Les éléments de l'authentification forte Seuls des éléments ou facteurs inviolables et non subtilisables peuvent assurer une réelle solidité 5 pour une authentification. On considère que ces éléments peuvent être : • Ce que l'entité connaît (un mot de passe, un code NIP, une phrase secrète, etc.), • Ce que l'entité détient (une carte magnétique, RFID, une clé USB, un PDA, une carte à puce, etc. Soit un � Authentifieur � ou � Token �), • Ce que l'entité est, soit une personne physique (empreinte digitale, empreinte rétinienne, 10 structure de la main, structure osseuse du visage ou tout autre élément biométrique), • Ce que l'entité sait faire, soit une personne physique (biométrie comportementale tel que signature manuscrite, reconnaissance de la voix, un type de calcul connu de lui seul, etc.), • Où l'entité est, soit un endroit d'où, suite à une identification et authentification réussie, elle est autorisée (accéder à un système logique d'un endroit prescrit). REVENDICATIONS1. Préambule L'invention concerne un procédé d'authentification forte, d'un utilisateur sur un serveur du réseau Internet fonctionnant selon le protocole hypertexte HTTP. L'utilisateur s'inscrit en fournissant uniquement son adresse de courriel au serveur web, qui lui retourne un message électronique contenant un lien hypertexte pour s'inscrire puis, par la suite, pour se connecter. Le serveur web utilise une base de données pour administrer les demandes de connexion et d'inscription, ainsi qu'un service d'envoi de courriel selon le protocole SMTP. Ce procédé est caractérisé par le fait de se dispenser de retenir un mot de passe, ou d'utiliser les certificats numériques qui présentent l'inconvénient d'être parfois difficile à appréhender du grand public, et nécessitant une gestion rigoureuse. 2. Revendications 1. Procédé d'authentification forte d'un terminal utilisateur sur le réseau Internet caractérisé en ce qu'il comporte : une étape d'inscription du terminal utilisateur auprès d'un serveur Web par émission d'un formulaire comportant son adresse de courriel, ledit serveur Web étant connecté avec une base de données comprenant 3 tables : une table de pré-inscription temporaire, une table -des comptes utilisateurs approuvés permanente, une table de tickets "volatiles" ; une étape d'enregistrement du terminal utilisateur dans la table de pré-inscription temporaire à l'aide des données du formulaire, et de génération d'un enregistrement dans la table des tickets ; une étape d'émission d'un message, via un serveur de courrier, du serveur vers le terminal utilisateur, ledit message contenant un lien hypertexte permettant au terminal utilisateur de s'enregistrer définitivement dans la table des comptes utilisateurs approuvés. 2. Procédé d'authentification forte selon la revendication 1 caractérisé en ce que le lien contenu dans le message permet au terminal utilisateur d'ouvrir une session identifiée de manière unique sur le serveur lors de l'inscription définitive de l'utilisateur, et de renouveler cette ouverture de session ultérieurement une fois l'utilisateur enregistré. 3. Procédé d'authentification forte selon la revendication 1 caractérisé en ce qu'un clic de l'utilisateur sur le lien hypertexte déclenche l'enregistrement définitif dans la table des comptes 2940727 -11- utilisateurs approuvés sous réserve de vérification positive de la présence d'un enregistrement du terminal utilisateur dans la table de tickets et dans la table de pré-inscription temporaire. 4. Procédé d'authentification forte selon la revendication 2 caractérisé en ce que l'enregistrement 5 du terminal utilisateur dans la table des tickets comporte l'enregistrement dans cette table de l'adresse IP du terminal utilisateur dans un champ adresse IP. 5. Procédé d'authentification forte selon la revendication 2 caractérisé en ce que l'enregistrement du terminal utilisateur dans la table des tickets comporte l'enregistrement dans cette table d'une 10 date limite de validité du ticket dans un champ date sous forme d'un horodatage (� timestamp �). 6. Procédé d'authentification forte selon la revendication 2 caractérisé en ce que la génération d'un enregistrement dans la table des tickets comporte l'enregistrement dans cette table de l'identifiant unique du ticket et de l'identifiant unique de l'utilisateur inscrit ou pré-inscrit. 7. Procédé d'authentification forte selon la revendication 2 caractérisé en ce que le lien hypertexte contient, sous forme de variables, l'emprunte irréversible (hachage) l'identifiant de l'enregistrement relatif au terminal utilisateur dans la table des tickets, ainsi qu'un mot de passe fort auto généré selon l'état de l'art du moment. 20 8. Procédé d'authentification forte selon la revendication 1, caractérisé en ce qu'à chaque utilisation du ticket virtuel de connexion, la date de validité du ticket est comparée avec la date d'utilisation et l'adresse IP enregistrée pour identifier le terminal utilisateur dans la table des comptes utilisateurs approuvés est comparée avec l'adresse IP de l'utilisateur en cours et en ce 25 que si la date de validité est dépassée ou si l'adresse IP de l'utilisateur a changé, l'enregistrement relatif au terminal utilisateur dans la table des tickets est détruit, obligeant l'utilisateur à s'identifier de nouveau en fournissant son adresse de courriel pour recevoir un nouveau ticket. 9. Procédé d'authentification forte selon la revendication 8, caractérisé en ce que le nouveau 30 ticket est automatiquement envoyé à l'utilisateur en supposant que c'est ce dernier qui a tenté de se connecter. 15 2940727 - 12- 10. Procédé d'authentification forte selon la revendication 2, caractérisé en ce que l'utilisateur puisse choisir entre deux modes de déconnexion telles que la première détruit seulement la session en cours sur le serveur et le cookie de session chez le client et la seconde détruit le ticket dans la table des tickets.