Skip to content

SQRL pourrait-il vraiment être aussi sûr qu'on le dit ?

Nos chercheurs vedettes ont épuisé leurs réserves de café, cherchant jour et nuit la réponse, jusqu'à ce qu'Alfredo trouve la réponse sur Beanstalk et maintenant nous la partageons avec nous.

Solution :

Dans l'ensemble, le protocole ne semble pas accroître la sécurité par rapport à la technologie existante. Si vous cherchez la meilleure façon de protéger votre identité en ligne, c'est sans aucun doute.pas cela. Mais passons en revue les avantages et les inconvénients :

Avantages

Il est impossible de "partager" un mot de passe dans le sens étroit où un site web malveillant ne peut pas utiliser l'authentification fournie à un site pour se connecter à un autre site.

Une attaque par force brute contre le jeton d'authentification n'est pas réalisable.

Les jetons d'authentification ne sont pas stockés sur votre ordinateur. Cela vous protège contre un petit sous-ensemble d'attaques dirigées vers les postes de travail. Plus précisément, vous êtes protégé contre les attaques qui volent votre mot de passe sur votre ordinateur. Vous êtes pas protégé contre toute sorte d'attaques de détournement de session ou de prise de contrôle du navigateur, cependant, et vous êtes maintenant.également sensible aux attaques liées au téléphone. Nous y reviendrons plus tard.

Inconvénients

Cette technique est dangereusement sensible aux attaques MITM et à l'ingénierie sociale. Probablement plus que tout autre schéma d'authentification utilisé, y compris les mots de passe. L'étape d'authentification et l'étape de lancement de la connexion sont intrinsèquement déconnectées dans le sens où le téléphone s'authentifiera correctement contre tout code QR présenté, peu importe comment ou où il est présenté à l'utilisateur.

Ainsi, par exemple, un site d'hameçonnage peut afficher un code QR de connexion authentique qui permet de connecter l'attaquant au lieu de l'utilisateur. Gibson est convaincu que les utilisateurs verront le nom de la banque, du magasin ou du site sur l'application du téléphone pendant l'authentification et qu'ils feront donc preuve d'une vigilance suffisante pour déjouer les attaques. L'expérience montre que cela est peu probable et qu'il est plus raisonnable de penser que le fait de voir le nom correct sur l'application rassurera faussement l'utilisateur en lui faisant croire que le site est légitime parce qu'il a pu déclencher la demande de connexion familière sur le téléphone. La prudence déjà battue dans la tête des utilisateurs concernant la sécurité des mots de passe ne se traduit pas nécessairement par de nouvelles techniques d'authentification comme celle-ci, ce qui rend cette appli probablement intrinsèquement moins résistante à l'ingénierie sociale.

Cette technique combine à la fois l'authentification et l'identité dans un objet physique qui est.fréquemment perdu ou volé. En ce sens, il s'agit plutôt d'un passeport que d'un mot de passe. Toute personne en possession de votre téléphone est soudainement exclusivement en possession de votre identité : non seulement l'attaquant peut se faire passer pour vous, mais sans une deuxième copie sur un deuxième téléphone (peu probable), maintenant vous avez perdu la capacité de vous identifier. Les clés d'authentification ne sont pas révocables, donc sans récupération hors bande sur chaque site, vous ne pouvez pas récupérer votre identité. Et même si la récupération hors bande existe, lorsque vous êtes confronté à deux utilisateurs, l'un en possession de l'identité et l'autre sans, il peut être difficile de voir pourquoi l'opérateur du site devrait vous faire confiance.

Cette technique combine tous vos jetons d'authentification en une seule clé. à moins que vous n'en créiez manuellement d'autres. Cela fait de votre clé unique une cible extra-juicy pour les attaquants. En outre, la clé est stockée sur votre téléphone, dont les appareils ont généralement une sécurité interne risible et poreuse. La combinaison de cibles exceptionnellement juteuses avec une sécurité de qualité inférieure ne vous rend pas sûr.

Alternatives

L'aspect le plus problématique de ce système est la faiblesse de sa comparaison avec les alternatives disponibles.

L'option la plus sûre universellement acceptée aujourd'hui est lastpass, keepass, et d'autres systèmes de mot de passe intégrés au navigateur. En particulier, le cryptage côté client évite d'avoir à faire confiance à un tiers. Et plus important encore, l'intégration du navigateur rend le phishing pratiquement impossible. LastPass ou KeePass ne remplit le mot de passe que s'il est servi depuis le bon domaine, ce qui signifie que si on lui présente un site malveillant, l'utilisateur n'aura pas accès à son mot de passe.

En outre, LastPass a récemment ajouté une fonction qui incite les utilisateurs à changer les mots de passe qui ne sont pas globalement uniques. Cela permet d'éviter la réutilisation des mots de passe, ce qui signifie que le principal avantage de la technique de Gibson peut facilement être obtenu en utilisant cet outil aujourd'hui sur des sites existants, sans l'insécurité supplémentaire que son schéma implique.

Les systèmes existants d'authentification à deux facteurs qui utilisent des téléphones ou des dispositifs similaires pour protéger les connexions des utilisateurs le font déjà aujourd'hui d'une manière qui ne vous rend pas immédiatement vulnérable à l'usurpation d'identité si votre dispositif est volé. La sécurité supplémentaire de l'authentification à deux facteurs réside dans le fait que ni le dispositif ni le mot de passe ne peuvent être utilisés en cas de vol sans l'autre. La technique de Gibson résiste largement à l'inclusion dans un schéma à deux facteurs, ce qui rend ce niveau de protection indisponible.

TL;DR :

La technique d'authentification de Gibson ne crée pas un avantage suffisant pour surmonter les coûts de sécurité supplémentaires qu'elle impose également. Ces coûts sont une partie fondamentale du schéma lui-même et ne peuvent probablement pas être travaillés sans mettre au rebut l'ensemble de la conception.

Vous pourriez argumenter que c'est mieux que rien, mais vous ne pouvez pas argumenter que c'est mieux que tout ce que nous avons déjà.

Mises à jour de Gibson

Gibson a récemment annoncé une protection supplémentaire contre le phishing car cela a été une critique majeure. Leur protection est la suivante : Si vous n'utilisez PAS les codes QR, le téléphone portable, etc, et que vous avez plutôt un agent d'authentification sur votre système (dans le navigateur, par exemple), alors le serveur peut vérifier que la réponse d'authentification provient de la même IP que la demande d'authentification. C'est bien, mais l'objectif de ce protocole est de transférer votre identité vers votre téléphone portable. Si la seule façon sûre d'utiliser le protocole est de ne pas utiliser sa fonctionnalité principale, alors peut-être devrions-nous repenser ce que nous essayons d'accomplir.

Théoriquement, vous pourriez continuer à utiliser votre téléphone portable si (et seulement si) votre téléphone portable savait qu'il utilise la même IP que votre ordinateur. Ce que, bien sûr, il ne peut pas savoir parce qu'il ne connaît pas l'adresse IP de votre ordinateur.

Une meilleure solution

Comme dit précédemment, si la mesure d'authentification est dans votre navigateur, alors tout le problème du phishing est immédiatement résolu sans aucun effort ou vérification de la part de l'utilisateur. Même l'utilisateur le moins compétent ne peut pas se faire piéger en s'authentifiant sur le mauvais site, car le jeton d'authentification du site est associé au nom de domaine, et le navigateur ne permettra pas l'authentification sur le mauvais domaine. Il s'agit d'une technique déjà utilisée aujourd'hui, complètement automatique, qui ne nécessite pas la coopération du site ou une quelconque intelligence de la part de l'utilisateur.

Cette méthode peut être renforcée en exigeant un deuxième facteur d'authentification (comme une clé variable dans le temps sur un téléphone portable) qui, là encore, est déjà disponible et utilisé aujourd'hui, ce qui vous protège (surtout) contre les ratés du site ou de l'entreprise de destination.

Quant aux préoccupations concernant l'authentification côté navigateur qui est vulnérable aux attaques des postes clients : si la est vraie, il est également vrai que.si votre navigateur est compromis, alors aucune utilisation de ce navigateur n'est sûre., quel que soit le mécanisme d'authentification que vous utilisez. Les auteurs de logiciels malveillants peuvent (et le font déjà) attendre que vous vous authentifiez par vous-même en utilisant votre technique super-sécurisée, puis envoyer silencieusement le trafic nécessaire pour "posséder" votre compte, le tout sans que vous ne voyiez rien d'anormal. Ni SQRL ni aucun autre système d'authentification ne peut protéger l'utilisateur d'un navigateur compromis, pas plus que des serrures de porte ne peuvent vous protéger d'un incendie. Acheter des serrures ignifugées n'est pas une solution.

Where Next

Si vous recherchez une garantie absolue de protection contre l'usurpation d'identité, alors regardez le jeton Fido U2F. Cette norme brille là où SQRL échoue, et vous offre une immunité garantie contre les attaques MITM (par exemple, le phishing). Elle authentifie non seulement l'utilisateur, mais aussi le canal, ce qui vous garantit que (a) votre compte ne peut pas être authentifié sans le jeton et que (b) votre jeton ne peut être utilisé que pour authentifier une connexion à la machine à laquelle il est attaché. Voir cette réponse pour plus d'informations.

SQRL n'est certainement pas sans défaut, mais c'est.certainement supérieure à la plupart des solutions d'authentification primaire largement utilisées sur le web aujourd'hui en termes de sécurité et (et c'est important) de convivialité. Permettez-moi de m'expliquer.

Idées fausses

Tout d'abord, permettez-moi de dissiper quelques-unes des idées fausses présentes dans certaines des autres réponses à cette question. Beaucoup de ces réponses sont dépassées, et ont été écrites avant les changements apportés à la documentation de SQRL qui traitent les problèmes qui y sont présentés, tandis que d'autres semblent mettre indûment l'accent sur les défauts de SQRL qui sont également présents dans de nombreuses autres solutions d'authentification existantes largement utilisées, tout en ignorant ses avantages. Alors dissipons quelques idées fausses ici, d'accord ?

Mythe : SQRL nécessite le balayage des codes QR pour fonctionner

Ce n'est tout simplement pas vrai. Les codes QR sont une commodité qui facilite l'utilisation de SQRL sur les ordinateurs sur lesquels l'utilisateur n'a pas configuré le logiciel client SQRL. Le site Web de SQRL indique ce qui suit :

Three Ways to Go .smartphone optional :

Bien que l'inspiration initiale pour le développement de ce système ait été un smartphone scannant un code QR sur la page de connexion d'un site Web, un petit ajout à ce modèle permet deux modes de fonctionnement plus importants : Il suffit de faire en sorte que l'image du code QR soit également un lien cliquable vers la même URL que celle qui est encodée dans le code QR. Cela donne trois façons de se connecter :

  • Scanner le code avec un smartphone : En utilisant le modèle décrit ci-dessus, le smartphone d'un utilisateur scanne le code QR apparaissant sur la page de connexion d'un site web et l'utilisateur est connecté à ce site.
  • Taper le code sur un smartphone : Pour se connecter à un site web SUR le smartphone, lorsque le code visuel SQRL est également un lien de style URL (en utilisant sqrl:// comme schéma), l'application SQRL installée dans le smartphone recevra ce lien et connectera de manière sécurisée l'utilisateur au site sur le téléphone.
  • Cliquez sur le code sur un écran de bureau ou d'ordinateur portable : Pour utiliser le système SQRL sur tout système de bureau ou d'ordinateur portable, une application SQRL de bureau serait installée et s'enregistrerait pour recevoir des liens sqrl://. (Cela est similaire à la façon dont un programme de messagerie s'enregistre pour recevoir des liens mailto :). Cela permet aux utilisateurs d'utiliser sur leur ordinateur de bureau la même solution que celle qu'ils utilisent sur leur smartphone. Lorsqu'un site Web quelconque propose un code SQRL, l'utilisateur n'a qu'à cliquer sur le code avec le curseur de sa souris et l'application SQRL installée localement apparaît, lui demande son mot de passe SQRL, confirme le domaine, puis le connecte.

Mythe : La clé maîtresse SQRL est stockée de manière totalement non cryptée et non protégée sur votre téléphone.

Je ne sais pas pourquoi certaines personnes ont fait cette supposition, car il me semble évident que ce ne serait pas le cas. La clé maîtresse SQRL est protégée à peu près de la même manière que vous protégeriez une base de données de mots de passe : avec un mot de passe maître fort. Le vol du téléphone d'un utilisateur ne vous donnerait pas automatiquement accès à son identité en ligne, à moins que vous ne disposiez également de son mot de passe principal. Plus de détails sur la gestion des clés sont expliqués dans la page sur la gestion des clés côté client de SQRL sur le site web de SQRL.

Mythe : si votre clé maîtresse est volée, vous ne pouvez pas changer vos identifiants de connexion.

Ceci est également faux. SQRL fournit un moyen intégré pour permettre au véritable titulaire du compte de mettre à jour ses identifiants de connexion dans le cas d'une clé compromise. Cette fonctionnalité est connue sous le nom de verrouillage d'identité :

"Identity Lock" empêche le changement d'identité & permet la récupération : Cette fonctionnalité est également suffisamment importante pour mériter sa propre page de description détaillée : "Le protocole de verrouillage d'identité" (page 4 dans le bloc de liens au bas de cette page.) Une fois que l'identité d'un utilisateur a été établie avec un serveur web, le client SQRL est.incapable de de changer cette identité. Cela signifie que si le pire se produisait, et qu'un mot de passe très faible et facilement deviné était utilisé, ou que le téléphone ou le bureau d'un utilisateur était piraté pour obtenir sa clé maîtresse d'identité et son mot de passe, aucun tiers malveillant ne peut changer l'identité en ligne de l'utilisateur. pour les bloquer de leurs propres comptes en ligne. Et, de plus, en chargeant ensuite une "clé de déverrouillage d'identité" normalement hors ligne, le véritable propriétaire de son identité peut retirer et remplacer son identité en ligne perdue ou volée pour essentiellement.la reprendre à tout attaquant, rendant leur identité précédente inutile.

Plausible : SQRL est plus vulnérable au phishing que les solutions d'authentification existantes.

Ok, donc c'est en fait partiellement vrai. Lorsque l'on utilise SQRL en scannant un code QR, il y a en effet très peu de protection contre le phishing. À moins que l'utilisateur ne prenne soin de s'assurer que le site web affiché dans la barre d'URL de son navigateur est le même que celui affiché par l'application SQRL Client, il pourrait autoriser une session de connexion pour l'attaquant. C'est encore mieux que les mots de passe, où ils donneraient au phisher un accès permanent à leur compte (et à tous les autres comptes qu'ils ont ailleurs et qui partagent le même mot de passe) jusqu'à ce qu'ils changent leur mot de passe, mais pas aussi bien que d'autres solutions qui s'intègrent au navigateur de l'utilisateur comme les clés U2F, WebAuthn, les certificats clients et (sous certaines conditions) les gestionnaires de mots de passe.

Cependant, lorsque vous utilisez un client SQRL sur le même appareil que celui avec lequel vous vous connectez, SQRL a mis en place certaines protections contre le phishing. Ces protections sont expliquées sur le site Web de SQRL, dans la section intitulée "Comment SQRL peut déjouer les attaques de phishing". Il est également possible d'intégrer SQRL aux navigateurs (éventuellement par le biais de plugins) afin de fournir une protection beaucoup plus forte contre les attaques de phishing, à l'instar de solutions comme WebAuthn et les certificats clients.

Globalement, je classerais SQRL au même niveau que les gestionnaires de mots de passe pour la protection contre le phishing. Il a le potentiel de fournir une forte protection contre le phishing lorsqu'il est installé sur le même appareil que celui sur lequel l'utilisateur se connecte, mais fournit une protection minimale lorsqu'il est installé sur un appareil différent.

Comparaison avec les alternatives

Comparons maintenant SQRL avec les solutions d'authentification existantes largement utilisées.

Mots de passe

SQRL est largement supérieur aux mots de passe à bien des égards. Non seulement elle est plus pratique à utiliser une fois configurée, puisque les utilisateurs n'ont pas à se soucier de se souvenir ou de retaper plusieurs mots de passe différents pour chaque site, mais elle protège également contre la réutilisation des mots de passe, les mots de passe faibles, les keyloggers et, dans une certaine mesure, le phishing.

Les inconvénients de SQRL par rapport aux mots de passe sont qu'il est plus difficile à mettre en œuvre pour les opérateurs de sites Web, qu'il n'est pas aussi largement utilisé, qu'il faut plus de temps pour le configurer initialement, qu'il faut un certain effort pour le transférer sur un nouvel appareil et qu'il fournit un point de défaillance unique pour tous les comptes de l'utilisateur si la clé maîtresse est volée (bien que ce dernier point soit également le cas pour les mots de passe si un utilisateur utilise le même mot de passe sur chaque site).

Gestionnaires de mots de passe

À bien des égards, SQRL est très similaire aux gestionnaires de mots de passe. Ils fournissent tous deux un ancrage de confiance unique et centralisé qui sert en quelque sorte de proxy d'authentification entre les utilisateurs et les services individuels. Il y a cependant quelques façons dont SQRL est supérieur aux gestionnaires de mots de passe.

Le principal avantage que je pense que SQRL a sur les gestionnaires de mots de passe est qu'il est plus facile et plus sûr à utiliser sur des ordinateurs non fiables ou seulement partiellement fiables. Par exemple, disons qu'un utilisateur veut se connecter à un site Web en utilisant un ordinateur dans une bibliothèque publique. Avec un gestionnaire de mots de passe, il devra soit accéder au mot de passe de ce site sur son téléphone et le retaper manuellement sur l'ordinateur, soit télécharger son gestionnaire de mots de passe et sa base de données de mots de passe sur l'ordinateur de la bibliothèque, déverrouiller la base de données à l'aide de son mot de passe principal, puis se connecter. Le premier scénario est gênant pour l'utilisateur et expose le mot de passe en clair de l'utilisateur pour ce site à l'ordinateur non sécurisé (et à tout logiciel malveillant sur l'ordinateur non sécurisé, y compris les enregistreurs de frappe). Le deuxième scénario est encore pire, car il est à la fois peu pratique et expose l'ensemble de la base de données des mots de passe décryptés et le mot de passe principal de l'utilisateur à l'ordinateur non fiable. Avec SQRL, l'utilisateur n'aurait qu'à scanner un code QR sur l'écran de l'ordinateur non fiable, ce qui est beaucoup plus pratique pour l'utilisateur et n'expose qu'une seule session de connexion (sans informations d'identification réutilisables comme un mot de passe) à l'ordinateur non fiable.

Un autre avantage de SQRL par rapport aux gestionnaires de mots de passe est qu'il est plus facile de se remettre du pire scénario : le vol de la base de données de mots de passe / clé maîtresse de l'utilisateur. Avec un gestionnaire de mots de passe, vous devriez non seulement changer votre mot de passe sur chaque site, mais vous devriez également vous inquiéter du fait que l'attaquant change vos mots de passe (ce qui pourrait vous empêcher d'accéder à votre compte). L'attaquant a également l'avantage de posséder une liste de tous les sites sur lesquels vous avez un compte, ce qui rend l'exploitation du vol d'une base de données de mots de passe d'autant plus facile. Avec SQRL, se faire voler sa clé maîtresse est toujours une situation terrible, mais l'attaquant ne dispose pas de la liste des sites sur lesquels vous avez un compte (il doit donc deviner), et ne peut pas changer votre mot de passe pour vous bloquer. Une fois que vous avez chargé votre clé de déverrouillage d'identité, il est également un peu plus pratique de changer vos identifiants de connexion sur chaque site, car le client SQRL a la capacité de le faire automatiquement pour chaque site que vous visitez à la connexion. (Pas besoin de passer par des formulaires de "changement de mot de passe").

Enfin, je pense que SQRL a un petit mais important avantage sur les gestionnaires de mots de passe en ce qui concerne son objectif de remplacer entièrement les mots de passe, et c'est que les sites ont la possibilité d'imposer l'utilisation de SQRL par rapport aux mots de passe traditionnels. Tant que les utilisateurs auront la possibilité d'opter pour une sécurité médiocre, en réutilisant le même mot de passe sur chaque site, cela se produira encore. Si SQRL commence à être largement adopté, les sites peuvent réellement commencer à éliminer progressivement l'utilisation des mots de passe. Cela ne peut pas être fait avec les gestionnaires de mots de passe, car ils dépendent de l'utilisation des mots de passe pour fonctionner.

En termes d'inconvénients, je ne peux pas penser à une situation où SQRL serait nécessairement pire que les gestionnaires de mots de passe en termes de sécurité. Le principal inconvénient de SQRL est qu'il nécessite le soutien des opérateurs de sites Web, alors que les gestionnaires de mots de passe ne nécessitent aucun soutien particulier des services existants. Cela signifie que vous pouvez commencer à utiliser les gestionnaires de mots de passe dès maintenant, mais que SQRL devra attendre que les sites le mettent en œuvre avant de pouvoir être utilisé. C'est un obstacle important à l'adoption.

Certificats clients

Le principal avantage de SQRL par rapport aux certificats clients est d'ordre pratique. Les certificats clients sont actuellement compliqués à configurer, difficiles à transférer entre ordinateurs et posent des problèmes de confidentialité lorsque le même certificat est utilisé sur différents sites. En théorie, nous pourrions construire un système utilisant des certificats clients qui résoudrait ces problèmes, mais il y aurait aussi le problème de la mauvaise intégration avec les interfaces utilisateur des sites Web et les serveurs Web, qui sont des problèmes plus difficiles à résoudre. Je n'entrerai pas trop dans les détails ici, car il y a déjà un excellent article sur les problèmes d'utilisabilité des certificats clients sur browserauth.net.

En termes de sécurité, les certificats clients ont l'inconvénient de nécessiter l'implication d'une AC. Cela est (potentiellement) coûteux, et nécessite de faire confiance à l'AC tierce. En outre, si vous choisissez d'ignorer les AC et d'auto-signer vos certificats, vous devez faire face à la question de la révocation des certificats. Les certificats clients ont également les mêmes problèmes de sécurité et de commodité que les gestionnaires de mots de passe lorsque les utilisateurs veulent se connecter sur un ordinateur non fiable ; ils doivent transférer leur cert sur l'ordinateur non fiable, ce qui est à la fois gênant et expose potentiellement leur identité principale à des logiciels malveillants sur cet ordinateur.

En bref, jusqu'à ce que quelqu'un vienne avec une meilleure solution conviviale utilisant des certificats clients qui résout (au moins la plupart) de ces problèmes, je ne crois pas que les certs clients soient un concurrent sérieux à SQRL (ou, d'ailleurs, aux mots de passe).

Authentification à 2 facteurs

J'ai juste pensé que je devais mentionner ceci : SQRL et l'authentification à 2 facteurs sont.pas mutuellement exclusives. SQRL est un remplacement du premier facteur de l'authentification à 2 facteurs : les mots de passe. D'autres mesures supplémentaires comme les codes OTP ou les clés FIDO U2F peuvent toujours être utilisées avec SQRL.

WebAuthn

Maintenant voici où les choses deviennent intéressantes. WebAuthn est une nouvelle (enfin, plus récente que SQRL) norme W3C conçue pour fournir une API standard que les sites Web peuvent utiliser pour authentifier les utilisateurs avec des clés publiques sur le Web. Tout comme SQRL, elle prend en charge l'utilisation du téléphone de l'utilisateur pour authentifier une session de connexion sur un périphérique externe, en plus de quelques autres méthodes d'authentification (comme les clés de sécurité à 2e facteur).

C'est là que SQRL rencontre finalement son match, du moins du point de vue de la sécurité. Non seulement WebAuthn fournit toutes les mêmes protections contre la réutilisation des mots de passe, les mots de passe faibles et l'enregistrement des touches que SQRL, mais il offre également une protection encore plus forte contre le phishing en s'intégrant au navigateur de l'utilisateur.même lorsqu'il autorise une session de connexion pour un PC sur lequel l'utilisateur n'a pas préalablement configuré le logiciel client de l'authentificateur. Cela est possible car dans cette situation, WebAuthn communique directement avec le navigateur de l'utilisateur en utilisant des protocoles de communication bidirectionnels comme Blutooth ou NFC au lieu de communiquer avec le site web que l'utilisateur utilise via un code QR unidirectionnel.

Du point de vue de la convivialité, les choses sont un peu plus compliquées. En apparence, du moins, WebAuthn l'emporte à nouveau. Comme il s'agit d'une norme du W3C qui est déjà mise en œuvre dans de nombreux navigateurs, les utilisateurs peuvent en théorie commencer immédiatement à utiliser WebAuthn sans avoir à installer de logiciel tiers. Dans la pratique, cependant, la plupart des implémentations existantes de WebAuthn se concentrent sur son utilisation comme une forme d'authentification de second facteur, ou comme un moyen de réauthentifier un utilisateur qui s'est précédemment connecté sur le même appareil via une méthode de connexion différente (généralement un mot de passe). En tant que facteur d'authentification primaire, WebAuthn est encore assez pauvre en implémentations viables.

Parmi les autres considérations mineures, citons le fait que SQRL dispose d'une méthode intégrée pour faire tourner les clés des comptes en cas de vol de la clé maîtresse, alors que WebAuthn s'appuie sur les sites Web pour mettre en œuvre leur propre système de révocation des clés, et le fait que WebAuthn nécessite certains matériels optionnels (comme Bluetooth ou NFC) afin de s'authentifier auprès d'une machine distante, alors que SQRL peut fonctionner sur n'importe quelle machine dotée d'un écran fonctionnel.

Dans l'ensemble, je pense qu'il est très probable que WebAuthn finisse par rendre SQRL obsolète. SQRL peut avoir un peu de marge de manœuvre pour le moment, mais WebAuthn a un soutien beaucoup plus fort de la part des fournisseurs de navigateurs, des opérateurs de sites et d'autres organisations tierces (comme le W3C). Une fois que WebAuthn aura obtenu quelques implémentations permettant son utilisation comme facteur d'authentification primaire, je m'attends à ce qu'il commence à envahir le web très rapidement.

Caveats

SQRL est toujours en développement actif, donc le matériel présenté dans cette réponse est sujet à changement. Au fur et à mesure que le développement se poursuit, je m'attends à ce que certaines des vulnérabilités et des incertitudes dans cette réponse soient abordées. La plupart des discussions ont lieu actuellement sur le groupe de discussion SQRL sur grc.com.

Comme d'habitude, prenez tout ce qui concerne Steve Gibson avec une bonne dose de sel. Lien obligatoire vers attrition.org.


Jetons un coup d'oeil à la description de Gibson de son protocole.

Gibon's rubbish

  • Le code QR présenté près de l'invite de connexion contient l'URL du service d'authentification du site. L'URL comprend un long numéro aléatoire généré de manière sécurisée, de sorte que chaque présentation de la page de connexion affiche un code QR différent. (Dans les cercles cryptographiques, ce long nombre aléatoire est connu sous le nom de "nonce").

  • L'application d'authentification SQRL du smartphone procède à un hachage cryptographique du nom de domaine du site avec la clé principale de l'utilisateur pour produire une paire de clés publiques spécifique au site.

  • L'app signe cryptographiquement l'intégralité de l'URL contenue dans le code QR à l'aide de la clé privée spécifique au site. Comme l'URL comprend un long nombre aléatoire sécurisé (le nonce), la signature est unique pour ce site et ce code QR.

  • L'application émet une requête sécurisée HTTPS POST vers l'URL du code QR, qui est le service d'authentification du site. Le POST fournit la clé publique spécifique au site et la signature cryptographique correspondante de l'URL du code QR.

  • Le site web d'authentification reçoit et accuse réception de la requête POST en renvoyant un HTTP standard "200 OK" sans autre contenu. L'appli SQRL accuse réception de la soumission réussie du code QR signé par l'utilisateur.

  • Le site d'authentification dispose de l'URL contenant le nonce qui est revenu de la page de connexion via le smartphone de l'utilisateur. Il dispose également d'une signature cryptographique de cette URL, et de la clé publique spécifique au site de l'utilisateur. Il utilise la clé publique pour vérifier que la signature est valide pour l'URL. Cela confirme que l'utilisateur qui a produit la signature a utilisé la clé privée correspondant à la clé publique. Après avoir vérifié la signature, le site d'authentification reconnaît l'utilisateur maintenant authentifié par sa clé publique spécifique au site.

La plus grande chose qui me saute aux yeux est l'utilisation d'une "clé maîtresse" par l'utilisateur. Si je lis correctement le protocole, cette unique clé maîtresse contrôle l'ensemble de l'identité en ligne de l'utilisateur.

Vraisemblablement, cette clé maîtresse est stockée dans le téléphone de l'utilisateur dans une base de données d'application. Ce qui ouvre un énorme vecteur d'attaque béant sous la forme d'un malware conçu spécifiquement pour voler la clé maîtresse.

Comparons donc la différence entre ce qui se passe lorsqu'un mot de passe est compromis et ce qui se passe lorsque la clé maîtresse est compromise. En supposant que vous suivez les bonnes pratiques en matière de mots de passe, à savoir des mots de passe longs, uniques et hautement aléatoires stockés dans un gestionnaire de mots de passe, tout ce que vous avez à faire est de changer un seul mot de passe s'il est compromis. Que se passe-t-il si votre clé maîtresse est compromise ? Vous devrez d'une manière ou d'une autre obtenir toutes les les sites sur lesquels vous vous êtes authentifié reconnaissent que votre clé maîtresse a été compromise. Le seul problème est que, puisque vous n'avez pas d'autres moyens de vous authentifier auprès du site, comme des noms d'utilisateur ou des adresses e-mail, comment le site saura-t-il que c'est bien vous qui essayez de révoquer la clé maîtresse ?

Comme tout ce qui sort de Gibson, ce schéma SRQL est très imparfait et n'offre aucun avantage par rapport aux méthodes conventionnelles.

Nous vous montrons les commentaires et les scores

Rappelez-vous quelque chose, que vous avez la possibilité d'évaluer cet avis si vous avez trouvé le résultat.



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.