FR3055053A1 - Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central - Google Patents

Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central Download PDF

Info

Publication number
FR3055053A1
FR3055053A1 FR1670443A FR1670443A FR3055053A1 FR 3055053 A1 FR3055053 A1 FR 3055053A1 FR 1670443 A FR1670443 A FR 1670443A FR 1670443 A FR1670443 A FR 1670443A FR 3055053 A1 FR3055053 A1 FR 3055053A1
Authority
FR
France
Prior art keywords
authentication
user
central server
module
token
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.)
Pending
Application number
FR1670443A
Other languages
English (en)
Inventor
Guillaume Dorbes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Auvercloud
Original Assignee
Auvercloud
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Auvercloud filed Critical Auvercloud
Priority to FR1670443A priority Critical patent/FR3055053A1/fr
Priority to PCT/IB2017/054589 priority patent/WO2018029564A1/fr
Publication of FR3055053A1 publication Critical patent/FR3055053A1/fr
Pending legal-status Critical Current

Links

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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • 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
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé d'authentification d'un utilisateur d'un système applicatif (10) par un serveur central (20), comprenant les étapes dans lesquelles : - un système applicatif (10) effectue (50) une demande d'authentification; - le serveur (20) central reçoit (51) la demande et génère (55) un jeton à durée limitée pour une pluralité de modes d'authentification ; - le serveur central (20) envoie (56) en parallèle à une pluralité d'appareils (10) de l'utilisateur à authentifier les jetons générés ; - un module (31) de réception/réponse d'au moins un des appareils utilisateur (30) reçoit (57) le jeton qui lui est destiné, modifie (58) le jeton et le renvoie au serveur central (20) ; - le serveur central (20) reçoit (59) le jeton modifié ; - le module d'authentification (24) du serveur central (20) valide (61) l'authentification et transmet cette validation au système applicatif (10) demandeur.

Description

DOMAINE TECHNIQUE DE L'INVENTION [0001] La présente invention concerne un système d’authentification sans mot de passe d’un utilisateur d’un système applicatif par un serveur central. Elle concerne également un procédé d’authentification sans mot de passe d’un utilisateur d’un système applicatif par un serveur central.
ETAT DE LA TECHNIQUE ANTERIEURE [0002] De façon classique, lorsqu’un utilisateur souhaite se connecter à un système applicatif, il doit avant tout procéder à une phase d’authentification. Cette phase permet de s’assurer que l’utilisateur qui demande l’identification est bien le véritable utilisateur. Cet aspect est d’autant plus important si le système applicatif comporte des données personnelles et/ou confidentielles concernant cet utilisateur. Très souvent, le processus d’authentification consiste à entrer des données d’identifiant unique et de mot de passe. Ce mode d’authentification est très largement répandu, pour des milliers de systèmes applicatifs de toutes sortes. De nombreux utilisateurs disposent de comptent ou d’accès à un grand nombre de systèmes applicatifs. La gestion des données d’identifiants et de mot de passe multiples est un problème récurent, qui n’a à ce jour pas trouvé de solution véritablement satisfaisante.
[0003]On observe également qu’une grande proportion de ces systèmes applicatifs prévoient des outils simples pour permettre aux utilisateurs ayant oublié des données de mot de passe et/ou d’identifiant unique de récupérer ces données par simple envoi d’un courriel par le système applicatif. Par exemple, si un utilisateur oublie son mot de passe, il fournit les données de son adresse courriel, ou numéro de téléphone, ou autre. Le système applicatif envoie ensuite à l’utilisateur un courriel, sms, ou autre type de message, comportant les données demandées, comme par exemple le mot de passe. D’autres systèmes applicatifs envoient un courriel proposant un lien qui permet à son tour de créer un nouveau mot de passe. Dans tous ces cas, on part du principe que l’envoi des données permettant une
Auverc-log-fr authentification en utilisant une adresse préalablement connue de courriel, numéro de téléphone, adresse postale, adresse IP, ou autre, comporte un niveau de sécurisation satisfaisant pour l’utilisateur en regard du système applicatif concerné.
[0004]Certains systèmes prévoient l’utilisation de hardware, tel qu’une carte à puce, pour permettre une authentification à sécurisation renforcée. Ces systèmes ajoutent des niveaux de complexité qui ont pour effet de décourager certains utilisateurs.
[0005] L’utilisation d’un mode d’authentification unique pour un utilisateur donné peut susciter certains inconvénients pratiques. En outre, le mode de transmission concerné (courriel, sms, etc) peut être temporairement hors service ou inaccessible pour l’utilisateur, rendant l’authentification impossible.
[0006] II persiste donc un besoin de longue date permettant de simplifier, fiabiliser, et pérenniser les outils d’authentification.
[0007]On connaît par ailleurs certains outils conçus dans le but de tenter de répondre à cette problématique.
[0008]Par exemple, le document FR3015824 décrit un procédé de gestion de données de connexion à un équipement via un réseau, le procédé comprenant une étape de réception, par un serveur de référencement, en provenance dudit équipement, de données de connexion audit équipement et d'au moins un jeton d'authentification généré à partir d'au moins un identifiant affecté audit équipement et à partir d'au moins une donnée d'authentification d'un utilisateur dudit équipement, une étape de référencement dudit équipement par le serveur de référencement par stockage des données de connexion reçues en association avec au moins d'une clé de référencement comprenant ledit au moins un jeton d'authentification, une étape de réception par le serveur, en provenance d'un terminal, d'au moins une requête d'obtention de données de connexion comprenant une clé de référencement, une étape de transmission audit terminal des données de connexion stockées en association avec la clé de référencement reçue. Ce procédé permet en outre de faciliter la connexion entre deux équipements dont un pour lequel l’adresse IP est variable.
Auverc-log-fr [0009] Le document FR 2940727 décrit un procédé destiné à authentifier un utilisateur du réseau Internet sur une machine offrant un service basé sur le protocole HTTP ou HTTPS, sans contraindre l'utilisateur à se souvenir d'un mot de passe, en vue d'ouvrir une session identifiée de manière unique sur le serveur. Dans un premier temps, lors de sa première demande d'enregistrement, l'utilisateur fournit son adresse de courrier électronique. Il est alors enregistré dans la base de comptes temporaires et reçoit un courriel contenant un lien hypertexte lui permettant de s'enregistrer définitivement dans la base de comptes. Ce courriel contient également un lien permettant à l'utilisateur de se connecter ultérieurement, une fois enregistré. Dans un second temps, l'utilisateur 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 lien de connexion pour se connecter, jusqu'à expiration de la validité de celui-ci ou jusqu'à sa déconnexion volontaire du site internet. Au delà de cette période ou après sa déconnexion, l'utilisateur devra recevoir un nouveau courriel de connexion. Ces courriels constituent des tickets de connexion permettant d'envoyer une requête de contrôle de l'appartenance de l'utilisateur à la base de compte. Ce procédé d'authentification est destiné à tous les sites internet possédant une base de comptes utilisateurs. Ce procédé présente cependant peu de souplesse du fait du l’utilisation obligatoire du courriel pour procéder à une connexion.
[0010]W02015047555A1 décrit un procédé et un système pour authentifier automatiquement un compte d'utilisateur en utilisant plusieurs services. Selon certains modes de réalisation de l'objet divulgué, les méthodes d'authentification d'un utilisateur à l'aide de multiples services sont fournis, les méthodes comprenant: la réception, à partir d'un dispositif client, de premières informations d'identification pour un compte de service cible; authentifier le compte de service cible sur la base des premières informations d'identification; émission d'une requête de redirection qui dirige le dispositif client à au moins un service de répondant, en réponse à l'authentification du compte de service cible; recevoir une réponse de répondant indiquant que le dispositif client a authentifié un compte de service de répondant avec au moins un service de répondant, dans lequel la réponse de répondant comprend un jeton de répondant; et fournir au dispositif client d'accéder au compte
Auverc-log-fr de service cible en réponse à la détermination que le compte de service de répondant est associé au compte de service cible. Ce procédé est complexe à mettre en œuvre et présente peu de souplesse opérationnelle.
[0011] D’autres procédés impliquent l’usage de moyens techniques spécifiques. Par exemple, le document WO 2008/060725 prévoit l’utilisation d’un lecteur biométrique, prévu pour identifier un utilisateur. Ce type de système est peu pratique du fait qu’il requiert un matériel très spécifique, convenablement paramétré. Les systèmes applicatifs existants doivent donc être équipés avant de pouvoir être considérés pour une mise en œuvre du procédé.
[0012]Pour pallier ces différents inconvénients, l’invention prévoit différents moyens techniques.
EXPOSE DE L'INVENTION [0013] Tout d’abord, un premier objet de l’invention consiste à prévoir un système et un procédé d’authentification permettant à l’utilisateur de se connecter à un système applicatif sans devoir mémoriser ni même utiliser un mot de passe.
[0014]Un autre objet de l’invention consiste à prévoir un système et un procédé d’authentification qui assure une mise en œuvre rapide et fiable, peu importe le contexte de disponibilité de l’utilisateur et/ou des réseaux de communication utilisés.
[0015]Encore un autre objet de l’invention consiste à prévoir un système et un procédé d'authentification faciles et simples à mettre en place et à utiliser, sans devoir installer d’équipement spécifiques chez les utilisateurs.
[0016]Encore un autre objet de l’invention consiste à prévoir un système et un procédé d’authentification permettant d’atteindre un niveau de sécurité satisfaisant pour l’utilisateur et le service applicatif.
Auverc-log-fr [0017]Pour ce faire, l’invention prévoit un procédé d’authentification d’un utilisateur d’un système applicatif par un serveur central, comprenant les étapes dans lesquelles :
un système applicatif effectue une demande d'authentification d'un utilisateur auprès d’un serveur central ;
le serveur central reçoit la demande d’authentification du système applicatif; le serveur central prend en compte les données requises du système applicatif et les données d’identifiant utilisateur ;
le serveur central prend en compte les données d’une pluralité de modes d'authentification mis en place pour cet utilisateur ;
le serveur central génère un jeton à durée limitée pour chaque mode d'authentification ;
le serveur central envoie sensiblement simultanément à une pluralité d’appareils utilisateur de l’utilisateur à authentifier les jetons générés, soit un jeton pour chacun des modes d'authentification ;
un module de réception/réponse d’au moins un des appareils utilisateur reçoit le jeton qui lui est destiné ;
sur réception d’une commande utilisateur, le module de réception/réponse ayant reçu ledit jeton modifie le jeton et le renvoie au serveur central ;
le serveur central reçoit le jeton modifié ;
le module d’authentification du serveur central valide l’authentification et transmet cette validation au système applicatif demandeur.
[0018]Par « sensiblement simultané », on entend à l’intérieur d’un intervalle de temps très court, comme par exemple inférieur ou égal à quelques dixièmes de secondes entre le premier et le dernier envoi, ou jusqu’à quelques secondes, par exemples 5 ou 10 secondes entre le premier et le dernier envoi.
[0019]Le procédé permet à un utilisateur de se connecter à un système applicatif sans la contrainte habituelle de devoir se souvenir d’un mot de passe en vue de fournir ce dernier pour permettre l’authentification. Le procédé permet également d’effectuer l’authentification automatiquement et très rapidement. En effet, si les modes d’authentification de l’utilisateur sont bien renseignés, le procédé permet à l’utilisateur d’avoir un maximum d’assurance qu’au moins un mode d’authentification
Auverc-Iog-fr sera disponible et saura lui convenir au moment de l’authentification. Le premier jeton utilisé permettra de valider l’authentification. Les autres jetons seront désactivés. En pratique, l’utilisateur renseigne au moins un mode d’authentification qu’il utilise fréquemment et pour lequel il reçoit les données facilement et rapidement. En cas d’indisponibilité, il peut alors recourir à l’un ou l’autre des autres modes prévus.
[0020]Selon un mode de réalisation avantageux, après réception d’un jeton modifié par un appareil utilisateur, le module d’authentification serveur central désactive les jetons envoyés en parallèle qui sont encore actifs.
[0021]L’envoi simultané permet à l’utilisateur d’avoir un choix. Le premier mode d’authentification qu’il choisi sera accepté, permettra l’authentification, et les autres modes, non utilisés, seront aussitôt désactivés.
[0022]Selon un autre mode de réalisation avantageux, avant l’étape de validation de l’authentification par le module d’authentification du système applicatif, un module de sécurisation du serveur central envoie au système applicatif une donnée de changement de statut d’un jeton.
[0023]Dans ce dernier cas, un module d’authentification du système applicatif demande en retour au module de sécurisation du serveur central les données correspondant au changement de statut.
[0024]De manière avantageuse, le module de sécurisation du serveur central envoie au système applicatif les détails de l'authentification. Cette approche permet de sécuriser d’avantage le procédé, pour éviter qu’un tiers ne puisse intervenir avant la fin du processus.
[0025]Selon encore un mode de réalisation avantageux, avant l’étape de génération de jeton, un module de vérification des modes d’authentification disponibles du serveur central effectue une vérification des modes d'authentification disponibles.
[0026]Cette étape permet d’optimiser le processus en évitant l’utilisation de modes
Auverc-log-fr d’authentification qui ne seraient pas disponibles à un instant donné.
[0027]L’invention prévoit également un système d’authentification d’un utilisateur d’un système applicatif par un serveur central, ledit système étant constitué par :
-un serveur central, comprenant :
-un module de sélection de modes d’authentification, pour mettre en place une pluralité de modes d’authentification pour chacun des utilisateurs ;
-un module de génération de jetons, permettant de générer un jeton pour chacun des modes d’authentification mis en place qui seront effectivement utilisés pour effectuer une authentification ;
-un module d’envoi sensiblement simultané de jetons pour au moins une partie des modes d’authentification préalablement mis en place, permettant d’envoyer les jetons générés par le module de génération de jetons vers chacun des modes d’authentification retenus;
-un module d’authentification, permettant de surveiller une réponse éventuelle d’un appareil utilisateur, selon un des modes d’authentification utilisés ;
-une pluralité de modules mémoire, pour mémoriser les données des utilisateurs, des modes d’authentification, des jetons, et les modes d’authentification ;
-une pluralité de systèmes applicatifs, chacun d’entre eux comprenant :
-un module de sélection de modes d’authentification, permettant de mettre en place une pluralité de modes d’authentification pour chacun des utilisateurs ;
-un module de demande d’authentification, permettant de demander au serveur central d’authentifier un utilisateur du système applicatif :
-un module d’authentification, permettant au système applicatif de valider l’authentification de l’utilisateur ;
-au moins un module mémoire pour mémoriser les données de modes d’authentification des utilisateurs du système et des données utilisateur authentifiés ;
-au moins deux appareils utilisateurs comportant chacun un module de réception et envoi de réponse jeton.
[0028]De manière avantageuse, le serveur central comprend par ailleurs un module de sécurisation, permettant au système applicatif de dialoguer avec le serveur
Auverc-log-fr central afin de générer par étapes la validation de l’authentification de l’utilisateur au niveau du système applicatif.
[0029]Ce module permet de renforcer la sécurisation du système, par exemple pour éviter qu’un tiers puisse recevoir les données d’authentification.
[0030]Selon un mode de réalisation avantageux, le serveur central comprend un module de vérification des modes d’authentification disponibles, permettant de vérifier la disponibilité des modes d’authentification associés à un utilisateur avant de transmettre un jeton par l’entremise de ce mode.
[0031]Ce module permet d’effectuer des envois uniquement par les modes disponibles au moment où une authentification doit être mise en oeuvre.
DESCRIPTION DES FIGURES [0032]Tous les détails de réalisation sont donnés dans la description qui suit, complétée par les figures 1 et 2, présentées uniquement à des fins d’exemples non limitatifs, et dans lesquelles:
-la figure 1 présente un organigramme fonctionnel présentant les principales étapes du procédé de sécurisation d’échanges de données conforme à l’invention;
-la figure 2 montre de façon schématique un exemple de système d’authentification selon l’invention.
DESCRIPTION DETAILLEE DE L’INVENTION
Système d’authentification [0033]La figure 2 est une représentation schématique d’un exemple de système d’authentification 1 d’un utilisateur d’un système applicatif 10 par l’entremise d’un serveur central 20.
Auverc-log-fr [0034] Le système est réparti entre les différents éléments d’équipement requis pour effectuer sa mise en œuvre. Une exemple de répartition est présenté à la figure 2 et sera décrit dans ce qui suit. D’autres modes de répartition des modules sont aussi possibles sans sortir du cadre de l’invention.
[0035]Le système comprend en outre trois éléments principaux, à savoir un serveur central 20, dédié principalement à la mise en œuvre des authentifications, au moins un et de préférence une pluralité de systèmes applicatifs 10, tels que des serveurs bancaires, d’achats ou de prestations diverses, etc, auxquels un grand nombres d’utilisateurs, associés et donc connus par les systèmes applicatifs, peuvent se connecter. Le système comprend enfin une pluralité d’appareil utilisateurs 30, que les utilisateurs utilisent pour effectuer diverses opérations à l’aide des systèmes applicatifs 10, après qu’une authentification a été opérée avec succès.
[0036]Chacun des systèmes applicatifs 10, en plus des modules spécifiquement dédiés aux types d’opérations et fonctionnalités qui sont spécifiques à chaque système, comprend une pluralité de modules concernant l’authentification, comme suit.
[0037]Chaque système applicatif 10 dispose d’une base 16 de données d’utilisateurs, comportant des identifiants uniques pour chacun d’entre eux. Pour procéder à l’authentification, une pluralité de moyens d’authentifications doivent être associés à chacun des utilisateurs. Ces données sont avantageusement comprises dans une base de modes d’authentification (28b) prévue au niveau du serveur central. En variante, une base 15 (en traits pointillés) peut être prévue au niveau du système applicatif. En pratique, certains systèmes applicatifs peuvent comprendre une base 15 tandis que d’autres n’en possèdent pas. La base 28b centralisée permet de bénéficier des données d’authentification des utilisateurs qui utilisent plusieurs systèmes applicatifs.
[0038] Ces données sont obtenues une fois lorsqu’un utilisateur s’inscrit ou ouvre un compte auprès d’un système applicatif. Un module 11 (en traits pointillés) de sélection de modes d’authentification permet de mettre en place ces données.
Auverc-Iog-fr
Comme dans le cas de la base 15, un module 21 de sélection des modes d’authentification peut lui aussi se trouver au niveau du serveur. Des données correspondant aux modes préférentiels d’authentification de chacun des utilisateurs sont avantageusement prévues dans la base d’authentification. Ces données sont obtenues au moment de l’inscription ou de l’ouverture du compte, et peuvent préférentiellement être mises à jour par la suite.
[0039] Lorsqu’une authentification doit être lancée, un module 12 de demande d’authentification permet de demander au serveur central 20 d’authentifier un utilisateur du système applicatif concerné par la demande.
[0040]Un module 13 d’authentification permet au système applicatif de valider l’authentification de l’utilisateur.
[0041]Dans l’exemple de réalisation de la figure 2, le serveur central 20 comprend des modules mémoire permettant de mémoriser les données des utilisateurs 28a, celles concernant les modes d’authentification 28b de ces utilisateurs, et les données de jetons 28c, qui permettront la mise en oeuvre du procédé, tel que décrit plus loin.
[0042]Comme préalablement décrit, le serveur comprend également un module 21 de sélection de modes d’authentification, pour mettre en place une pluralité de modes d’authentification pour chacun des utilisateurs. Les modes préférentiels de l’utilisateur peuvent être indiqués. A noter que dans l’architecture proposée à la figure 2, le serveur central et le système applicatif comprennent chacun un module de sélection des modes d’authentification. Diverses configurations sont possibles, en prévoyant par exemple un seul module à l’un de deux emplacements. L’emplacement du serveur permet de centraliser les fonctions et confère de ce fait une mise en œuvre plus simple.
[0043]Un module 22 de génération de jetons est sollicité lorsqu’une authentification doit être effectuée : ce module permet alors de générer un jeton pour chacun des modes d’authentification mis en place qui seront effectivement utilisés pour effectuer une authentification.
Auverc-log-fr [0044]Une des particularités du système consiste à prévoir un envoi simultané ou quasi-simultané d’une pluralité de jetons d’authentification pour des modes d’authentification distincts. Pour cette mise en oeuvre, un module 23 d’envoi sensiblement simultané de jetons pour au moins une partie des modes d’authentification préalablement mis en place est prévu. Ce module permet d’envoyer les jetons générés par le module 22 de génération de jetons vers chacun des modes d’authentification retenus.
[0045]Afin de surveiller l’arrivée en retour d’un des jetons envoyés, un module 24 d’authentification, permet de surveiller une réponse éventuelle d’un appareil utilisateur, selon un des modes d’authentification utilisés. Ce même module permet de désactiver les jetons qui ne sont pas utilisés. Les jetons étant de durée limitée, ce module désactive les jetons une fois la durée prévue écoulée. Cette durée est avantageusement très courte, à des fins de sécurité, comme par exemple quelques secondes ou minutes. A titre d’exemple, la durée peut se situer entre 10s et 30s ou entre 30s et 90s, ou plus.
[0046]Le serveur central 20 comprend par ailleurs un module 26 de sécurisation. Ce module est prévu afin que le système applicatif 10 puisse échanger des données intermédiaires avec le serveur central 20 afin de générer par étapes la validation de l’authentification de l’utilisateur au niveau du système applicatif.
[0047]Enfin, dans l’exemple illustré, le serveur central 20 comprend un module 25 de vérification des modes d’authentification disponibles, permettant de vérifier la disponibilité des modes d’authentification associés à un utilisateur avant de transmettre un jeton pour ce mode.
[0048]Chaque utilisateur dispose de préférence d’au moins deux appareils utilisateurs 30 comportant chacun un module 31 de réception et envoi de réponse jeton 31. Ce module est conçu pour recevoir les jetons 31 de demande d’authentification générés par le module de génération 22 de jetons sur serveur central 20, et pour retourner ce jeton transformé au serveur central, en confirmation d’acceptation de l’authentification.
Auverc-log-fr [0049] Les échanges entre les éléments du système d’authentification sont effectués de façon connue en soit, par exemple par réseau filaire ou non. La figure 2 illustre un exemple où un réseau 40 tel qu’internet ou un réseau téléphonique est utilisé.
[0050]Chacun des éléments du système d’authentification dispose d’une unité de calcul tel qu’un microprocesseur 14, 27 et 32 avec des instructions, une mémoire de travail et un module de communication (non montré) permettant les échanges de données entre les modules.
[0051]Selon le mode de réalisation prévu, les jetons peuvent prendre diverses formes et/ou formats. Dans un mode de réalisation préférentiel, les jetons sont des nombres aléatoires.
[0052]La mise en oeuvre des différents modules préalablement décrits des trois constituants du système d’authentification (par exemple les modules 11, 12 et 13 du système applicatif, les modules 21 à 27 du serveur central et le module 31 des appareils utilisateurs) est avantageusement réalisée au moyen d’instructions de mise en oeuvre, permettant aux modules d’effectuer la ou les opérations spécifiquement prévues pour le module concerné. Les instructions peuvent être sous la forme d’un ou plusieurs logiciels ou modules de logiciels mis en oeuvre par un ou plusieurs microprocesseurs. Le ou les modules et/ou le ou les logiciels sont avantageusement prévus dans un produit programme d’ordinateur comprenant un support d’enregistrement ou medium d’enregistrement utilisable par un ordinateur et comportant un code programmé lisible par un ordinateur intégré dans ledit support ou medium, permettant à un logiciel applicatif son exécution sur un ordinateur ou autre dispositif comportant un microprocesseur tel qu’un ordinateur, une tablette, un téléphone de type « smartphone », ou autre.
Procédé d’authentification [0053]La figure 1 est un organigramme fonctionnel illustrant les principales étapes du procédé d’authentification. Ce procédé permet d’effectuer l’authentification d’un
Auverc-log-fr utilisateur d’un système applicatif 10 par un serveur central 20. La première étape 50, concerne une demande d’authentification d’un utilisateur effectuée par un système applicatif 10 auprès d’un serveur central 20.
[0054]A l’étape 51, le serveur central reçoit la demande d’authentification du système applicatif 10. A l’étape 52, le serveur central 20 prend en compte les données requises du système applicatif 10, et les données 28a d’identifiant utilisateur (par exemple pour quel système applicatif le serveur doit-il authentifier ? Et de quel utilisateur s’agit-il ?).
[0055]A l’étape 53, le serveur central prend en compte les données 15 des modes d'authentification mis en place pour cet utilisateur. Ensuite, à l’étape 55, le serveur central génère un jeton à durée limitée pour chaque mode d'authentification.
[0056]A l’étape 56, le serveur central envoie sensiblement simultanément à une pluralité d’appareils utilisateur 10 de l’utilisateur à authentifier les jetons générés. II y a donc un jeton pour chacun des modes d'authentification utilisés.
[0057]Au niveau de l’appareil utilisateur 30, un module 31 de réception/réponse reçoit le jeton qui lui est destiné, à l’étape 57. L’utilisateur interagit avec son appareil pour entrer une commande de validation de l’authentification. Sur réception de cette commande utilisateur, le module 31 de réception/réponse ayant reçu ledit jeton modifie le jeton et le renvoie au serveur central (étape 58).
[0058]A l’étape 59, le serveur central reçoit le jeton modifié. Le module d’authentification 24 du serveur central 20 valide l’authentification et transmet cette validation au système applicatif 10 qui a adressé la demande (étape 61).
[0059] Pour éviter que des jetons devenus inutiles perdurent après l’utilisation d’un premier jeton, l’étape 60 prévoit qu’après réception d’un jeton modifié par un appareil utilisateur, le module d’authentification 24 du serveur central désactive les jetons envoyés en parallèle qui sont encore actifs.
Auverc-log-fr [0060]Afin d’augmenter la sécurité du processus, avant l’étape de validation 61 de l’authentification par le module d’authentification 13 du système applicatif 10, un module de sécurisation 26 du serveur central 20 envoie au système applicatif 10 une donnée de changement de statut d’un jeton (étape 63). Suite à cela, le module d’authentification 13 du système applicatif demande en retour (étape 64) au module de sécurisation 26 du serveur central les données correspondant au changement de statut. En réponse à cette requête, le module de sécurisation 26 du serveur central envoie au système applicatif les détails de l'authentification (étape 65).
[0061]Avant l’étape 55 de génération de jeton, un module de vérification 25 des modes d’authentification disponibles du serveur central effectue une vérification des modes d'authentification 28b disponibles. Cette étape 54 est optionnelle.
[0062]Les Figures et leurs descriptions faites ci-dessus illustrent l'invention plutôt qu'elles ne la limitent. En particulier, l'invention et ses différentes variantes viennent d'être décrites en relation avec un exemple particulier comportant une architecture dans laquelle les éléments clés sont prévus au niveau du serveur central.
[0063] Néanmoins, il est évident pour un homme du métier que l'invention peut être étendue à d’autres modes de réalisation dans lesquels en variantes, on prévoit que certains modules sont agencés à un autre endroit. Par exemple, le module 21 de sélection des modes d’authentification peut être agencé au niveau d’un système applicatif.
[0064]Encore selon une autre variante, certains modules sont intégrés ou joints, bien que le mode de fonctionnement du procédé reste similaire à celui préalablement décrit.
Auverc-log-fr

Claims (9)

  1. REVENDICATIONS
    1. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20), comprenant les étapes dans lesquelles :
    un système applicatif (10) effectue (50) une demande d'authentification d'un utilisateur auprès d’un serveur (20) central ;
    le serveur (20) central reçoit (51) la demande d’authentification du système applicatif (10) ;
    le serveur central (20) prend en compte (52) les données requises du système applicatif (10) et les données (28a) d’identifiant utilisateur ;
    le serveur central (20) prend en compte (53) les données (15) des modes d'authentification mis en place pour cet utilisateur ;
    Le serveur central (20) génère (55) un jeton à durée limitée pour chaque mode d'authentification ;
    le serveur central (20) envoie (56) sensiblement simultanément à une pluralité d’appareils utilisateur (10) de l’utilisateur à authentifier les jetons générés, soit un jeton pour chacun des modes d'authentification ;
    un module (31) de réception/réponse d’au moins un des appareils utilisateur (30) reçoit (57) le jeton qui lui est destiné ;
    sur réception d’une commande utilisateur, le module (31) de réception/réponse ayant reçu ledit jeton modifie (58) le jeton et le renvoie au serveur central (20) ;
    le serveur central (20) reçoit (59) le jeton modifié ;
    le module d’authentification (24) du serveur central (20) valide (61) l’authentification et transmet cette validation au système applicatif (10) demandeur.
  2. 2. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20) selon la revendication 1, dans lequel, après réception d’un jeton modifié par un appareil utilisateur, le module d’authentification (24) serveur central (20) désactive (60) les jetons envoyés en parallèle qui sont encore actifs.
  3. 3. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20) selon l’une des revendications 1 ou 2, dans lequel avant l’étape de validation (61) de l’authentification par le module d’authentification (13) du
    Auverc-log-fr système applicatif (10), un module de sécurisation (26) du serveur central (20) envoie (63) au système applicatif (10) une donnée de changement de statut d’un jeton.
  4. 4. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20) selon la revendication 3, dans lequel un module d’authentification (13) du système applicatif (10) demande en retour (64) au module de sécurisation (26) du serveur central (20) les données correspondant au changement de statut.
  5. 5. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20) selon la revendication 4, dans lequel le module de sécurisation (26) du serveur central (20) envoie (65) au système applicatif (10) les détails de l'authentification.
  6. 6. Procédé d’authentification d’un utilisateur d’un système applicatif (10) par un serveur central (20) selon l’une des revendications 1 à 5, dans lequel, avant l’étape (55) de génération de jeton, un module de vérification (25) des modes d’authentification disponibles du serveur central (20) effectue (54) une vérification des modes d'authentification (28b) disponibles.
  7. 7. Système d’authentification (1) d’un utilisateur d’un système applicatif (10) par un serveur central (20), ledit système étant constitué par :
    -un serveur central (20), comprenant :
    -un module (21) de sélection de modes d’authentification, pour mettre en place une pluralité de modes d’authentification pour chacun des utilisateurs ;
    -un module (22) de génération de jetons, permettant de générer un jeton pour chacun des modes d’authentification mis en place qui seront effectivement utilisés pour effectuer une authentification ;
    -un module (23) d’envoi sensiblement simultané de jetons pour au moins une partie des modes d’authentification préalablement mis en place, permettant d’envoyer les jetons générés par le module (22) de génération de jetons vers chacun des modes d’authentification retenus;
    Auverc-log-fr
    -un module (24) d’authentification, permettant de surveiller une réponse éventuelle d’un appareil utilisateur, selon un des modes d’authentification utilisés ;
    -une pluralité de modules mémoire (28a, 28b, 28c), pour mémoriser les données des utilisateurs (28a), des modes d’authentification (28b), des jetons (28c) ;
    -une pluralité de systèmes applicatifs (10), chacun d’entre eux comprenant :
    -un module (11) de sélection de modes d’authentification, permettant de mettre en place une pluralité de modes d’authentification pour chacun des utilisateurs ; -un module (12) de demande d’authentification, permettant de demander au serveur central d’authentifier un utilisateur du système applicatif :
    -un module (13) d’authentification, permettant au système applicatif de valider l’authentification de l’utilisateur ;
    -au moins un module mémoire, pour mémoriser les données (15) de modes d’authentification des utilisateurs du système et des données (16) utilisateur authentifiés.
    -au moins deux appareils utilisateurs (30) comportant chacun un module de réception et envoi de réponse jeton (31).
  8. 8. Système d’authentification (1) d’un utilisateur d’un système applicatif (10) selon la revendication 7, dans lequel le serveur central (20) comprend par ailleurs un module (26) de sécurisation, permettant au système applicatif (10) de dialoguer avec le serveur central (20) afin de générer par étapes la validation de l’authentification de l’utilisateur au niveau du système applicatif.
  9. 9. Système d’authentification (1) d’un utilisateur d’un système applicatif (10) selon l’une des revendications 7 ou 8, dans lequel le serveur central (20) comprend un module (25) de vérification des modes d’authentification disponibles, permettant de vérifier la disponibilité des modes d’authentification associés à un utilisateur avant de transmettre une jeton par l’entremise de ce mode.
    Auverc-log-fr
    50' r
    s/ r
    r
    1/2
    ·' Demande d'authentification d'un utilisateur par un système Réception de la demande d'authentification par le serveur Le serveur considère les données requises du système concerné, de l'identifiant de l'utilisateur et d'éventuelles données complémentaires i -- Le serveur considère les données des modes d'authentification prévus - Le serveur effectue une vérification des modes d'authentification disponibles . Le serveur génère un jeton à durée limitée pour chaque mode d'authentification „Envoi en parallèle des jetons à l'utilisateur, soit un jeton pour chacun des modes d'authentification
    Non réponse dans la durée du jeton : expiration de tous les jetons émis
    Z'
    Réception par le module de réception /réponse du jeton de l'utilisateur
    Après réception d'une commande utilisateur, envoi réponse par le module de réception /réponse du jeton de l'utilisateur par un -- des modes d'authentification
    58'
    Réception par le serveur du jeton modifié par le mode utilisé
    60'
    Désactivation par le serveur des autres modes d'authentification / ---.-.Le serveur envoie au système une alerte de changement de - statut d'un jeton
    63 -iLe système demande au serveur les données correspondant au f\_changement de statut
    64 t x—· Le serveur envoie au système les détails de l'authentification
    Le système valide l'authentification de l'utilisateur
FR1670443A 2016-08-09 2016-08-09 Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central Pending FR3055053A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1670443A FR3055053A1 (fr) 2016-08-09 2016-08-09 Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
PCT/IB2017/054589 WO2018029564A1 (fr) 2016-08-09 2017-07-27 Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1670443A FR3055053A1 (fr) 2016-08-09 2016-08-09 Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
FR1670443 2016-08-09

Publications (1)

Publication Number Publication Date
FR3055053A1 true FR3055053A1 (fr) 2018-02-16

Family

ID=57485811

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1670443A Pending FR3055053A1 (fr) 2016-08-09 2016-08-09 Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central

Country Status (2)

Country Link
FR (1) FR3055053A1 (fr)
WO (1) WO2018029564A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11050560B2 (en) 2019-09-27 2021-06-29 International Business Machines Corporation Secure reusable access tokens

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040054750A1 (en) * 2002-09-13 2004-03-18 Sun Microsystems, Inc., A Delaware Corporation System for digital content access control
US20150032625A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating risk using token assurance data
US20150249540A1 (en) * 2014-02-28 2015-09-03 Verizon Patent And Licensing Inc. Password-less authentication service

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886156B2 (en) 2006-09-18 2011-02-08 John Franco Franchi Secure universal transaction system
FR2940733A1 (fr) 2008-12-31 2010-07-02 Franck Michel Marchand W3s : web simple safety system.
WO2015047555A1 (fr) 2013-09-28 2015-04-02 Elias Athanasopoulos Procédés, systèmes et supports d'authentification d'utilisateurs employant des services multiples
FR3015824A1 (fr) 2013-12-23 2015-06-26 Orange Obtention de donnees de connexion a un equipement via un reseau

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040054750A1 (en) * 2002-09-13 2004-03-18 Sun Microsystems, Inc., A Delaware Corporation System for digital content access control
US20150032625A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating risk using token assurance data
US20150249540A1 (en) * 2014-02-28 2015-09-03 Verizon Patent And Licensing Inc. Password-less authentication service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WIKIPEDIA: "Challenge-response authentication - Wikipedia", 3 January 2016 (2016-01-03), pages 1 - 4, XP055333225, Retrieved from the Internet <URL:https://en.wikipedia.org/wiki/Challenge-response_authentication> [retrieved on 20170109] *

Also Published As

Publication number Publication date
WO2018029564A1 (fr) 2018-02-15

Similar Documents

Publication Publication Date Title
WO2013021107A9 (fr) Procede, serveur et systeme d&#39;authentification d&#39;une personne
FR2975855A1 (fr) Systeme et procede de securisation d&#39;echanges de donnees entre un module client et un module serveur
WO2020064890A1 (fr) Procede de traitement d&#39;une transaction, dispositif, systeme et programme correspondant
EP3568965B1 (fr) Procédé d&#39;authentification en deux étapes, dispositif et programme d&#39;ordinateur correspondant
WO2019092327A1 (fr) Procédé d&#39;obtention d&#39;une identité numérique de niveau de sécurité élevé
EP3262553B1 (fr) Procede de transaction sans support physique d&#39;un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
FR3055053A1 (fr) Systeme et procede d&#39;authentification sans mot de passe d&#39;un utilisateur d&#39;un systeme applicatif par un serveur central
EP3588418A1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d ordinateur correspondant
EP3729307A1 (fr) Procédés et dispositifs pour l&#39;enrôlement et l&#39;authentification d&#39;un utilisateur auprès d&#39;un service
EP2529330B1 (fr) Procédé de fourniture d&#39;un code dynamique par l&#39;intermédiaire d&#39;un téléphone
FR3090259A1 (fr) Procédé et système d’authentification d’un terminal client par un serveur cible, par triangulation via un serveur d’authentification.
EP3371760A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
EP3395042B1 (fr) Serveur d&#39;authentification pour le contrôle d&#39;accès a un service
EP4241190A1 (fr) Procede d&#39;authentification securise par le decouplage structurel des identifiants personnels et de services
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
FR3143143A1 (fr) Procédé de connexion à un compte personnel sur un service en ligne au moyen d’une chaîne de blocs
FR3044789A1 (fr) Procede d&#39;autorisation d&#39;une transaction
EP4348459A1 (fr) Procédé de traitement d&#39;une transaction, dispositif et programme correspondant
FR3081246A1 (fr) Procede de realisation d&#39;une transaction, terminal, serveur et programme d&#39;ordinateur correspondant
WO2022214768A1 (fr) Méthode de contrôle d&#39;accès à un bien ou service distribué par un réseau de communication de données
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
EP3394780A1 (fr) Procede et dispositif de connexion a un serveur distant
FR3060172A1 (fr) Procede de transaction relative a un vehicule .
FR2825213A1 (fr) Systeme d&#39;authentification d&#39;un utilisateur
FR3038998A1 (fr) Procede relatif a la transaction d’un vehicule.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180216