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

Avantages

Il est impossible de "partager" un mot de passe au sens strict où un site Web malveillant ne peut pas utiliser l'authentification fournie à un site pour vous connecter à un autre site.

Une attaque par force brute contre le jeton d'authentification n'est pas possible.

Les informations d'identification ne sont pas stockées sur votre ordinateur. Ceci vous protège contre un petit sous-ensemble d’attaques dirigées par les postes de travail. Plus précisément, vous êtes protégé contre les attaques qui volent votre mot de passe sur votre ordinateur. Cependant, vous n'êtes pas protégé contre les attaques de piratage de session ou de prise de contrôle de navigateur, et vous êtes désormais également vulnérable aux attaques liées aux téléphones. Plus d'informations à ce sujet plus tard.

Inconvénients

Cette technique est dangereusement vulnérable aux attaques MITM et à l'ingénierie sociale. Probablement plus que tout autre système d'authentification utilisé, y compris les mots de passe. L'étape d'authentification et l'étape d'initiation de la connexion sont intrinsèquement déconnectées en ce sens que le téléphone s'authentifiera correctement par rapport à tout code QR présenté, peu importe comment et où il est présenté à l'utilisateur.

Ainsi, par exemple, un site de phishing peut afficher un code QR de connexion authentique qui connecte l'attaquant au lieu de l'utilisateur. Gibson est convaincu que les utilisateurs verront le nom de la banque ou du magasin ou du site sur l'application téléphonique lors de l'authentification et exerceront donc une vigilance suffisante pour contrecarrer les attaques. L'histoire suggère que cela est peu probable, et l'attente la plus raisonnable est que voir le nom correct sur l'application rassurera à tort l'utilisateur en lui faisant croire que le site est légitime car il a pu déclencher la demande de connexion familière sur le téléphone. La prudence déjà imposée à 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 application probablement moins résistante à l'ingénierie sociale.

Ceci technique combine à la fois l’authentification et l’identité en un objet physique qui est fréquemment perdu ou volé. En ce sens, il s’agit plus 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), vous avez maintenant perdu la possibilité de Identifiez-vous. Les clés d'authentification ne sont pas révocables, donc sans récupération hors bande de chaque site, vous ne pouvez pas récupérer votre identité. Et même si la récupération hors bande existe, face à deux utilisateurs, l'un avec la possession de l'identité et l'autre sans, il peut être difficile de comprendre pourquoi l'opérateur du site devrait vous faire confiance.

Cette technique combine tous vos jetons d'authentification en une seule clé sauf si vous en créez d'autres manuellement. Cela fait de votre clé une cible extra-juteuse pour les attaquants. De plus, la clé est stockée sur votre téléphone, dont les appareils ont généralement une sécurité interne ridiculement poreuse. Combiner des cibles inhabituellement juteuses avec une sécurité de qualité inférieure ne vous met pas en sécurité.

Alternatives

L'aspect le plus problématique de ce schéma est sa faible comparaison avec les alternatives disponibles.

L'option la plus sécurisée universellement acceptée aujourd'hui est lastpass, keepass et autres ces systèmes de mot de passe intégrés au navigateur. En particulier, le chiffrement côté client réduit le besoin de faire confiance à un tiers. Et plus important encore, l'intégration du navigateur rend le phishing pratiquement impossible . LastPass ou KeePass ne rempliront le mot de passe que s'il est servi depuis le bon domaine, ce qui signifie que s'il est présenté avec un site malveillant, l'utilisateur n'aura pas accès à son mot de passe.

De plus, LastPass a récemment ajouté une fonctionnalité qui incite les utilisateurs à changer les mots de passe qui ne sont pas uniques au monde. Cela permet d'éviter la réutilisation du mot 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.

Schémas d'authentification à second facteur existants qui utiliser des téléphones ou des appareils similaires aident à protéger les connexions des utilisateurs aujourd'hui, le faites déjà de manière à ne pas vous rendre immédiatement vulnérable au vol d'identité si votre appareil est volé. La sécurité supplémentaire de l'authentification à deux facteurs réside dans le fait que ni l'appareil ni le mot de passe ne peuvent être utilisés s'ils sont volés sans l'autre. La technique de Gibson résiste largement à être incluse 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'il impose également. Ces coûts sont une partie fondamentale du système lui-même et ne peuvent probablement pas être résolus sans mettre au rebut toute la conception.

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

Mises à jour de Gibson

Gibson a récemment annoncé une protection supplémentaire contre le phishing, car il s'agissait d'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 à la place un agent d'authentification sur votre système (dans le navigateur, par exemple), le serveur peut alors vérifier que l'authentification La réponse provient de la même adresse IP que la demande d'authentification. C'est bien beau, mais le but de ce protocole est de déplacer votre identité sur votre téléphone portable. Si le seul moyen sûr d'utiliser le protocole est de ne pas utiliser sa fonctionnalité principale, nous devrions peut-être 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 utilisait la même adresse IP que votre ordinateur. Ce qui, bien sûr, ne peut pas le savoir car il ne connaît pas l'adresse IP de votre ordinateur.

Une meilleure solution

Comme indiqué précédemment, si la mesure d'authentification est dans votre navigateur , alors tout le problème de phishing est immédiatement résolu sans effort ni vérification de la part de l'utilisateur. Même l'utilisateur le moins capable ne peut pas être amené à s'authentifier sur le mauvais site car le jeton d'authentification du site est associé au nom de domaine et le navigateur n'autorisera pas l'authentification sur le mauvais domaine. C'est une technique déjà utilisée aujourd'hui, est complètement automatique, et ne nécessite pas la coopération du site ni aucune intelligence de la part de l'utilisateur.

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

En ce qui concerne les inquiétudes concernant la vulnérabilité de l'authentification côté navigateur aux attaques client-poste de travail: si le est vrai, 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 malwares peuvent (et le font déjà) attendre que vous vous authentifiiez par vous-même en utilisant votre technique ultra-sécurisée, puis envoyer silencieusement le trafic nécessaire pour «posséder» votre compte, le tout sans que vous voyiez quoi que ce soit qui cloche. Ni SQRL ni aucun autre système d'authentification ne peuvent protéger l'utilisateur d'un navigateur compromis, pas plus que les serrures de porte ne peuvent vous protéger d'un incendie domestique. L'achat de serrures ignifuges n'est pas une solution.

Et ensuite

Si vous recherchez une garantie absolue de protection contre l'usurpation d'identité, alors regardez le Fido Jeton U2F. Cette norme brille là où SQRL n'est pas à la hauteur et vous offre une immunité garantie contre les attaques MITM (par exemple, le phishing). Il le fait en authentifiant non seulement l'utilisateur, mais également le canal, de sorte que vous êtes assuré que (a) votre compte ne peut pas être authentifié sans le jeton, et aussi (b) votre jeton ne peut être utilisé que pour authentifier une connexion à la machine à laquelle il est attaché. Consultez cette réponse pour plus d'informations.

SQRL n'est certainement pas sans défauts, mais il est certainement supérieur à la plupart des solutions d'authentification primaires largement utilisées sur le Web aujourd'hui en termes de sécurité et (et c'est important) de convivialité. Permettez-moi de vous expliquer.

Idées fausses

Tout d'abord, permettez-moi de clarifier quelques-unes des idées fausses présentes dans certaines des autres réponses à cette question. Beaucoup de ces réponses sont obsolètes et ont été écrites avant les modifications apportées à la documentation SQRL qui abordent les problèmes qui y sont présentés, tandis que d'autres semblent mettre un accent excessif sur les failles de SQRL qui sont également présentes dans de nombreuses autres solutions d'authentification existantes largement utilisées, tandis que ignorant ses avantages. Alors clarifions quelques idées fausses ici, d'accord?

Mythe: SQRL nécessite de scanner les 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 déclare ce qui suit:

Trois façons d'y aller. . . smartphone en option:

Bien que l'inspiration originale 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: L'image du code QR est également un lien cliquable vers la même URL 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 qui apparaît sur la page de connexion d'un site Web et l'utilisateur est connecté à ce site.
• APPUYER SUR LE CODE sur un smartphone: Pour se connecter à un site Web SUR le smartphone, lorsque le code visuel SQRL est également de type URL link (en utilisant sqrl: // comme schéma), l'application SQRL installée sur le smartphone recevra ce lien et connectera en toute sécurité 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 n'importe quel ordinateur de bureau ou ordinateur portable, une application SQRL de bureau serait installée et s'enregistrerait pour recevoir des liens sqrl: // . (Ceci est similaire à la façon dont un programme de messagerie s'enregistre pour recevoir des liens mailto:). Cela permet aux utilisateurs sur leur bureau d'utiliser la même solution qu'ils utilisent sur leurs smartphones. Lorsqu'un site Web propose un code SQRL, l'utilisateur clique simplement sur le code avec le curseur de la souris et l'application SQRL installée localement s'affiche, demande son mot de passe SQRL, confirme le domaine, puis se connecte.

Mythe: la clé principale SQRL est stockée complètement non chiffrée et non protégée sur votre téléphone

Je ne sais pas pourquoi certaines personnes ont fait cette hypothèse, car cela me semble évident que ce ne serait pas le cas. La clé principale SQRL est protégée de la même manière que vous protégeriez une base de données de mots de passe: avec un mot de passe principal fort. Voler le téléphone d'un utilisateur ne vous donnerait pas automatiquement accès à son identité en ligne à moins que vous n'ayez également son mot de passe principal. Plus de détails sur la gestion des clés sont expliqués dans la page Gestion des clés côté client SQRL sur le site Web de SQRL.

Mythe: si votre clé principale est volée, vous ne pouvez pas changer votre 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 informations de connexion en cas de clé compromise. Cette fonctionnalité est connue sous le nom de verrouillage d'identité:

«Identity Lock» empêche le changement d'identité & autorise la récupération: Ceci est également suffisamment important 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 l'identité d'un utilisateur établie avec un serveur Web, le client SQRL est incapable de changer cette identité. Cela signifie que si le pire se produisait et qu'un mot de passe très faible et facile à deviner était utilisé, ou que le téléphone ou le bureau d'un utilisateur était piraté pour obtenir sa clé principale d'identité et son mot de passe, aucun tiers malveillant ne peut modifier l'identité en ligne de l'utilisateur pour les exclure de leurs propres comptes en ligne. De plus, en chargeant ensuite une "clé de déverrouillage d'identité" normalement hors ligne, le véritable propriétaire de son identité peut se retirer et remplacer son identité en ligne perdue ou volée pour essentiellement la reprendre à tout attaquant, ce qui rend leur identité précédente est inutile.

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

D'accord, c'est donc partiellement vrai . Lorsque vous utilisez SQRL en scannant un code QR, il y a en effet très peu de protection contre le phishing. À moins que l'utilisateur veille à ce que le site Web affiché dans la barre d'URL de son navigateur soit le même que celui affiché par l'application SQRL Client, il peut autoriser une session de connexion pour l'attaquant. C'est toujours 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 de mot de passe, mais pas aussi bien que d'autres solutions qui s'intègrent à le 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 avec lequel vous vous connectez, SQRL dispose de certaines protections contre le phishing. Ces protections sont expliquées sur le site Web de SQRL, dans la section Comment la SQRL peut contrecarrer les attaques de phishing. Il est également possible d'intégrer SQRL avec les navigateurs (éventuellement via des plugins) pour fournir une protection beaucoup plus forte contre les attaques de phishing; à égalité avec des solutions comme WebAuthn et les certificats clients.

Dans l'ensemble, je classerais SQRL à peu près 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 sur lequel l'utilisateur se connecte, mais offre une protection minimale lorsqu'il est installé sur un appareil différent.

Comparaison avec des alternatives

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

Mots de passe

SQRL est largement supérieur aux mots de passe à bien des égards. Non seulement il est plus pratique à utiliser une fois configuré, car les utilisateurs n'ont pas à se soucier de se souvenir ou de retaper plusieurs mots de passe différents pour chaque site, mais il protège également contre la réutilisation des mots de passe, les mots de passe faibles, l'enregistrement de frappe et, dans une certaine mesure, 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, pas aussi largement utilisé, nécessite plus de temps pour être configuré au départ, nécessite un certain effort pour transférer vers un nouvel appareil, et fournit un point de défaillance unique pour tous les comptes de l'utilisateur si la clé principale 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 une ancre de confiance unique et centralisée qui sert de sorte de proxy d'authentification entre les utilisateurs et les services individuels. Cependant, SQRL est supérieur aux gestionnaires de mots de passe de plusieurs manières.

Je pense que le principal avantage de SQRL par rapport aux 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, supposons qu'un utilisateur souhaite se connecter à un site Web à l'aide d'un ordinateur d'une bibliothèque publique. Avec un gestionnaire de mots de passe, il devrait soit accéder au mot de passe de ce site sur son téléphone et le retaper manuellement dans 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 in. Le premier scénario est peu pratique pour l'utilisateur et expose le mot de passe en clair de l'utilisateur pour ce site à l'ordinateur non approuvé (et à tout logiciel malveillant sur l'ordinateur non approuvé, y compris les enregistreurs de frappe). Le deuxième scénario est encore pire, car il est à la fois peu pratique et expose la base de données de mots de passe déchiffrée et le mot de passe principal de l'utilisateur à l'ordinateur non approuvé. Avec SQRL, l'utilisateur n'aurait qu'à scanner un code QR sur l'écran de l'ordinateur non approuvé, 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 approuvé.

Un autre avantage de SQRL par rapport aux gestionnaires de mots de passe est qu'il est plus facile de récupérer du pire des cas: la base de données de mots de passe de l'utilisateur / la clé principale volée. Avec un gestionnaire de mots de passe, vous devrez non seulement changer votre mot de passe sur chaque site, mais vous devrez également vous soucier du fait que l'attaquant modifie vos mots de passe (peut-être vous excluant de 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 facilite grandement l'exploitation du vol d'une base de données de mots de passe. Avec SQRL, se faire voler votre clé principale est toujours une situation terrible, mais l'attaquant n'a pas de liste de sites sur lesquels vous avez un compte (devant plutôt deviner), et ne peut pas changer votre mot de passe pour vous exclure de votre compte. Une fois que vous avez chargé votre clé de déverrouillage d'identité, il est également un peu plus pratique de modifier vos informations de connexion sur chaque site, car le client SQRL a la possibilité de le faire automatiquement pour chaque site que vous visitez lors de 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 sur les mots de passe traditionnels. Tant que les utilisateurs ont encore la possibilité d'une mauvaise sécurité, en réutilisant le même mot de passe sur chaque site, c'est quelque chose qui se produira toujours. Si SQRL commence à être largement adopté, les sites peuvent en fait commencer à supprimer 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 de mots de passe pour fonctionner.

En termes d'inconvénients, je ne peux pas penser à une situation où SQRL serait forcément 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 support des opérateurs de sites Web, alors que les gestionnaires de mots de passe ne nécessitent aucun support spécial de la part des services existants. Cela signifie que vous pouvez commencer à utiliser des gestionnaires de mots de passe dès maintenant, mais SQRL devra attendre que les sites l'implémentent avant de pouvoir l'utiliser. C'est un obstacle important à l'adoption.

Certificats clients

Le principal avantage de SQRL sur les certificats clients est la commodité. Les certificats clients sont actuellement compliqués à configurer, difficiles à transférer entre les ordinateurs et présentent des problèmes de confidentialité lorsque le même certificat est utilisé sur différents sites. Alors qu'en théorie, nous pourrions construire un système utilisant des certificats clients qui résoudraient ces problèmes, il y aurait aussi le problème d'une mauvaise intégration avec les interfaces utilisateur et les serveurs Web, qui sont des problèmes plus difficiles à résoudre. Je n'entrerai pas dans les détails ici, car il existe 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 d'exiger la participation d'un CA. Ceci est (potentiellement) coûteux et nécessite de faire confiance à l'autorité de certification tierce. De plus, si vous choisissez d'ignorer les autorités de certification et de signer vous-même vos certificats, vous devez régler le problème de la révocation des certificats. Les certificats clients présentent également les mêmes problèmes de sécurité et de commodité que les gestionnaires de mots de passe lorsque les utilisateurs souhaitent se connecter sur un ordinateur non approuvé; ils doivent transférer leur certificat sur l'ordinateur non approuvé, ce qui est à la fois peu pratique et expose potentiellement leur identité principale à des logiciels malveillants sur cet ordinateur.

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

Authentification à 2 facteurs

Je pensais juste que je mentionnerais ceci: SQRL et l'authentification à 2 facteurs ne sont pas mutuellement exclusives. SQRL remplace le premier facteur de 2FA: 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 norme W3C (enfin plus récente que SQRL) 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, il prend en charge l'utilisation du téléphone de l'utilisateur pour authentifier une session de connexion sur un appareil externe, en plus de quelques autres méthodes d'authentification (telles que les clés de sécurité de deuxième facteur).

C'est là que SQRL rencontre enfin son match, du moins du point de vue de la sécurité. Non seulement WebAuthn fournit les mêmes protections contre la réutilisation des mots de passe, les mots de passe faibles et le keylogging 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 lors de l'autorisation d'une session de connexion pour un PC sur lequel l'utilisateur n'a pas précédemment 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 tels que Blutooth ou NFC, communiquant plutôt avec le site Web que l'utilisateur utilise via un code QR à sens unique.

Du point de vue de la convivialité, les choses sont un peu plus compliquées. Au moins en surface, WebAuthn gagne à nouveau. Comme il s'agit d'un standard W3C qui a déjà des implémentations dans plusieurs navigateurs, en théorie les utilisateurs peuvent immédiatement commencer à utiliser WebAuthn sans avoir besoin d'installer de logiciel tiers. Dans la pratique cependant, la plupart des implémentations existantes de WebAuthn se concentrent sur son utilisation en tant que forme d'authentification de second facteur, ou comme moyen de ré-authentifier un utilisateur qui s'était 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 principal, WebAuthn manque encore plutôt d'implémentations viables.

D'autres considérations mineures incluent le fait que SQRL dispose d'une méthode intégrée pour la rotation des clés des comptes en cas de vol de clé principale , alors que WebAuthn s'appuie sur les sites Web pour implémenter son propre système de révocation des clés, et le fait que WebAuthn nécessite certains matériels optionnels (comme Bluetooth ou NFC) pour s'authentifier auprès d'une machine distante, alors que SQRL peut fonctionner sur n'importe quelle machine avec un écran fonctionnel .

Dans l'ensemble, je pense qu'il est très probable que WebAuthn finisse par rendre SQRL obsolète. SQRL a peut-être un peu de marge de manœuvre pour l'instant, mais WebAuthn bénéficie d'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 principal, je pense qu'il commencera à prendre le contrôle du Web très rapidement.

Avertissements

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 incertitudes de cette réponse soient résolues. La plupart des discussions se déroulent actuellement sur le groupe de discussion SQRL sur grc.com.

Comme d'habitude, prenez tout ce qui concerne Steve Gibson avec un camion de sel. Obligatoire attrition.org lien.

Regardons la description de Gibson de son protocole.

• Le code QR présenté à côté de l'invite de connexion contient l'URL du service d'authentification du site. L'URL comprend un long nombre aléatoire généré de manière sécurisée afin 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 appelé «nonce».)

• L'application d'authentification SQRL du smartphone hache cryptographiquement le nom de domaine du site saisi par la clé principale de l'utilisateur pour produire une paire de clés publiques spécifiques au site.

• L'application signe de manière cryptographique l'intégralité de l'URL contenue dans le code QR à l'aide de la clé privée spécifique au site. Étant donné que 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 envoie une requête HTTPS POST sécurisée au QR l'URL du code, 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 reconnaît la requête POST en renvoyant un HTTP standard " 200 OK ”sans autre contenu. L'application SQRL reconnaît la soumission réussie du code QR signé par l'utilisateur.

• Le site d'authentification a l'URL contenant le nonce qui est revenu de la page de connexion via le smartphone de l'utilisateur. Il a également une signature cryptographique de cette URL et 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 désormais authentifié par sa clé publique spécifique au site.

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

Vraisemblablement, cette clé principale 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 de logiciels malveillants spécialement conçus pour voler la clé principale.

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é principale est compromise . En supposant que vous suivez les bonnes pratiques de mot de passe 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 mot de passe unique s'il est compromis. Que se passe-t-il si votre clé principale est compromise? Vous devrez d'une manière ou d'une autre obtenir tous les sites avec lesquels vous vous êtes authentifié pour reconnaître que votre clé principale a été compromise. Le seul problème est que, puisque vous ne disposez d'aucun autre moyen de vous authentifier avec le site, comme les noms d'utilisateur ou les adresses e-mail, comment le site saura-t-il que c'est en fait vous qui essayez de révoquer la clé principale?

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.

SQRL est une solution pratique au problème du paradoxe nom d'utilisateur / mot de passe. (c'est-à-dire le compromis commodité / sécurité) sans faire appel à un tiers . Il fournit une alternative simple au modèle d'authentification le plus populaire (Username & Password), avec pratiquement aucun compromis sur la sécurité. Il est pratiquement tout aussi sûr de l’un des modèles d’authentification courants utilisés de nos jours, tant que vous êtes toujours soucieux de la sécurité . Si vous utilisez SQRL, cela ne signifie pas que vous ne pouvez pas suivre les meilleures pratiques de sécurité telles que combiner cela avec l'authentification multifacteur pour les comptes importants.

Il est important de pas le manquer le point de SQRL. SQRL lui-même ne fournit pas nécessairement une sécurité meilleure ou pire. Si l'ordinateur / téléphone lui-même est compromis, ou si l'utilisateur est victime d'un hameçonnage, il s'agit d'une attaque par canal secondaire au lieu d'une faute directe de SQRL lui-même. Toutes les méthodes d'authentification conventionnelles posent ce problème d'attaques par canal secondaire. Le pavé unique incassable est également vulnérable aux attaques par canal latéral telles que la compromission du pavé lui-même, ou une mauvaise sécurité ou implémentation environnante.

Si vous avez écouté la proposition originale de l'idée sur le podcast de Steve Gibson, suivi par le Q&A, la plupart des préoccupations soulevées sur ce fil de discussion ont été résolues. Aussi, Steve a dit ainsi lui-même que cette idée très "simple" et "ingénieuse" (ses mots) devrait être "vérifiée" et "martelée" par des experts en sécurité car seul le temps nous dira si c'est une solution sûre.

En conclusion, la plupart des arguments contre SQRL sortent du domaine de SQRL lui-même, et sont plutôt des problèmes avec des humains pratiquant une mauvaise sécurité. SQRL n'introduit pas de nouvelle classification des problèmes que nos méthodes d'authentification traditionnelles n'ont pas déjà.

SQRL est excellent s'il est utilisé de manière appropriée par des personnes soucieuses de la sécurité. Vous devez comprendre que il y a toujours un compromis entre la commodité et la sécurité , et cette solution est probablement le meilleur équilibre des deux que j'ai vus.

Je suis d'accord avec les autres commentaires dans une certaine mesure, mais je pense qu'il y a des avantages:

Pour activer SQRL pour vous, vous devez créer votre clé principale et la stocker sur votre téléphone. TERMINÉ. À partir de cette seconde, vous pourrez vous connecter à N'IMPORTE QUEL site Web qui utilise "SQRL". Et ce serait une connexion anonyme - tant que vous décidez de ne pas fournir d'informations supplémentaires.

C'est BEAUCOUP plus simple que de travailler avec votre propre certificat; ou en créant des comptes d'utilisateurs explicites (vous demandant probablement de fournir une adresse e-mail valide). Peut-être que je n'utiliserais pas la même clé principale pour mes comptes bancaires, Amazon, ... mais surtout pour ces situations «je voudrais publier quelque chose ici» ... parfait. Plus de "s'il vous plaît laissez google ou facebook ou tout autre site savoir que vous voulez publier ici".

SQRL n'apporte aucune amélioration révolutionnaire. Les codes QR sont un format de code-barres optique utile pour la distribution de contenu court - rien de plus.

Toute situation de "connexion automatique" que SQRL tente de résoudre pourrait simplement utiliser un certificat client stocké sur le mobile à la place.

En théorie, un code-barres QR sur une page HTTPS pourrait renvoyer une version serveur signée ou chiffrée du certificat client (ou un identifiant similaire) comme précédemment connu par le serveur, mais pourquoi? Pour l'expiration des informations d'identification? Le site pourrait simplement rejeter directement un identifiant expiré.

Le plus gros problème de sécurité que j'ai avec ce protocole est: Réinventer la roue carrée.

Mise à jour

En lisant de nouvelles réponses et commentaires, j'aimerais souligner combien il est facile de faire quelque chose de similaire à SQRL grâce à une simple automatisation de technologie existante mature :

1. Le site Web demande à tous les CAPTCHA ou à une vérification similaire «Je suis un humain». Une fois que l'utilisateur s'est conformé (POSTed), le site Web renvoie un HTTP 403.7 - Certificat client requis ou une erreur 403 vanille.
2. Les pages 403 personnalisées sont assez faciles à configurer et peuvent être assez jolies et conviviales. Pourrait même amorcer la fonctionnalité requise ci-dessous d'une manière similaire aux invites "Adobe Reader requis" sur de nombreux sites Web.
3. La page 403 personnalisée comprend des balises auxquelles un plug-in de navigateur personnalisé réagit. Appelons ce plugin personnalisé `` compatible S403L '' dans l'esprit de `` conformité SQRL ''.
4. Le plugin S403L génère un certificat client standard, qui est sécurisé dans le cache de certificat crypté habituel du navigateur (ou un troisième- cache de partie si le chiffrement du keystore de votre navigateur est nul). Le plugin crée un CSR standard pour le certificat client et envoie le CSR à l'URL spécifiée dans le balisage 403. (par exemple <s403l ref = "https://www.example.com/S403L" / > )
5. Le serveur compatible S403L utilise l'identifiant de session de l'utilisateur (récupéré à partir des cookies ou de la chaîne de requête) pour créer une continuité avec l'étape 1, puis renvoie le CSR signé par le serveur. L'authentification générale du serveur acceptera tout certificat client qui a été signé par le serveur (et qui répondait donc aux critères d'enregistrement exigés à l'étape 1).
6. Le plugin S403L stocke ce certificat client signé dans le cache du navigateur. À partir de là, le navigateur standard sans assistance de plug-in peut "se connecter automatiquement" au serveur de la manière SSL / TLS standard jusqu'à l'expiration du certificat.

Les paramètres "mobile" et "visuel" La nature de SQRL est quelque peu erronée car elle ne fournit pas d'authentification à deux facteurs détachée et vous avez maintenant besoin de deux ordinateurs pour naviguer sur Internet au lieu d'un. À moins que vous ne dirigiez la webcam USB de votre ordinateur vers son propre moniteur.

Les compromis entre les mots de passe et les certificats sont bien définis dans la communauté de la sécurité: les mots de passe tiennent dans un cerveau humain; les certificats ne rentrent pas dans un cerveau humain ( généralement) mais peuvent avoir une entropie folle et de bonnes fonctionnalités de gestion PKI (expiration, révocation, extensions de politique, etc.). SQRL ne s'intègre proprement dans aucun des deux camps; et s'il dérive vers le camp moins humain et plus informatique qu'il semble être - il a des années de développement et d'analyse de la sécurité pour répéter les fonctionnalités X.509 existantes.

Je voudrais répondre à la première question: "l'un des problèmes auxquels je pense est que si le lecteur QR est compromis, d'afficher www.google.com au lieu de www.nsa-super-secret-place.gov / 123 ":

La clé principale est utilisée comme source dans HMAC avec l'adresse du site Web (FQDN). Ainsi, bien que le code QR puisse encoder une URL complètement différente, le protocole ne révélera PAS le code d'authentification qui serait normalement envoyé à www.google.com (dans l'exemple).

Deuxièmement, de nombreux contributeurs oublient les objectifs clés lors de l'élaboration de cette idée:

1. anonymat en n'utilisant pas de tiers
2. facilité d'utilisation
3. pas besoin de taper des identifiants secrets sur des ordinateurs non fiables

Je crois que les protocoles les résolvent complètement!

Cependant, il existe des compromis qui en proviennent du premier objectif. Si aucun tiers n'est impliqué dans l'authentification, comment peut-on révoquer ses informations d'authentification? De plus, la sécurité de la clé principale est une préoccupation évidente. J'envisage que cela soit bien protégé par les futurs appareils mobiles dans un HSM comme une puce. Jusque-là, la clé est juste un appareil mobile à broche de fichier, protégé par un mot de passe, bien que PBDKF2 garantisse qu'il est très lent de le forcer.