Le SQRL pourrait-il vraiment être aussi sûr qu'on le dit?
Je viens de tomber https://www.grc.com/sqrl/sqrl.htm
Avec Secure QR Login, votre téléphone prend le code QR affiché sur la page de connexion d'un site Web. . . . et VOUS êtes connecté en toute sécurité.
Cela semble être assez génial - l'un des problèmes auxquels je peux penser est que si le lecteur QR est compromis, pour afficher www.google.com au lieu de www.nsa-super-secret-place.gov/123. Quels autres problèmes ce système rencontre-t-il?
Comme d'habitude, prenez tout ce qui concerne Steve Gibson avec un camion de sel. Obligatoire attrition.org lien .
Jetons un coup d'œil à la description de Gibson de son protocole.
Le code QR présenté près de l'invite de connexion contient l'URL du service d'authentification pour le 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écifique au site.
L'application signe cryptographiquement l'URL complète 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 émet une requête HTTPS sécurisée POST vers l'URL du code QR, qui est le service d'authentification pour le 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 possède l'URL contenant le nonce qui est revenu de la page de connexion via le smartphone de l'utilisateur. Il possède é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 forme de malware conçu spécifiquement 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 produit lorsque la clé principale est compromise. En supposant que vous suivez de bonnes pratiques de mots de passe de 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é principale est compromise? Vous devrez en quelque sorte 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 pour vous authentifier auprès du site, tels que des noms d'utilisateur ou des adresses e-mail, comment le site saura-t-il que c'est 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.
Dans l'ensemble, le protocole ne semble pas accroître la sécurité des technologies existantes. Si vous cherchez le meilleur moyen de protéger votre identité en ligne, cela ne fait aucun doute pas lui . Mais passons en revue les avantages et les inconvénients:
Les avantages
Il est impossible de "partager" un mot de passe au 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 possible.
Les informations d'identification ne sont pas stockées sur votre ordinateur. Cela vous protège contre un petit sous-ensemble d'attaques dirigées par le poste 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 tout type de piratage de session ou d'attaque par le navigateur, et vous êtes maintenant aussi sensible aux attaques liées au téléphone. Plus sur cela plus tard.
Désavantages
Cette technique est dangereusement vulnérable 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 d'initiation 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 sera 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 feront donc preuve d'une vigilance suffisante pour contrecarrer les attaques. L'histoire suggère que cela est peu probable, et l'attente la plus raisonnable est 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 car il a pu déclencher la demande de connexion familière sur le téléphone. La prudence déjà lancée aux chefs d'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 par nature à l'ingénierie sociale.
Cette technique combine à la fois l'authentification et l'identité en un objet physique qui est fréquemment perdu ou volé. En ce sens, c'est plus comme un passeport plutôt qu'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 vous imiter, mais sans une deuxième copie sur un deuxième téléphone (peu probable), maintenant vous avez perdu le capacité à vous identifier. 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 s'il existe une récupération hors bande, face à deux utilisateurs, l'un avec 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é sauf si vous en créez manuellement d'autres. Cela fait de votre touche unique 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. La combinaison d'objectifs inhabituellement juteux avec une sécurité inférieure aux normes ne vous rend pas sûr.
Alternatives
L'aspect le plus problématique de ce programme est sa médiocre comparaison avec les alternatives disponibles.
L'option universellement acceptée la plus sûre aujourd'hui est lastpass, keepass et d'autres systèmes de mots de passe intégrés au navigateur. En particulier, le chiffrement côté client réduit la nécessité de faire confiance à un tiers. Et plus important encore, l'intégration du navigateur rend le phishing pratiquement impossible . LastPass ou KeePass ne remplira le mot de passe que s'il est servi à partir du domaine correct, ce qui signifie que s'il est présenté avec un site malveillant, l'utilisateur n'aura pas accès à son mot de passe.
En outre, LastPass a récemment ajouté une fonctionnalité qui incite les utilisateurs à modifier des mots de passe qui ne sont pas uniques au monde. 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 schémas d'authentification à deux facteurs existants qui utilisent des téléphones ou des appareils similaires contribuent à protéger les connexions des utilisateurs aujourd'hui de manière à ne pas vous rendre immédiatement vulnérable au vol d'identité en cas de vol de votre appareil. 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 à son 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 suffisamment d'avantages pour surmonter les coûts de sécurité supplémentaires qu'elle impose également. Ces coûts sont une partie fondamentale du programme lui-même et ne peuvent probablement pas être calculés sans abandonner la conception entière.
Vous pourriez dire que c'est mieux que rien, mais vous ne pouvez pas dire 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 disposez d'un agent d'authentification sur votre système (dans le navigateur, par exemple), le serveur peut vérifier que l'authentification la réponse provient de la même IP que la demande d'authentification. C'est bien et bien, mais le but de ce protocole est de déplacer votre identité vers votre téléphone portable. Si le seul moyen sûr d'utiliser le protocole est de ne pas utiliser sa fonction principale, alors nous devrions peut-être repenser ce que nous essayons d'accomplir.
En théorie, 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 IP que votre ordinateur. Bien sûr, il 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 se trouve dans votre navigateur, , l'ensemble du 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. Il s'agit d'une technique déjà utilisée aujourd'hui, totalement automatique et ne nécessitant 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 (comme une clé variant dans le temps sur un téléphone portable) qui, encore une fois, est déjà disponible et utilisé aujourd'hui, ce qui vous protège (plus particulièrement) contre les erreurs de la pièce du site ou de l'entreprise de destination.
En ce qui concerne les préoccupations concernant l'authentification côté navigateur vulnérable aux attaques client-poste de travail: bien que le soit 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 logiciels malveillants peuvent (et le font déjà) attendre que vous vous authentifiiez par vous-même à l'aide de 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 de mal. Ni SQRL ni aucun autre système d'authentification ne peut protéger l'utilisateur d'un navigateur compromis, pas plus que les serrures de porte ne peuvent vous protéger contre un incendie de maison. L'achat de serrures ignifuges n'est pas une solution.
Où ensuite
Si vous recherchez un garantie absolue de protection contre l'emprunt d'identité , alors regardez le jeton Fido U2F. Cette norme brille là où SQRL échoue et vous donne une immunité garantie contre les attaques MITM (par exemple, le phishing). Il le fait en authentifiant non seulement l'utilisateur, mais aussi le canal, vous êtes donc 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é. Voir 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 principales 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. Bon nombre de ces réponses sont obsolètes et ont été écrites avant les modifications apportées à la documentation SQRL qui résolvent les problèmes qui y sont présentés, tandis que d'autres semblent insister indûment sur les failles dans 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 numérisation 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 la SQRL indique ce qui suit:
Trois façons d'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: il suffit de faire de l'image du code QR également un lien cliquable vers le même URL encodée dans le code QR. Cela donne trois façons de se connecter:
- Scannez 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.
- APPUYEZ SUR LE CODE sur un smartphone: Pour vous connecter à un site Web SUR le smartphone, lorsque le code SQRL visuel 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 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'inscrirait lui-même 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 de leur bureau d'utiliser la même solution que celle qu'ils utilisent sur leur smartphone. Lorsqu'un site Web propose un code SQRL, l'utilisateur clique simplement sur le code avec le curseur de sa souris et l'application SQRL installée localement apparaîtra, vous demandera son mot de passe SQRL, confirmera le domaine, puis se connectera.
Mythe: la clé principale SQRL est stockée entièrement 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 il 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 --- SQRL Client-Side Key Management sur le site Web de SQRL.
Mythe: si votre clé principale est volée, vous ne pouvez pas modifier vos informations de connexion
C'est également faux. SQRL fournit un moyen intégré pour permettre au titulaire du compte authentique de mettre à jour ses informations de connexion dans le cas d'une clé compromise. Cette fonctionnalité est connue sous le nom de verrouillage d'identité:
"Verrouillage d'identité" empêche le changement d'identité et permet la récupération: Ceci est également suffisamment important pour mériter sa propre page de description détaillée: " Le verrouillage d'identité protocol ”(page 4 dans le bloc de liens en bas de cette page.) Une fois que l'identité d'un utilisateur a été établie avec un serveur Web, le client SQRL est incapable pour changer cette identité. Cela signifie que si le pire s'est produit et qu'un mot de passe très faible et facilement deviné a été utilisé, ou que le téléphone ou le bureau d'un utilisateur a été piraté pour obtenir sa clé principale et son mot de passe d'identité, aucun tiers malveillant ne peut modifier l'identité en ligne de l'utilisateur pour le verrouiller de ses 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 de tout attaquant, rendant son identité précédente inutile.
Plausible: SQRL est plus vulnérable au phishing que les solutions d'authentification existantes
D'accord, c'est donc en fait partiellement true. 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 ne 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 pourrait autoriser une session de connexion pour l'attaquant. C'est encore mieux que les mots de passe, où ils donneraient au phishing un accès permanent à leur compte (et à tous les autres comptes qu'ils ont ailleurs 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 avec 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 que celui avec lequel vous vous connectez, SQRL dispose de certaines protections contre le phishing. Ces protections sont expliquées sur le site Web de SQRL, sous la section Comment SQRL peut contrecarrer les attaques de phishing . Il y a aussi la possibilité d'intégrer SQRL aux navigateurs (éventuellement via des plugins) pour fournir une protection beaucoup plus forte contre les attaques de phishing; au même niveau que 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 auquel l'utilisateur se connecte, mais offre une protection minimale lorsqu'il est installé sur un autre appareil.
Comparaison avec des 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 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 des clés et, dans une certaine mesure, Hameçonnage.
Les inconvénients du 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 la configuration initiale, nécessite un certain effort de transfert 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. Il existe cependant deux façons que SQRL est supérieur aux gestionnaires de mots de passe.
Le principal avantage que je pense que SQRL a 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 partiellement fiables. Par exemple, supposons qu'un utilisateur souhaite se connecter à un site Web à l'aide d'un ordinateur dans 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 en utilisant son mot de passe principal, puis se connecter dans. Le premier scénario n'est pas 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 gênant et expose la totalité de la base de données de mots de passe et du mot de passe maître 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 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 approuvé.
Un autre avantage de SQRL sur les 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/clé principale de l'utilisateur est 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 inquiéter du fait que l'attaquant modifie vos mots de passe (vous bloquant éventuellement 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 l'exploitation du vol d'une base de données de mots de passe. Avec SQRL, le vol de votre clé principale est toujours une situation terrible, mais l'attaquant n'a pas de liste de sites sur lesquels vous avez un compte (à deviner à la place) et ne peut pas changer votre mot de passe pour vous verrouiller hors de votre compte. Une fois que vous avez chargé votre clé de déverrouillage d'identité, il est également 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 un formulaire 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 toujours la possibilité d'une sécurité médiocre, 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 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 de mots de passe pour fonctionner.
En termes d'inconvénients, je ne peux vraiment 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 support des opérateurs de sites Web, tandis que les gestionnaires de mots de passe ne nécessitent aucun support spécial des services existants. Cela signifie que vous pouvez commencer à utiliser les gestionnaires de mots de passe dès maintenant, mais SQRL devra attendre que les sites l'implémentent avant de pouvoir être utilisé. Il s'agit d'un obstacle important à l'adoption.
Certificats clients
Le principal avantage de SQRL sur les certificats clients est celui de la commodité. Les certificats clients sont actuellement compliqués à configurer, difficiles à transférer entre ordinateurs et ont des problèmes de confidentialité lorsque le même certificat est utilisé sur différents sites. Alors que théoriquement, nous pourrions construire un système utilisant des certificats clients qui résoudrait ces problèmes, il y aurait également le problème d'une mauvaise intégration avec les interfaces utilisateur et les serveurs Web des sites Web, qui sont des problèmes plus difficiles à résoudre. Je n'entrerai pas dans trop de détails ici, car il y a déjà un excellent article sur les problèmes d'utilisation des certificats clients sur browserauth.net.
En termes de sécurité, les certificats clients ont l'inconvénient de nécessiter l'intervention d'une 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 d'auto-signer vos certificats, vous devez résoudre 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 fiable; ils doivent transférer leur certificat 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 trouve une meilleure solution conviviale utilisant des certificats clients qui résout (au moins la plupart) ces problèmes, je ne pense pas que les certificats clients soient un sérieux concurrent de SQRL (ou, d'ailleurs, de mots de passe).
Authentification à 2 facteurs
Je pensais juste mentionner ceci: l'authentification SQRL et à 2 facteurs sont pas s'excluent mutuellement. 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 en utilisant le 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 (telles que les clés de sécurité de 2e facteur).
C'est là que la SQRL rencontre enfin son match, du moins du point de vue de la sécurité. Non seulement WebAuthn offre 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 connexion session pour un PC sur lequel l'utilisateur n'a pas encore configuré le logiciel client de l'authentificateur. Cela est possible car dans cette situation, WebAuthn communique directement avec le navigateur de l'utilisateur à l'aide de 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 l'utilisabilité, les choses sont un peu plus compliquées. En surface au moins, WebAuthn gagne à nouveau. Parce qu'il s'agit d'une norme W3C qui a déjà des implémentations dans plusieurs navigateurs , en théorie, les utilisateurs peuvent immédiatement commencer à utiliser WebAuthn sans avoir à installer de logiciel tiers. Dans la pratique cependant, la plupart des implémentations WebAuthn existantes 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 principal, WebAuthn manque encore d'implémentations viables.
D'autres considérations mineures incluent le fait que SQRL dispose d'une méthode intégrée pour faire pivoter les clés de comptes en cas de vol d'une clé principale, tandis que WebAuthn s'appuie sur des sites Web pour implémenter son propre système de révocation des clés, et le fait que WebAuthn requiert certaines matériel optionnel (comme Bluetooth ou NFC) afin de s'authentifier auprès d'une machine distante, tandis que SQRL peut fonctionner sur n'importe quelle machine avec un affichage fonctionnel.
Dans l'ensemble, je pense qu'il est très probable que WebAuthn rendra finalement SQRL obsolète. SQRL a peut-être un peu de marge de manœuvre pour le moment, mais WebAuthn bénéficie d'un soutien beaucoup plus fort de la part des fournisseurs de navigateurs, des opérateurs de site 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 m'attends à ce qu'il commence à prendre le contrôle du Web très rapidement.
Avertissements
SQRL est toujours en cours de développement actif, donc le matériel présenté dans cette réponse est susceptible de changer. À mesure que le développement se poursuit, je m'attends à ce que certaines des vulnérabilités et des incertitudes de cette réponse soient corrigées. La plupart des discussions se déroulent actuellement sur le newsgroup SQRL sur grc.com.
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 utiliser de tierce partie . Il fournit une alternative simple au modèle d'authentification le plus populaire (nom d'utilisateur et mot de passe), avec virtuellement aucun compromis sur la sécurité. Il est pratiquement tout aussi sûr de tous les modèles d'authentification courants utilisés aujourd'hui 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 en combinant cela avec l'authentification multifacteur pour les comptes importants.
Il est important de ne pas manquer le point de SQRL. SQRL lui-même ne fournit pas nécessairement une sécurité meilleure ou pire. Si l'ordinateur/le téléphone lui-même est compromis, ou que l'utilisateur est trompé, il s'agit d'une attaque par canal latéral à la place d'une faute directe du SQRL lui-même. Chaque méthode d'authentification conventionnelle a ce problème d'attaques de canal latéral Le pad unique incassable est également vulnérable aux attaques de canal latéral telles que la compromission du pad lui-même, ou un mauvais environnement sécurité ou implémentations.
Si vous avez écouté la proposition originale de l'idée sur Steve Gibson's podcast , suivie des Q&R, de nombreuses préoccupations soulevées sur ce fil de pile ont été résolues. En outre, Steve a dit lui-même que cette idée très "simple" et "ingénieuse" (ses mots) devrait être "examinée" et "martelée" par des experts en sécurité, car seul le temps nous dira s'il s'agit d'une solution sûre.
En conclusion, la plupart des arguments contre SQRL ne relèvent pas du domaine de SQRL lui-même, et sont plutôt des problèmes avec les humains pratiquant une sécurité médiocre. SQRL n'introduit pas de nouvelle classification des problèmes que nos méthodes d'authentification traditionnelles ne possèdent pas déjà.
SQRL est excellent s'il est utilisé de manière appropriée par des personnes soucieuses de leur sécurité. Vous devez comprendre que il y a toujours un compromis entre commodité et sécurité , et cette solution est probablement le meilleur équilibre du j'ai vu deux.
Je suis d'accord avec les autres commentaires dans une certaine mesure, mais je pense qu'il y a certains 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 à TOUT site Web utilisant "SQRL". Et ce serait une connexion anonyme - tant que vous décidez de ne pas fournir d'autres informations.
C'est BEAUCOUP plus facile 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 poster quelque chose ici" ... parfait. Pas plus "s'il vous plaît laissez google ou facebook ou n'importe quel site savoir que vous souhaitez 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 à la place un certificat client stocké sur le mobile.
Hypothétiquement, un code-barres QR sur une page HTTPS pourrait renvoyer une version signée ou chiffrée du serveur 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 justificatif expiré.
Le plus gros problème de sécurité que j'ai avec ce protocole est donc: Réinventer la roue carrée .
Update
En lisant de nouvelles réponses et commentaires, je voudrais souligner à quel point il est facile de faire quelque chose de similaire au SQRL grâce à une automatisation simple de une technologie existante mature:
- Le site Web demande des 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 - Client Certificate Requiredou une erreur Vanilla 403. - Les pages 403 personnalisées sont assez faciles à configurer et peuvent être assez jolies et conviviales. Pourrait même bootstrap les fonctionnalités requises ci-dessous d'une manière similaire aux invites "Adobe Reader requis" sur de nombreux sites Web.
- La page 403 personnalisée comprend un balisage auquel un plug-in de navigateur personnalisé réagit. Appelons ce plugin personnalisé "conforme S403L" dans l'esprit de la "conformité SQRL".
- Le plug-in S403L génère un certificat client standard, qui est sécurisé dans le cache de certificat de navigateur chiffré habituel (ou dans un cache tiers si le chiffrement du fichier de clés de votre navigateur est nul). Le plugin crée une CSR standard pour le certificat client et envoie la CSR à l'URL spécifiée dans le balisage 403. (par exemple.
<s403l ref="https://www.example.com/S403L" />) - 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 retourne le CSR tel que signé par le serveur. L'authentification générale du serveur acceptera tout certificat client signé par le serveur (et répondant ainsi aux critères d'enregistrement exigés à l'étape 1).
- Le plug-in S403L stocke le certificat client signé dans le cache du navigateur. A partir de là, le navigateur standard sans assistance de plugin peut se "connecter automatiquement" au serveur de la manière SSL/TLS standard jusqu'à l'expiration du certificat.
La nature "mobile" et "visuelle" de SQRL est une sorte de mauvaise orientation car elle ne fournit pas d'authentification à deux facteurs et vous avez maintenant besoin de deux ordinateurs pour naviguer sur Internet au lieu d'un. Sauf si vous pointez la webcam USB de votre bureau sur 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 s'inscrivent dans un cerveau humain; les certificats ne rentrent pas dans le cerveau humain ( généralement ) mais peuvent avoir entropie folle et de bonnes fonctionnalités de gestion des PKI (expiration, révocation, extensions de politique, etc.). SQRL s'intègre parfaitement dans aucun des deux camps; et s'il dérive vers le camp le moins humain plus informatique qu'il semble être - il a des années de développement et d'analyse de 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 peux penser est que si le lecteur QR est compromis, afficher www.google.com au lieu de www.nsa-super-secret-place.gov/123" :
La clé principale est utilisée comme graine dans HMAC avec l'adresse du site Web (FQDN). Ainsi, bien que le code QR puisse coder 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:
- anonymat en n'utilisant pas un tiers
- facilité d'utilisation
- pas besoin de taper des informations d'identification secrètes sur des ordinateurs non approuvés
Je pense que les protocoles traitent ces problèmes dans leur intégralité!
Cependant, il y a des compromis qui viennent en fait du premier objectif. Si aucun tiers n'est impliqué dans l'authentification, comment 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 une puce de type HSM. Jusque-là, la clé n'est qu'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 brutalement.