Difference between revisions of "VT2018 FIDO"

From air
Jump to navigation Jump to search
Line 38: Line 38:
 
=== Cérémonie d'authentification ===
 
=== Cérémonie d'authentification ===
 
[[File:CEREMONIE1.png|970px|CEREMONIE AUTHENTIFICATION]]
 
[[File:CEREMONIE1.png|970px|CEREMONIE AUTHENTIFICATION]]
  +
  +
Quand le serveur reçoit une demande d'authentification, il génère un challenge qu'il envoie au navigateur puis à la clé de sécurité. La clé de sécurité le signe et renvoie sa réponse au serveur. Le scénario basique d'authentification est très simple. Mais tel quel il présente beaucoup de failles de sécurité.
  +
C'est pourquoi d'autres couches de sécurité ont été ajoutées. Tout d'abord pour contrer les attaques de type phishing, on ajoute le champs "Origin". Il est utilisé de la même façon que pour la cérémonie d'enregistrement.
  +
Ensuite, si ma clé de sécurité ne générait qu'une seule paire de clé et qu'elle l'utilisait sur tous les sit
  +
es alors il serait possible de traquer mon activité. Donc on impose la génération d'une paire de clé pour tous les services. Le gestionnaire de clé permet ensuite de retrouver la clé privé avec laquelle signer le challenge.
  +
Il est également possible que ma clé de sécurité se fasse cloner. Dans ce cas, 2 clé identiques circulent. on met en place un compteur. A chaque fois que je signe j'incrémente ce compteur et j'informe le serveur de la valeur du compteur. Le serveur sauvegarde également cette valeur. Si 2 clés circulent, l'une d'entre elle va se retrouver dans le "passé". En voyant une baisse de la valeur du compteur le serveur sait qu'il existe 2 clés. En revanche il est incapable de les différencier. La plupart des providers, ferment les comptes associés à des clés clonées ou bien forcent le retour à une authentification classique.
   
 
== Résultats ==
 
== Résultats ==

Revision as of 13:45, 14 January 2019

Auteur

  • Nom : Najwa EZ-ZINE
  • Sujet : FiDO

Résumé

À l'heure actuelle, les experts en sécurité doivent faire face à un dilemme : renforcer la sécurité ou améliorer l'expérience utilisateur. C'est avec pour but de mettre fin à ce dilemme que les poids lourds du secteur informatique se sont alliés, formant la Fido Alliance. Pour produire une solution alliant renforcement de la sécurité et amélioration de l'expérience utilisateur.

Abstract

Currently, experts in cybersecurity are facing a dilemma : strenghtening security or improving the overall user experience. With a strong will to put an end to this dilemma the biggest companies in the world joined forces forming the FIDO Alliance. To produce a solution to both problems, strenghtening security and user experience.

Synthèse

Après 4 ans de travail est né le protocole U2F. Principalement développé par Yubico et Google, il décrit l'utilisation d'une clé de sécurité pour l'authentification.

Introduction U2f

L'idée principale est d'utiliser du hardware pour s'authentifier, une clé USB par exemple. La clé USB présente plusieurs avantages. Tout d'abord elle est complètement séparée de l'outil permettant l'accès au service. Ce qui rajoute une couche de protection, une étape de plus à franchir pour accéder aux données pour une personne mal intentionnée. La clé est aussi très simple d'utilisation. Il suffit en effet simplement d'appuyer sur un bouton pour établir la connexion.

Fonctionnement

La clé repose sur de la cryptographie asymétrique, c'est-à-dire une paire de clé privé et publique. Il y a 2 modes principaux d'utilisation de la clé. On appelle ces modes : cérémonies. Tout d'abord, quand je souhaite utiliser ma clé pour la première fois, je dois l'enregistrer au sein de ce service. Il s'agit de la cérémonie d'enregistrement. Le second mode, est l'authentification. Quand je souhaite m'authentifier en utilisant ma clé, j'enclenche la cérémonie d'authentification.

Cérémonie d'enregistrement

CEREMONIE ENREGISTREMENT

Quand je souhaite enregistrer une clé, le serveur enclenche la cérémonie d'enregistrement. Il génère un challenge qu'il m'envoie avec l'identification de l'application AppId. Le navigateur transfère ces informations à la clé ainsi qu'un champs "Origin". Ce champ est en fait la résolution par le navigateur du nom de domaine d'où provient la requête. Cela permet de protéger l'utilisateur contre les attaques de type phishing. Avec toutes ces informations la clé génère une paire de clés publique et privé ainsi qu'un gestionnaire de clés. Le gestionnaire de clé permet à la clé cde sécurité de retrouver la clé privé avec laquelle il doit signer le challenge. En effet, une paire de clé est générée pour chaque service. La clé de sécurité envoie ces informations (gestionnaire clé, origine,...) au navigateur qui les transfère au serveur. Le serveur vérifie les informations reçues (Origin en cas de phishing...) et enregistre cette clé publique avec le gestionnaire clé associé. La cérémonie d'enregistrement est terminée.

Cérémonie d'authentification

CEREMONIE AUTHENTIFICATION

Quand le serveur reçoit une demande d'authentification, il génère un challenge qu'il envoie au navigateur puis à la clé de sécurité. La clé de sécurité le signe et renvoie sa réponse au serveur. Le scénario basique d'authentification est très simple. Mais tel quel il présente beaucoup de failles de sécurité. C'est pourquoi d'autres couches de sécurité ont été ajoutées. Tout d'abord pour contrer les attaques de type phishing, on ajoute le champs "Origin". Il est utilisé de la même façon que pour la cérémonie d'enregistrement. Ensuite, si ma clé de sécurité ne générait qu'une seule paire de clé et qu'elle l'utilisait sur tous les sit es alors il serait possible de traquer mon activité. Donc on impose la génération d'une paire de clé pour tous les services. Le gestionnaire de clé permet ensuite de retrouver la clé privé avec laquelle signer le challenge. Il est également possible que ma clé de sécurité se fasse cloner. Dans ce cas, 2 clé identiques circulent. on met en place un compteur. A chaque fois que je signe j'incrémente ce compteur et j'informe le serveur de la valeur du compteur. Le serveur sauvegarde également cette valeur. Si 2 clés circulent, l'une d'entre elle va se retrouver dans le "passé". En voyant une baisse de la valeur du compteur le serveur sait qu'il existe 2 clés. En revanche il est incapable de les différencier. La plupart des providers, ferment les comptes associés à des clés clonées ou bien forcent le retour à une authentification classique.

Résultats

Le protocole U2F est un véritable succès:

  • il réduit de moitié le temps d'authentification.
  • Le nombre d'incident avec une utilisation de la clé U2f est de 2 à 2.5 fois moins important

Futur?

Le monde de demain sera un monde sans mot de passe. C'est en tout cas l'objectif ultime de la FiDO Alliance. Elle s'est d'ailleurs alliée avec WC pour produire une API permettant l'authentification à l'aide de la reconnaissance faciale, les empreintes digitales et autres.

Références

https://fidoalliance.org/

https://en.wikipedia.org/wiki/FIDO_Alliance

https://fr.wikipedia.org/wiki/Universal_Second_Factor

https://www.devopsdays.org/events/2018-seattle/program/jen-tong/

https://www.journaldugeek.com/2018/04/12/webauthn-futur-web-de-passe-se-rapproche/

https://www.yubico.com/