Yubikey – II – Comment ca fonctionne ?

Principe

Le but de ce petit article est d’expliquer le fonctionnement de ce que j’ai décrit dans l’article Yubikey – II – Le plugin WordPress.

La Yubikey génère un mot de passe unique (OTP), et notre site protégé (ici via le plugin WordPress) est capable de la reconnaître, nous identifier, et s’assurer que ce mot de passe n’a jamais été utilisé !

Voici le schéma du déroulement :

yubikey-sp1

L’utilisateur est au préalable identifié sur le serveur protégé, WordPress dans mon article, et sur le serveur de validation qui se trouve chez Yubico. C’est ce qui est appelé l’ID client qui correspond à un numéro d’identifiant. 25704 dans l’exemple que j’ai donné.

Lorsque je m’identifie sur mon site WordPress, j’ai entré mon login, mon mot de passe, puis j’appuie sur la pastille dorée de la Yubikey pour généré un mot de passe unique.
A cet instant, mon site WordPress pour m’identifier dispose des informations suivantes :

  • Mon login
  • Mon mot de passe
  • Mon OTP Yubikey

Il va commencer par vérifier le login et le mot de passe. S’ils sont corrects, il va rechercher l’ID client Yubico que j’ai associé à mon login WordPress. Pour rappel, c’est ce qui a été fait lors de l’étape de paramétrage du plugin Yubikey  :yubikey-plugwp-10Mon serveur WordPress va alors constituer une URL pour interroger le serveur de validation qui se trouve chez Yubico.
Cette URL a la forme suivante :

yubikey-sp2

  • URL de validation est l’URL du serveur Yubico : http://api.yubico.com/wsapi/verify
  • OTP est le mot de passe unique de la Yubikey : ccccccdjijefutnttfjinvbtvlkhnjvjrchleubkjujr par exemple, transmis par la variable OTP de l’URL
  • ID utilisateur est l’identifiant utilisateur : 25704 dans notre exemple, variable ID de l’URL
  • Chaine aléatoire est une chaine destinée à ajouter de l’aléa …. 😉 Variable NONCE de l’URL
  • La signature est calculée à l’aide de la phrase secrète connue par le serveur de validation et le serveur protégé : FjoQlaq12qnhoeyLO7ULW7VbjgE= dans l’exemple. Variable H de l’URL.

Le serveur WordPress va donc appeler le serveur de validation de Yubico par webservice avec une URL qui aurait cet aspect là avec nos exemples :

http://api.yubico.com/wsapi/verify?id=25704&nonce=hmjgdizcgfvxqrssnzrtllbjlayosbtz&otp=ccccccdjijefutnttfjinvbtvlkhnjvjrchleubkjujr&h=jetFYbTQ4Q5jVg3XZrrN73B8Fxo

Le serveur de validation traite et récupère ces variables. Il va faire notamment appel à un serveur de déchiffrement. Nous verrons cela dans un article ultérieur expliquant comment créer nos propres serveurs de validation.

Le serveur de validation affiche en résultat une page HTML, récupérée par le serveur protégé qui lui indique si l’OTP générée par la Yubikey est valable pour l’utilisateur identifié par ID. Pour cela sur une ligne  apparaître la mention status=OK

Si le serveur de validation à bien répondu (status=OK), alors le serveur protégé peux identifier l’utilisateur.

Le rôle de la signature

La signature n’est pas obligatoire dans le protocole proposé par Yubico. Elle n’a de sens que pour des communications qui sont non chiffrées, en hhtp, entre le serveur protégé et le serveur de validation.

L’objectif de la signature est de se prémunir contre une attaque du type ‘Man in the Middle’. Imaginons qu’il n’y ait pas de signature, sur le schéma suivant :

yubikey-sp3A l’étape 1, l’utilisateur génère à l’aide de sa Yubikey un OTP valide pour s’identifier. Un vilain intercepte la communication entre le serveur protégé et le serveur de validation. (Avec un code malicieux sur le serveur protégé par exemple). Il répond au serveur protégé à la place du serveur de validation, et lui indique que l’OTP est valide. L’utilisateur est alors identifié et ouvre sa session. Pour lui tout cela est transparent.

Maintenant, à l’étape 2, le vilain dispose d’un OTP qui n’a jamais été envoyé à un serveur de validation, et qui est donc valide. Il va l’utiliser pour s’identifier et ainsi avoir accès au système :

yubikey-sp4Le rôle de la signature est de se prémunir contre cela.

Le serveur protégé et de validation connaissent tous les deux la même phrase secrète pour l’utilisateur qui s’identifie.

yubikey-sp5Le serveur protégé calcule à l’aide de l’algorithme HMAC-SHA1 et de la phrase secrète la signature de l’URL qui va être expédiée. Cette signature est ajoutée à la fin de l’URL.

Le serveur de validation recalcule la signature pour s’assurer qu’elle est bien valide en la comparant avec la signature envoyée par le serveur protégé. Il procède ensuite à la vérification de l’OTP, puis dans sa réponse au serveur protégé, recalcule la signature de sa réponse toujours à l’aide de la phrase secrète.

Reste au serveur protégé à vérifier que la signature du serveur de validation est correcte en la recalculant. En procédant ainsi on se prémunit du risque d’interception de l’OTP.

Posts relatifs

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">