Les meilleurs mots de passe sont ceux qui ne quittent jamais votre appareil

Les mots de passe sont l'objet de préoccupations. Ils posent un problème car la plupart des personnes qui les utilisent ne les connaissent pas. Peu importe qu'un mot de passe soit complexe ou difficile à deviner, dès lors qu'il n'est plus en votre possession, il met la sécurité en péril.

La plupart des lecteurs reconnaîtront immédiatement que les mots de passe sont difficiles à mémoriser et à gérer, d'autant plus que les exigences en matière de mots de passe sont de plus en plus complexes. Par chance, il existe de formidables packs de logiciels et modules complémentaires de navigateur qui facilitent la gestion des mots de passe. Cependant, cela étonnera peut-être la plupart des lecteurs mais les problèmes sont bien plus profonds qu'on ne le croit généralement. La plupart tiennent au fait que les mots de passe sont par définition non sécurisés.

« Mais les mots de passe sont toujours conservés dans un format chiffré ! » répondrez-vous certainement. C'est vrai, mais uniquement dans une certaine mesure. En réalité, même un mot de passe chiffré peut être décodé ; certes, cela demande d'énormes efforts lorsqu'ils sont correctement chiffrés (et c'est heureux !). La nature même des mots de passe donne lieu à un problème de plus en plus préoccupant : l'utilisation d'un mot de passe implique une manipulation en texte clair de celui-ci.

Et là vous vous dites « mon mot de passe est transmis en toute sécurité via HTTPS ! » C'est vrai.

Vous vous dites également « mais je sais que le serveur conserve mon mot de passe sous une forme chiffrée et sécurisée, donc personne ne peut y accéder !» Et bien, c'est accorder une grande confiance au serveur. Quand bien même, admettons que ça aussi, c'est vrai.

Il reste toutefois un détail contre lequel il convient de mettre en garde : une faille dans le déroulement de bout en bout de l'utilisation des mots de passe. Sachez qu'une fois qu'un serveur reçoit un mot de passe, entre le moment où il est transmis de manière sécurisée et celui où il est stocké en toute sécurité, le mot de passe doit être lu et traité. Oui, sous forme de texte clair !

Et il y a pire : comme beaucoup sont habitués à penser à l'aspect logiciel, peu se soucient de la vulnérabilité du matériel. En effet, même si le logiciel est a priori fiable, il y a bien un moment où le mot de passe doit se trouver dans la mémoire. Le mot de passe doit à un moment donné être transmis à l'unité centrale par un bus partagé. C'est là que se trouvent les vecteurs d'attaques pour les indiscrets, quels qu'ils soient. Bien sûr, ces vecteurs d'attaque sont beaucoup moins probables qu'au moment de la transmission et du stockage permanent, mais ils n'en sont pas moins graves (les récentes vulnérabilités d'unité centrale telles que Spectre et Meltdown en sont un exemple peu réjouissant).

La seule façon de régler ce problème est de se débarrasser complètement des mots de passe. Il y a de l'espoir ! Les milieux de la recherche et du secteur privé travaillent d'arrache-pied pour y parvenir. De nouvelles normes sont en train de naître et de se perfectionner. Malheureusement, les mots de passe sont tellement omniprésents qu'il faudra beaucoup de temps pour parvenir à un accord concernant les nouvelles normes et technologies, les mots de passe ne seront donc pas remplacés avant un bon moment.

Chez Cloudflare, nous nous interrogeons sur la possibilité de faire quelque chose dès maintenant, sans attendre. L'immersion que nous faisons aujourd'hui dans OPAQUE apporte une réponse possible. OPAQUE est l'un des nombreux exemples de systèmes qui permettent d'utiliser un mot de passe en le gardant toujours pour vous. Personne n'aime les mots de passe, mais tant qu'ils sont utilisés, nous pouvons au moins vous garantir qu'ils ne seront jamais donnés.

Ce n'est pas moi qui vais vous dire le contraire, l'authentification par mots de passe est casse-pied : les mots de passe sont difficiles à mémoriser, fastidieux à saisir et, c'est bien connu, peu sécurisés. Les initiatives visant à réduire ou à remplacer les mots de passe sont prometteuses. Par exemple, WebAuthn est une norme d'authentification Web reposant essentiellement sur la cryptographie par clé publique à l'aide de jetons matériels (ou logiciels). Aussi frustrants les mots de passe soient-ils, on persiste à les utiliser comme mécanisme d'authentification. Que ce soit par facilité de mise en œuvre, en raison de leur familiarité chez les utilisateurs ou simplement parce qu'ils sont omniprésents sur le Web, nous les utilisons toujours et nous souhaitons rendre l'authentification par mot de passe aussi sécurisée que possible tant que nous y aurons recours.

Mon stage chez Cloudflare a eu pour sujet principal OPAQUE, un protocole cryptographique qui résout l'un des problèmes de sécurité les plus typiques de l'authentification par mot de passe : quand bien même les mots de passe sont généralement protégés pendant le transit par HTTPS, les serveurs les traitent en texte clair pour en vérifier l'exactitude. Le traitement des mots de passe en texte clair est dangereux, car en cas de consignation ou de mise en cache accidentelles, les défaillances potentielles sont catastrophiques pour le système de sécurité. L'objectif du projet, n'est pas tant de plaider pour l'adoption d'un protocole particulier que de montrer qu'OPAQUE est une option envisageable parmi d'autres pour l'authentification. Le cas du Web étant celui qui m'est le plus familier, et j'imagine que c'est le cas pour de nombreux lecteurs, j'utiliserai le Web comme principal exemple.

Lorsque vous saisissez un mot de passe dans le Web, que se passe-t-il ? Le site Web doit vérifier que le mot de passe que vous avez saisi est le même que celui que vous avez enregistré à l'origine sur le site. Mais comment procède-t-il à la vérification ?

En général, vos nom d'utilisateur et mot de passe sont envoyés à un serveur. Le serveur vérifie alors si le mot de passe enregistré associé à votre nom d'utilisateur correspond au mot de passe que vous avez fourni. Bien évidemment, pour éviter qu'un pirate à l'écoute de votre trafic Internet ne vole votre mot de passe, votre connexion au serveur doit être chiffrée via HTTPS (HTTP-over-TLS).

Même en ayant recours à HTTPS, il nous reste un problème manifeste : le serveur doit stocker une représentation de votre mot de passe quelque part. Les serveurs sont difficiles à sécuriser, et les violations sont trop fréquentes. La fuite de cette représentation peut entraîner des problèmes de sécurité catastrophiques. (Pour obtenir des informations sur les dernières violations, consultez https://haveibeenpwned.com/).

Pour atténuer les conséquences de ces fuites, les serveurs appliquent souvent une fonction de hachage aux mots de passe des utilisateurs. Une fonction de hachage associe chaque mot de passe à une valeur unique et aléatoire. Il est facile d'appliquer le hachage à un mot de passe, mais presque impossible d'inverser la fonction et de récupérer le mot de passe. (Cela dit, n'importe qui peut deviner un mot de passe, appliquer la fonction de hachage et vérifier si le résultat est le même.)

Avec le hachage, les mots de passe ne sont plus stockés en texte clair sur les serveurs.  Il ne suffit plus au pirate de voler une base de données de mots de passe pour accéder directement aux mots de passe. Au lieu de cela, le pirate doit désormais appliquer le hachage à de nombreux mots de passe potentiels et comparer les résultats aux mots de passe hachés ayant fuité.

Malheureusement, si un serveur se contente de hacher les mots de passe, les pirates ont la possibilité de télécharger des tables arc-en-ciel précalculées contenant des trillions de mots de passe possibles, qui leur permettront de récupérer presque instantanément les mots de passe en texte clair. (Consultez https://project-rainbowcrack.com/table.htm pour obtenir une liste de tables arc-en-ciel).

Dans cette optique, le salage constitue une bonne stratégie de défense en profondeur ; il s'agit d'un hachage au cours duquel le serveur hache votre mot de passe associé à une valeur aléatoire, propre à l'utilisateur, appelée le sel. Le serveur enregistre également le sel avec le nom d'utilisateur, de sorte que l'utilisateur ne le voit jamais ou n'a pas besoin de le soumettre. Lorsque l'utilisateur soumet un mot de passe, le serveur recalcule cette fonction de hachage à l'aide du sel. Un pirate qui vole les données du mot de passe, c'est-à-dire les représentations du mot de passe et les valeurs du sel, doit alors tenter de deviner des mots de passe à partir d'exemples courants, un par un, et appliquer la fonction de salage à chaque tentative de mot de passe. Les tables arc-en-ciel existantes ne lui seront d'aucune aide, car elles ne prennent pas en compte les sels. L'attaquant doit donc créer une nouvelle table arc-en-ciel pour chaque utilisateur !

Si tout se passe bien, cela ralentit suffisamment l'attaque pour que le service ait le temps d'informer les utilisateurs de la violation, afin qu'ils modifient leur mot de passe. De plus, il est recommandé de renforcer le salage en multipliant les occurrences de hachage pour ralentir plus encore les attaques. (Consultez https://blog.cloudflare.com/keeping-passwords-safe-by-staying-up-to-date/ pour une discussion plus détaillée à ce sujet).

Ces deux solutions d'atténuation (chiffrement du mot de passe en transit et stockage des salages et hachages renforcés) sont les pratiques recommandées actuellement.

Il reste une grande faille de sécurité à colmater. La méthode Mot de passe via TLS (comme nous l'appellerons) demande aux utilisateurs d'envoyer les mots de passes en texte clair aux serveurs à la connexion, car les serveurs doivent les voir pour vérifier qu'ils correspondent aux mots de passe enregistrés sur le fichier. Même un serveur bien intentionné peut accidentellement mettre en cache ou enregistrer vos tentatives de mot de passe, ou encore faire l'objet d'une corruption pendant la vérification des mots de passe. (Par exemple, Facebook a réalisé en 2019 qu'il avait accidentellement stocké des centaines de millions de mots de passe d'utilisateurs en texte clair). Dans l'idéal, les serveurs ne doivent jamais voir de mot de passe en clair.

Mais il s'agit là d'un véritable casse-tête : comment vérifier un mot de passe si vous ne le voyez jamais ? Passez à OPAQUE : un protocole d'échange de clé authentifié par mot de passe (PAKE) qui prouve de manière instantanée qu'un mot de passe est connu et en déduit une clé secrète. Avant de décrire OPAQUE en détail, nous allons commencer par passer en revue les fonctionnalités PAKE en général.

L'échange de clé authentifié par mot de passe (PAKE) a été proposé par Bellovin et Merrit[1] en 1992. L'objectif premier était alors de permettre l'authentification par mot de passe en excluant toute possibilité d'attaque par dictionnaire sur la base des données transmises via un canal non sécurisé.

Concrètement, un PAKE simple ou symétrique est un protocole cryptographique qui permet à deux parties qui n'ont en commun qu'un mot de passe d'établir une clé secrète partagée forte. Les objectifs du PAKE sont les suivants :

1. Les clés secrètes correspondent si les mots de passe correspondent, et paraissent aléatoires dans le cas contraire.

2. Les participants n'ont pas besoin de faire confiance à des tiers (concrètement, pas d'infrastructure à clé publique),

3. La clé secrète qui en résulte n'est connue de personne qui soit extérieur au protocole, pas même de ceux qui connaissent le mot de passe.

4. Le protocole ne révèle pas le mot de passe de l'une des parties à l'autre (sauf si les mots de passe correspondent), ni aux espions.

En résumé, la seule façon de réussir à attaquer le protocole est de deviner correctement le mot de passe dans le cadre même du protocole. (Par chance, il est possible de quasiment neutraliser de telles attaques en limitant le débit, c'est-à-dire en empêchant un utilisateur de se connecter après un certain nombre de tentatives de mot de passe erronées).

Au vu de ces impératifs, la méthode Mot de passe via TLS est clairement différente d'un PAKE, car :

• Elle repose sur WebPKI, qui fait confiance à des tiers appelés autorités de certification (voir https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ pour obtenir une explication en détail de WebPKI et de certaines de ses lacunes)

• Le mot de passe de l'utilisateur est révélé au serveur.

• Mot de passe via TLS ne permet pas à l'utilisateur d'être certain que le serveur connaît son mot de passe ou qu'il l'a déduit. Un serveur peut accepter n'importe quelle saisie de l'utilisateur sans aucun contrôle.

Cela étant dit, dans sa version standard le PAKE est encore pire que Mot de passe via TLS dans la mesure où il implique que le serveur stocke les mots de passe en texte clair. Nous avons besoin d'un PAKE qui permette au serveur de stocker les hachages salés si nous voulons améliorer la pratique actuelle.

Le PAKE asymétrique (ePAKE) constitue une amélioration par rapport au PAKE simple car seul le client connaît le mot de passe, le serveur quant à lui connaît un mot de passe  haché. Un ePAKE présente les quatre propriétés du PAKE, plus une autre :

1. Un pirate qui vole les données de mot de passe stockées sur le serveur doit effectuer une attaque par dictionnaire pour récupérer le mot de passe.

Le problème avec la plupart des protocoles aPAKE existants réside toutefois dans le fait qu'ils n'autorisent pas le salage (et quand il leur arrive de l'autoriser, ils exigent que le sel soit transmis à l'utilisateur, ce qui signifie que le pirate a accès au sel à l'avance et peut commencer à calculer une table arc-en-ciel pour l'utilisateur avant de voler les données). Par conséquent, nous souhaiterions perfectionner la propriété de sécurité comme suit :

5*) Un pirate qui vole les données de mot de passe stockées sur le serveur doit effectuer une attaque par dictionnaire par utilisateur pour récupérer le mot de passe après que les données ont été fragilisées.

OPAQUE est le premier protocole aPAKE à intégrer une vérification de sécurité formelle aussi perfectionnée : il garantit un sel totalement secret.

OPAQUE est ce que l'on appelle un aPAKE fort, ce qui signifie qu'il résiste aux attaques en précalcul grâce à un hachage secrètement salé sur le serveur. OPAQUE a été proposé et analysé de manière officielle par Stanislaw Jarecki, Hugo Krawcyzk et Jiayu Xu en 2018 (pour tout vous dire, Stanislaw Jarecki est mon directeur d'étude). Le nom OPAQUE a été formé à partir des noms de deux protocoles cryptographiques : OPRF et PAKE. Nous connaissons déjà PAKE, mais qu'est-ce qu'une OPRF ? OPRF vient de « Oblivious Pseudo-Random Function », qui signifie fonction pseudo-aléatoire inconsciente. Il s'agit d'un protocole dans lequel deux parties calculent une fonction F(Key, x) qui est déterministe mais produit des valeurs à l'apparence aléatoire. Une partie entre la valeur x et une autre partie apporte la clé. La partie qui entre x découvre le résultat F(Key, x) mais pas la clé, et la partie qui fournit la clé n'apprend rien. (Vous pouvez étudier en détail les mathématiques des OPRF ici : https://blog.cloudflare.com/privacy-pass-the-math/).

OPAQUE repose essentiellement sur une méthode de stockage des secrets utilisateur que l'on souhaite sécuriser sur un serveur sans que celui-ci puisse y accéder. Au lieu de stocker un salage de mot de passe traditionnel, le serveur stocke une enveloppe secrète qui est « verrouillée » par deux informations : votre mot de passe, connu de vous uniquement, et une clé secrète aléatoire (comme un sel), que seul le serveur connaît. Pour se connecter, le client lance un échange cryptographique qui révèle la clé de l'enveloppe au client, mais surtout sans jamais la révéler au serveur.

Le serveur envoie ensuite l'enveloppe à l'utilisateur, qui peut alors récupérer les clés chiffrées. (L'enveloppe contient une paire de clés privée-publique pour l'utilisateur, et une clé publique pour le serveur). Ces clés, une fois déverrouillées, feront office d'entrées pour un protocole d'échange de clé authentifié (AKE), grâce auquel l'utilisateur et le serveur vont définir une clé secrète qui leur permettra de chiffrer leur communication à venir.

Deux phases sont à distinguer dans OPAQUE, inscription des informations d'identification et connexion via l'échange de clé.

Avant l'inscription, l'utilisateur commence par s'inscrire à un service et choisit un nom d'utilisateur et un mot de passe. L'inscription commence par le flux OPRF que nous venons de décrire : Alice (l'utilisateur) et Bob (le serveur) procèdent à un échange OPRF. À la suite de cela Alice dispose d'une clé aléatoire rwd, déduite du résultat de l'OPRF F(key, pwd), où key correspond à une clé OPRF détenue par le serveur, spécifique à Alice et pwd correspond au mot de passe d'Alice.

Avec son message OPRF, Bob envoie la clé publique correspondant à son identité OPAQUE. Alice génère alors une nouvelle paire de clés privée-publique, il s'agit de son identité OPAQUE, qu'elle conservera pour le service de Bob. Elle procède au chiffrement de sa clé secrète ainsi que la clé publique de Bob avec le rwd (nous appelons le résultat une enveloppe chiffrée). Elle envoie cette enveloppe chiffrée avec sa clé publique (non chiffrée) à Bob, qui stocke les données qu'elle a fournies, ainsi que son secret OPRF, dans une base de données indexée par son nom d'utilisateur.

La phase de connexion est très semblable. La procédure commence de la même manière que l'inscription, avec un flux OPRF. Toutefois, côté serveur, au lieu de générer une nouvelle clé OPRF, Bob cherche celle qui a été créée au moment de l'inscription d'Alice. Pour ce faire, il recherche le nom d'utilisateur d'Alice (qu'elle lui a transmis dans son premier message), et récupère l'enregistrement qu'il lui a consacré. Cet enregistrement contient sa clé publique, son enveloppe chiffrée et la clé OPRF de Bob pour Alice.

Il envoie également l'enveloppe chiffrée qu'Alice peut déchiffrer avec le résultat du flux OPRF. (En cas d'échec du déchiffrement, elle interrompt le protocole. C'est probablement le signe d'une erreur de saisie du mot de passe, ou d'une usurpation d'identité de la part de Bob). Si le déchiffrement réussit, elle dispose désormais de sa propre clé secrète et de la clé publique de Bob. Elle les utilise comme entrées d'un protocole AKE établi avec Bob qui entre à son tour sa clé privée et sa clé publique, ce qui produit pour chacun d'eux une nouvelle clé secrète.

À ce stade une question importante se pose : quel AKE convient à OPAQUE ? la nouvelle spécification du CFRG détaille plusieurs options, y compris 3DH et SIGMA-I. Toutefois, sur le Web, il existe déjà un AKE disponible : TLS !

Rappelons que le protocole TLS est un AKE dans la mesure où il garantit une authentification unilatérale (et mutuelle) avec déduction de secret partagé. Le protocole TLS est concentré autour d'un échange de clé Diffie-Hellman, qui n'est pas authentifié en soi. Cela signifie que les parties qui l'exécutent n'ont aucun moyen de vérifier avec qui ils l'exécutent. (Cela peut poser des problèmes, par exemple lorsque vous vous connectez à votre banque, ou à tout autre site web qui stocke vos données confidentielles, vous voulez être certain qu'ils sont bien ceux qu'ils prétendent être). L'authentification utilise principalement des certificats, qui sont émis par des entités de confiance dans le cadre d'un système appelé Infrastructure à clé publique (PKI). Chaque certificat est associé à une clé secrète. Pour prouver son identité, le serveur présente son certificat au client, et signe la négociation TLS avec sa clé secrète.

Ce n'est peut-être pas cette authentification par certificat très répandue sur le Web qu'il convient de modifier en premier. Il semble préférable de commencer par l'authentification du secret partagé TLS, à l'aide d'OPAQUE, après la négociation TLS. En d'autres termes, une fois qu'un serveur est authentifié avec son certificat WebPKI classique, les clients peuvent ensuite s'authentifier auprès du serveur. Cette authentification peut avoir lieu « après une négociation » dans une connexion TLS utilisant OPAQUE.

Les authentificateurs exportés constituent un mécanisme d'authentification « après négociation » dans TLS. Ils permettent à un serveur ou à un client de fournir la preuve d'une identité sans avoir à établir une nouvelle connexion TLS. Rappelons que dans le cas standard du Web, le serveur établit leur identité avec un certificat (prouvant, par exemple, qu'ils sont bien "cloudflare.com"). Mais si le même serveur compte également d'autres identités, ils doivent exécuter à nouveau le protocole TLS pour prouver qui ils sont.

Le flux de base de l'authentificateur exporté ressemble à un protocole question-réponse classique, et fonctionne comme suit. (Nous n'allons parler que du cas d'authentification du serveur, le cas du client étant symétrique).

Une fois établie une connexion TLS, à n'importe quel moment Alice (le client) envoie une demande d'authentification pour indiquer qu'elle souhaite que Bob (le serveur) fournisse la preuve d'une identité supplémentaire. Cette requête comprend un contexte (une chaîne imprévisible, envisagez cela comme un défi) et des extensions qui incluent des informations précisant l'identité que le client souhaite fournir. Par exemple, le client peut inclure l'extension SNI pour demander au serveur un certificat associé à un certain nom de domaine, autre que celui initialement utilisé dans la connexion TLS.

À réception du message du client, si le serveur dispose d'un certificat valide correspondant à la demande, il renvoie un authentificateur exporté, ce qui prouve qu'il possède la clé secrète du certificat. (Ce message est au même format qu'un message Auth du client dans la négociation TLS 1.3. Il comporte un certificat, un CertificateVerify et un message Finished). Si le serveur ne peut ou ne souhaite pas s'authentifier avec le certificat demandé, il répond par un authentificateur vide qui ne contient qu'un message Finished bien formé.

Le client vérifie alors que l'authentificateur exporté qu'il reçoit est bien formé, puis vérifie que le certificat présenté est valide, et, le cas échéant, accepte la nouvelle identité.

En résumé, les authentificateurs exportés constituent une méthode prudente d'authentification dans une couche supérieure (telle que la couche application) qui met à profit la qualité de la cryptographie et des formats de message de TLS. Qui plus est, ils sont liés à la session TLS de telle sorte que les messages d'authentification ne peuvent pas être copiés et collés d'une connexion TLS dans une autre. Autrement dit, les authentificateurs exportés forment l'exact maillon nécessaire pour ajouter l'authentification basée sur OPAQUE dans TLS.

OPAQUE-EA permet d'exécuter OPAQUE à n'importe quel endroit une fois qu'une connexion TLS a été établie. Rappelons que Bob (le serveur) stockera son identité OPAQUE, dans ce cas une clé de signature et une clé de vérification, et qu'Alice stockera son identité (chiffrée) sur le serveur de Bob. (Le flux d'inscription dans lequel Alice stocke ses clés chiffrées est le même que dans la version standard d'OPAQUE, à la différence près qu'elle stocke une clé de signature, nous allons donc passer directement au flux de connexion). Alice et Bob exécutent deux flux de demande d'authentification EA (pour Exported Authenticators ou authentificateurs exportés), un pour chaque partie, et les messages de protocole OPAQUE circulent dans la section des extensions des EA. Examinons en détail ce fonctionnement.

D'abord, Alice génère son message OPRF sur la base de son mot de passe. Elle crée une requête d'authentification, demandant l'identité OPAQUE de Bob, elle indique (dans les champs d'extension) son nom d'utilisateur et son mot de passe à l'aveugle, puis elle envoie le tout à Bob via la connexion TLS qu'ils ont établie.

Bob reçoit le message et cherche le nom d'utilisateur d'Alice dans sa base de données. Il récupère l'enregistrement OPAQUE contenant la clé de vérification et l'enveloppe chiffrée d'Alice, ainsi que sa propre clé OPRF. Il utilise la clé OPRF sur le message OPRF, et crée un authentificateur exporté prouvant qu'il est bien le détenteur de sa clé de signature OPAQUE, avec une extension contenant sa sortie OPRF et l'enveloppe chiffrée. De plus, il envoie une nouvelle requête d'authentification invitant Alice à prouver qu'elle est la détentrice de sa clé de signature OPAQUE.

Alice analyse le message et procède à l'évaluation OPRF à l'aide du message de Bob pour obtenir le rwd qui en résulte, puis elle l'utilise pour déchiffrer l'enveloppe. Elle obtient ainsi sa clé de signature et la clé publique de Bob. Elle utilise la clé publique de Bob pour valider la preuve de sa réponse d'authentification et, si la vérification est satisfaisante, elle envoie un authentificateur exporté prouvant qu'elle détient bien la clé de signature qui vient d'être chiffrée. Bob vérifie la validité de l'authentificateur exporté, et, le cas échéant, autorise la connexion d'Alice.

Tout ce qui est décrit précédemment est étayé par de très nombreuses théories pour lesquelles aucun moyen de concrétisation n'a encore été trouvé. J'avais pour projet de faire de cette théorie une réalité. J'ai commencé par des descriptions écrites d'authentificateurs exportés, OPAQUE, et une version préliminaire d'OPAQUE-in-TLS. Mon objectif était d'en tirer un prototype qui fonctionne.

Ma démo illustre la faisabilité de mise en œuvre d'OPAQUE-EA sur le Web, en supprimant la totalité des mots de passe en texte clair de la toile, qu'ils soient chiffrés ou non. Il est ainsi possible d'améliorer le flux actuel de mots de passe sur TLS avec de meilleures propriétés de sécurité, sans que l'utilisateur ne remarque aucun changement.

Il peut être utile de connaître quelques-uns des détails de la mise en œuvre. Lorsqu'il s'agit de science de l'informatique, l'abstraction est un outil puissant. Cela signifie que souvent nous pouvons profiter d'outils et d'API existants ; évitons les efforts inutiles là où d'autres ont déjà obtenu des résultats. Dans le cadre de mon projet, j'ai énormément puisé dans mint, une mise en œuvre en open source du protocole TLS 1.3 dans Go qui s'avère parfaite pour le prototypage. J'ai également profité de l’API OPRF de CIRCL. J'ai créé des librairies d'authentificateurs exportés, l'élément central d'OPAQUE et d'OPAQUE EA (qui lie les deux).

J'ai réalisé la démo Web en intégrant la fonctionnalité OPAQUE-EA dans un simple modèle de serveur et client HTTP qui se transmettent des messages via HTTPS. Étant donné qu'un navigateur ne peut pas exécuter Go, j'ai compilé depuis Go vers WebAssembly (WASM), ce qui m'a permis d'utiliser la fonctionnalité Go dans le navigateur et j'ai rédigé un script simple dans JavaScript pour invoquer les fonctions WASM dont j'avais besoin.

Les navigateurs actuels ne permettant pas d'accéder à la connexion TLS sous-jacente côté client, j'ai dû mettre en place une astuce pour permettre au client d'accéder aux clés de l'exportateur, à savoir que le serveur calcule simplement les clés et les envoie au client via HTTPS. Cette solution limite la sécurité de la démo qui en résulte, c'est-à-dire qu'il faut faire confiance au serveur pour fournir la bonne clé. Malgré cela, le mot de passe de l'utilisateur est toujours en sécurité, quand bien même un serveur malveillant fournirait les mauvaises clés. Il lui est simplement impossible de garantir avec certitude que c'est auprès de ce serveur qu'a été faite l'inscription. Cependant, à l'avenir, les navigateurs pourraient intégrer un mécanisme qui prendrait en charge les clés exportées et permettrait à OPAQUE-EA de fonctionner avec l'intégralité de ses propriétés de sécurité.

Vous pouvez observer ma mise en œuvre sur GitHub. Vous pouvez même suivre les instructions pour installer votre propre serveur et client de test OPAQUE-EA. J'insiste toutefois sur le fait que la mise en œuvre n'a été conçue qu'à des fins de démonstration de faisabilité et ne doit pas être utilisée pour des systèmes en production sans être préalablement révisée, voire modifiée.

Malgré les formidables propriétés présentées par OPAQUE-EA, passer du stade de démonstration de faisabilité à celui de mécanisme d'authentification à part entière ne se fera pas sans difficulté.

Prise en charge des clés de l'exportateur TLS par les navigateurs. Comme je l'ai mentionné précédemment, pour exécuter OPAQUE-EA dans un navigateur, vous devez accéder aux secrets de la connexion TLS à savoir les clés de l'exportateur. Il n'y a aucun moyen de le faire dans les navigateurs les plus courants. Vous devrez donc ajouter la prise en charge de cette fonctionnalité.

Refonte des bases de données de mots de passe. Pour adopter OPAQUE-EA, les serveurs doivent non seulement mettre à jour leur logique de vérification des mots de passe, mais aussi remanier complètement leurs bases de données de mots de passe. Comme OPAQUE repose sur des représentations spéciales de mots de passe qui ne peuvent être générées que de manière interactive, les mots de passe existants hachés et salés ne peuvent pas être automatiquement mis à jour dans les enregistrements OPAQUE. Les serveurs devront probablement exécuter un flux d'enregistrement OPAQUE spécial, utilisateur par utilisateur. OPAQUE reposant sur l'adhésion à la fois du client et du serveur, les serveurs devront peut-être poursuivre avec l'ancienne méthode pendant un certain temps avant que tous les clients ne se soient mis à jour.

Dépendance à l'égard des normes émergentes. OPAQUE-EA s'appuie sur les OPRF, qui sont en cours de normalisation, et sur les authentificateurs exportés, un projet de norme. Cela signifie que la prise en charge de ces dépendances n'est pas encore disponible dans la plupart des bibliothèques cryptographiques existantes. Les premiers adoptants auront donc peut-être besoin de mettre en œuvre ces outils eux-mêmes.

Tant que les utilisateurs auront encore recours à des mots de passe, nous souhaitons rendre le processus aussi sécurisé que possible. Les méthodes actuelles reposent sur une pratique risquée, le traitement de mots de passe en texte clair côté serveur pendant la vérification de leur exactitude. Les PAKE, et plus précisément les aPAKE, permettent une connexion avec mot de passe sécurisée sans que jamais le serveur ne puisse voir les mots de passe. OPAQUE est l'un des meilleurs aPAKE du marché et peut être entièrement intégré dans TLS. Vous pouvez consulter le code.

[1] Bellovin, S. M., and Merritt, M. “Encrypted key exchange: Password-based protocols secure against dictionary attacks.” Proc. IEEE Computer Society Symposium on Research in Security and Privacy (Oakland, May 1992), 72–84.