Comme dhabitude, prenez tout ce qui touche à Steve Gibson avec un camion de sel. Obligatoire attrition.org lien .

Jetons un œil à la description de Gibson de son protocole.

• Le code QR présenté à côté de la connexion invite contient lURL du service dauthentification du site. LURL comprend un long numéro 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».)

• Lapplication dauthentification SQRL du smartphone hache cryptographiquement le nom de domaine du site saisi par lutilisateur « s master key pour produire une paire de clés publiques spécifiques au site.

• Lapplication signe de manière cryptographique lintégralité de lURL contenue dans le code QR à laide de la clé privée spécifique au site. Étant donné que lURL comprend un long nombre aléatoire sécurisé (le nonce), la signature est unique pour ce site et ce code QR.

• Lapplication envoie une requête HTTPS POST sécurisée au QR lURL du code, qui est le service dauthentification du site. Le POST fournit la clé publique spécifique au site et la signature cryptographique correspondante de lURL du code QR.

• Le site Web dauthentification reçoit et accuse réception de la requête POST en renvoyant un HTTP standard «200 OK» sans autre contenu. Lapplication SQRL reconnaît la soumission réussie du code QR signé par lutilisateur.

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

Le la chose la plus importante qui me saute aux yeux est lutilisation dune  » clé principale  » par lutilisateur. Si je lis correctement le protocole, cette clé principale unique contrôle toute lidentité en ligne de lutilisateur …

Vraisemblablement, cette clé principale est stockée dans le téléphone de lutilisateur dans une base de données dapplication. Ce qui ouvre un énorme vecteur dattaque 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 lorsquun mot de passe est compromis et ce qui se passe lorsque la clé principale est compromis. En supposant que vous suivez les bonnes pratiques de mot 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 sil est compromis. Que se passe-t-il si votre clé principale est compromise? devra dune manière ou dune 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 vous ne disposez daucun autre moyen de vous authentifier auprès du site, comme les noms dutilisateur ou adresses e-mail, comment le site saura-t-il que cest 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 noffre aucun avantage par rapport aux méthodes.

Comme nts

•  » Si vous ‘ suivez les bonnes pratiques en matière de mots de passe  » est une énorme mise en garde, et la plupart des internautes ne ‘ ne le font pas.Une partie de la promesse de SQRL ‘ est de réduire les utilisateurs ‘ qui doivent rester au courant des meilleures pratiques. De plus, la spécification SQRL demandera que la clé principale soit stockée cryptée avec un mot de passe principal et sera impossible à forcer (réglé pour prendre ~ 60s pour un essai). Obtenir le mot de passe sera souvent non trivial car SQRL favorise lauthentification hors bande (cest-à-dire que lenregistrement au clavier dune machine piratée ne vous aidera pas ‘ toujours). Ainsi, bien que les conséquences dun compromis complet soient élevées, la probabilité de compromis est quelque peu faible.
• SQRL peut encore présenter des défauts qui doivent être corrigés, mais prétend résoudre un certain nombre de problèmes rencontrés dans les approches dauthentification existantes, et toute critique de SQRL qui laffirme  » noffre aucun avantage  » devrait inclure des réfutations de ces affirmations au lieu de sattendre à ce que lassertion soit aveuglément acceptée.
• > Comme tout ce qui sort de Gibson , ce schéma SRQL est très imparfait et noffre aucun avantage par rapport aux méthodes conventionnelles. — Cela ‘ ne semble pas aider à répondre à la question, et je pense en fait que vous avez des problèmes avec la technologie à cause de qui la inventée. Certains des points que vous avez mentionnés comme étant des failles sont en fait traités par la  » spec « . Par exemple, SQRL lui-même ne ‘ t mentionne comment la clé principale est stockée, mais les commentaires de Steve Gibson ‘ à ce sujet sont qu’un mobile le client, par exemple, le chiffrerait avec un mot de passe principal en utilisant un scrypt qui prend en moyenne 60 s à exécuter.
• Gibson aborde explicitement la protection de la clé principale.
• Attendez un deuxième. Vous assimilez votre clé principale SQRL volée à une de vos clés LastPass volée. Est-ce que ‘ ne serait pas une meilleure analogie de lassimiler à toute votre base de données de mots de passe LastPass déchiffrée volée?

Dans lensemble, le protocole ne semble pas accroître la sécurité par rapport à la technologie existante. Si vous cherchez le meilleur moyen de protéger votre identité en ligne, cest sans aucun doute pas cela . Mais passons en revue le pour et le contre:

Avantages

Il est impossible de  » partager  » un mot de passe au sens strict où un site Web malveillant ne peut pas utiliser lauthentification fournie à un site pour se connecter à un autre site.

Une attaque par force brute contre le jeton dauthentification est impossible.

Les identifiants ne sont pas stockés sur votre ordinateur. Cela vous protège contre un petit sous-ensemble de 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. 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 maintenant également vulnérable aux attaques liées aux téléphones. Plus dinformations à ce sujet plus tard.

Inconvénients

Cette technique est dangereusement sensible aux attaques MITM et à lingénierie sociale. Probablement plus que tout autre schéma dauthentification utilisé, y compris les mots de passe. Létape dauthentification et létape dinitiation de la connexion sont intrinsèquement déconnectées dans le sens où le téléphone sauthentifiera correctement par rapport à tout code QR présenté, peu importe comment et où il est présenté à lutilisateur.

Ainsi, par exemple, un site de phishing peut afficher un code QR de connexion authentique qui connecte lattaquant à la place de lutilisateur. Gibson est convaincu que les utilisateurs verront le nom de la banque ou du magasin ou du site sur lapplication téléphonique lors de lauthentification et exerceront donc une vigilance suffisante pour contrecarrer les attaques. Lhistoire suggère que cela est peu probable, et lattente la plus raisonnable est que voir le nom correct sur lapplication rassurera à tort lutilisateur 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 dauthentification comme celle-ci, ce qui rend cette application probablement moins résistante à lingénierie sociale.

Cette technique combine à la fois lauthentification et lidentité dans un objet physique qui est fréquemment perdu ou volé. En ce sens, il  » s ressemble plus à un passeport quà un mot de passe. Toute personne en possession de votre téléphone est soudainement exclusivement en possession de votre identité: non seulement lattaquant 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 capacité de vous identifier.Les clés dauthentification 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 sil existe une récupération hors bande, face à deux utilisateurs, lun avec la possession de lidentité et lautre sans, il peut être difficile de comprendre pourquoi lopérateur du site devrait vous faire confiance.

Cette technique combine tous vos jetons dauthentification en une seule clé sauf si vous en créez dautres 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 rend pas sûr.

Alternatives

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

Loption la plus sécurisée universellement acceptée aujourdhui est lastpass, keepass et dautres 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 surtout, lintégration du navigateur rend le phishing pratiquement impossible . LastPass ou KeePass ne rempliront le mot de passe que sil est servi depuis le bon domaine, ce qui signifie que sil est présenté avec un site malveillant, lutilisateur naura pas accès à son mot de passe.

De plus, LastPass a récemment ajouté une fonctionnalité qui incite les utilisateurs à changer 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 aujourdhui sur les sites existants, sans linsécurité supplémentaire que son schéma implique.

Les schémas dauthentification de second facteur existants qui utilisent des téléphones ou des appareils similaires aident à protéger les connexions des utilisateurs aujourdhui le font déjà dune manière qui ne vous rend pas immédiatement vulnérable au vol didentité si votre appareil est volé. la sécurité de lauthentification à deux facteurs réside dans le fait que ni lappareil ni le mot de passe ne peuvent être utilisés sils sont volés sans lautre. La technique de Gibson résiste largement à être incluse dans un schéma à deux facteurs, ce qui rend ce niveau de protection non disponible.

TL; DR:

La technique dauthentification de Gibson ne crée pas un avantage suffisant pour surmonter les coûts de sécurité supplémentaires quelle 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 dire que cest mieux que rien, mais vous ne pouvez pas dire que cest 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 nutilisez PAS les codes QR, le téléphone portable, etc., et que vous avez à la place un agent dauthentification sur votre système (dans le navigateur, par exemple), le serveur peut alors vérifier que lauthentification La réponse provient de la même adresse IP que la demande dauthentification. Cest bien, mais le but de ce protocole est de déplacer votre identité sur votre téléphone portable. Si le seul moyen sûr dutiliser le protocole est de ne pas lutiliser , 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 quil utilisait la même adresse IP que votre ordinateur. Ce que, bien sûr, il ne peut pas savoir car il ne connaît pas ladresse IP de votre ordinateur.

Une meilleure solution

Comme indiqué précédemment, si la mesure dauthentification se trouve dans votre navigateur, , tout le problème de phishing est immédiatement résolu sans effort ni vérification de la part de lutilisateur. Même lutilisateur le moins capable ne peut « pas être amené à sauthentifier sur le mauvais site car le jeton dauthentification du site » est associé au nom de domaine, et le navigateur a gagné  » t autorisez lauthentification sur le mauvais domaine. Cest une technique déjà utilisée aujourdhui, complètement automatique, et ne nécessite pas la coopération du site ni aucune intelligence de la part de lutilisateur.

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

En ce qui concerne les inquiétudes concernant la vulnérabilité de l’authentification côté navigateur aux attaques du poste de travail client: si le est vrai, il est également vrai que si votre navigateur est compromis, alors non lutilisation de ce navigateur est sûre , quel que soit le mécanisme dauthentification que vous utilisez.Les auteurs de logiciels malveillants peuvent (et le font déjà) attendre que vous vous authentifiiez par vous-même à laide de votre technique ultra-sécurisée, puis envoyer silencieusement le trafic nécessaire à  »  » votre compte, le tout sans que vous voyiez quoi que ce soit qui cloche. Ni SQRL ni aucun autre système dauthentification ne peuvent protéger lutilisateur dun navigateur compromis, pas plus que les serrures de porte ne peuvent vous protéger dun incendie domestique. Lachat de serrures ignifuges nest pas une solution.

Où ensuite

Si vous « recherchez une garantie absolue de protection contre lusurpation didentité , puis examinez 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 lutilisateur, mais également le canal «sont garantis 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 dinformations.

Commentaires

• À propos du premier point : pour autant que je sache, cela a été pensé et une option est de laisser le site Web sur lequel vous êtes authentifié être responsable de la redirection. Ainsi, lors de la connexion, vous êtes redirigé vers la vraie page de la banque ‘, pas vers lattaquant. Concernant le deuxième point, la même chose se produit aujourdhui avec les utilisateurs doutils comme LastPass. Sauf si vous configurez un mécanisme de protection (PIN, par exemple), tous vos mots de passe sont également volés. Pourquoi ‘ peut-il en être de même pour SQRL? Aussi, pour autant que je sache daprès les spécifications, lutilisateur peut sauvegarder son identité même sur papier (sous forme de code QR).
• Et à propos du troisième point: la même chose se produit avec la plupart des utilisateurs qui ne ‘ t utiliser un gestionnaire de mots de passe, en utilisant simplement un seul nom dutilisateur / mot de passe sur plusieurs sites Web. Ou, avec les utilisateurs de gestionnaires de mots de passe, dont l  » identité  » est répartie sur plusieurs sites Web, mais stockée dans un seul emplacement (LastPass ‘ serveurs, base de données 1Password, etc.). Donc, ce ‘ nest pas vraiment une faille SQRL. Dans lensemble, plus je lis sur SQRL, plus jen vois les avantages par rapport aux alternatives actuelles. Dites ce que vous dites à propos de Steve Gibson, mais SQRL me semble vraiment une bonne alternative.
•  » La prudence déjà battue dans la tête de les utilisateurs concernant la sécurité des mots de passe ne se traduisent pas nécessairement par de nouvelles techniques dauthentification comme celle-ci. . .  » Cest un excellent point, et la bataille a déjà été perdue pour le marketing. Les codes QR sont considérés comme un moyen facile de faire avancer les choses, et non comme un vecteur dattaque potentiel. Au moins, les paires nom dutilisateur / mot de passe ont été dabord utilisées comme mécanisme dauthentification, pas comme outil de marketing.
• @jpkrohling: En ce qui concerne les gestionnaires de mots de passe, je suppose que la plupart des utilisateurs de ces logiciels ne stockent PAS leur mot de passe principal sur leur appareil mobile, précisément parce quils savent à quel point cest dangereux. Jai une copie physique de mon mot de passe principal dans un endroit sûr, mais aucune copie électronique. Les attaques qui donneraient accès à mon mot de passe principal sont différentes de celles qui compromettraient un mot de passe de site, et sont beaucoup moins probables. (Principalement parce quattaquer ma base de données de mots de passe impliquerait de mattaquer personnellement, plutôt quun grand site compromis.)
• @jpkrohling Ni LastPass ni KeePass ne stockent un mot de passe principal nulle part. Il ‘ est utilisé pour déverrouiller votre base de données de mots de passe, mais il n’est pas ‘ stocké. Ceci est fondamentalement différent davoir une seule clé qui est, elle-même, utilisée partout.

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

Idées fausses

Tout dabord, 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, tout en ignorant ses avantages. Alors clarifions ici quelques idées fausses. nous?

Mythe: SQRL nécessite de scanner les codes QR pour fonctionner

Ce n’est tout simplement pas vrai. Les codes QR sont pratiques ce qui rend SQRL plus facile à utiliser sur les ordinateurs sur lesquels lutilisateur na pas configuré le logiciel client SQRL. Le site Web de SQRL indique ce qui suit:

Trois façons dy aller….smartphone en option:

Bien que linspiration originale pour le développement de ce système ait été un smartphone scannant un code QR sur la page de connexion dun site Web, un petit ajout à ce modèle permet deux modes de fonctionnement plus importants: Simplement faire de limage du code QR é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:

• Scannez le code avec un smartphone: En utilisant le modèle décrit ci-dessus, le smartphone dun utilisateur scanne le code QR apparaissant sur la page de connexion dun site Web et lutilisateur est connecté à ce site.
• TAP LE CODE sur un smartphone: Pour vous 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) le Lapplication SQRL installée sur le smartphone recevra ce lien et connectera en toute sécurité lutilisateur au site sur le téléphone.
• Cliquez sur le code sur un écran de bureau ou dordinateur portable : Pour utiliser le système SQRL sur nimporte quel ordinateur de bureau ou ordinateur portable, une application SQRL de bureau serait installée et senregistrerait pour recevoir les liens sqrl: //. (Ceci est similaire à la façon dont un programme de messagerie senregistre pour recevoir des liens mailto:). Cela permet aux utilisateurs sur leur bureau dutiliser la même solution quils utilisent sur leurs smartphones. Lorsquun site Web propose un code SQRL, lutilisateur clique simplement sur le code avec le curseur de la souris et lapplication SQRL installée localement saffiche, 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 cela 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 dun utilisateur ne vous donnerait pas automatiquement accès à son identité en ligne à moins que vous nayez également son mot de passe principal. Plus de détails sur la gestion des clés sont expliqués dans la page Client SQRL- Side Key Management sur le site Web de SQRL.

Mythe: Si votre clé principale est volée, vous ne pouvez pas modifier vos identifiants de connexion

Ceci est également faux. SQRL fournit un moyen intégré permettant 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 didentité:

« Identity Lock » empêche le changement didentité & permet la récupération: Ceci est également suffisamment important pour mériter sa propre page de description détaillée: «  Le protocole de verrouillage didentité  » (page 4 dans le bloc de liens au bas de cette page). l identité de l utilisateur a été établie avec un serveur Web, le SQRL c lient est incapable de changer cette identité. Cela signifie que si le pire sest produit et quun mot de passe très faible et facile à deviner a été utilisé, ou le téléphone ou le bureau dun utilisateur a été piraté pour obtenir sa clé principale didentité et son mot de passe, aucun tiers malveillant ne peut modifier lidentité en ligne de lutilisateur pour le verrouiller hors de ses propres comptes en ligne. De plus, en chargeant ensuite une « clé de déverrouillage didentité » 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 leur identité précédente inutile.

Plausible: SQRL est plus vulnérable au phishing que solutions dauthentification existantes

Daccord, cest 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 lutilisateur veille à ce que le site Web affiché dans la barre dURL de son navigateur soit le même que celui affiché par lapplication SQRL Client, il pourrait autoriser une session de connexion pour lattaquant. Cest toujours mieux que les mots de passe, où ils « donneraient au phisher un accès permanent à leur compte (et à tous les autres comptes quils ont ailleurs qui partagent le même mot de passe) jusquà ce quils changent de mot de passe, mais pas aussi bien que dautres solutions qui sintègrent au navigateur de lutilisateur comme les clés U2F , WebAuthn, certificats clients et (sous certaines conditions) 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 phishing en place. Ces protections sont expliquées sur le site Web de SQRL, sous la section Comment SQRL peut contrecarrer les attaques de phishing .Il est également possible dinté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 lensemble, je classe SQRL sur à 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 lorsquil est installé sur le même appareil sur lequel lutilisateur se connecte, mais offre une protection minimale lorsquil est installé sur un appareil différent.

Comparaison avec des alternatives

Comparons maintenant SQRL avec les solutions dauthentification 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 défini car les utilisateurs nont 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, le keylogging et, dans une certaine mesure, le phishing.

Inconvénients SQRL a comparé aux mots de passe, il est plus difficile à mettre en œuvre pour les opérateurs de sites Web, pas aussi largement utilisé, nécessite plus de temps pour configurer initialement, 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 lutilisateur si la clé principale est volée (bien que ce dernier point Cest é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 dauthentification entre les utilisateurs et les services individuels. Cependant, SQRL est supérieur de deux manières aux gestionnaires de mots de passe.

Le principal avantage que SQRL a sur les gestionnaires de mots de passe est quil est plus facile et plus sûr à utiliser sur des ordinateurs non fiables ou seulement partiellement fiables. Par exemple, supposons quun utilisateur souhaite se connecter à un site Web à laide dun ordinateur dune 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 saisir à nouveau manuellement sur lordinateur, soit télécharger son le gestionnaire de mots de passe et la base de données de mots de passe sur l’ordinateur de la bibliothèque, déverrouillez la base de données à l’aide de son mot de passe principal, puis connectez-vous. Le premier scénario est peu pratique pour l’utilisateur et expose le mot de passe en texte clair de l’utilisateur pour ce site à l’ordinateur non approuvé (et à tout logiciel malveillant sur lordinateur 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 et le mot de passe principal décryptés de lutilisateur à lordinateur non approuvé. Avec SQRL, lutilisateur naurait quà scanner un code QR sur lécran de lordinateur non approuvé, ce qui est beaucoup plus pratique pour lutilisateur, et nexpose quune seule session de connexion (sans informations didentification réutilisables comme un mot de passe) à lordinateur non approuvé .

Un autre avantage de SQRL par rapport aux gestionnaires de mots de passe est quil est plus facile de récupérer du pire des cas: la base de données de mots de passe / la clé principale de lutilisateur est volée. Avec un gestionnaire de mots de passe, vous ne pouvez pas il vous suffit de changer votre mot de passe sur chaque site, vous devrez également vous inquiéter de la modification de votre mot de passe par l’attaquant (éventuellement vous exclure de votre compte). L’attaquant a également l’avantage de posséder une liste de tous les sites sur lesquels vous disposez compte sur, ce qui rend lexploitation du vol dune base de données de mots de passe beaucoup plus facile. Avec SQRL, se faire voler votre clé principale est toujours une situation terrible, mais lattaquant na pas de liste de sites sur lesquels vous avez un compte (il doit plutôt deviner ) et ne peut pas modifier votre mot de passe pour vous verrouiller de votre compte. Une fois que vous avez chargé votre clé de déverrouillage didentité, 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 daller via nimporte quel formulaire de «changement de mot de passe».)

Enfin, je pense que SQRL a un petit mais important avantage par rapport aux gestionnaires de mots de passe en ce qui concerne son objectif de remplacer entièrement les mots de passe, à savoir que les sites ont la possibilité dappliquer lutilisation de SQRL par rapport aux mots de passe traditionnels. Tant que les utilisateurs ont toujours la possibilité de bénéficier dune sécurité médiocre, en réutilisant le même mot de passe sur chaque site, cela se produira toujours. Si SQRL commence à être largement adopté, les sites peuvent en fait commencer à supprimer lutilisation de mots de passe. Cela ne peut pas être fait avec les gestionnaires de mots de passe, car ils reposent sur lutilisation de mots de passe pour fonctionner.

En termes dinconvé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 quil 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 des gestionnaires de mots de passe dès maintenant, mais SQRL devra attendre que les sites limplémentent avant de pouvoir lutiliser. Cest un obstacle important à ladoption.

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 quen 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 dune mauvaise intégration avec les interfaces utilisateur et les serveurs Web, qui sont des problèmes plus difficiles à résoudre. Je nentrerai pas dans les détails ici, car il existe déjà un excellent article sur les problèmes de convivialité des certificats clients sur browserauth.net.

En termes de sécurité, les certificats clients ont linconvénient de nécessiter limplication dune CA. Ceci est (potentiellement) coûteux et nécessite de faire confiance à lautorité de certification tierce. De plus, si vous choisissez dignorer 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 lordinateur 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 quelquun propose une meilleure solution conviviale en utilisant certificats clients qui résout (au moins la plupart de) ces problèmes, je ne crois pas que les certificats clients soient un concurrent sérieux de SQRL (ou, d’ailleurs, des mots de passe).

Authentification à 2 facteurs

Je pensais juste que je le mentionnerais: SQRL et lauthentification à 2 facteurs ne sont pas mutuellement exclusives. SQRL remplace le premier facteur de 2FA: les mots de passe. Dautres 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 lutilisation du téléphone de lutilisateur pour authentifier une session de connexion sur un appareil externe , en plus de quelques autres méthodes dauthentification (telles que les clés de sécurité de deuxième facteur) .

Cest 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 fournit é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 lutilisateur na pas préalablement configuré le logiciel client de lauthentificateur. Cela est possible car dans cette situation, WebAuthn communique directement avec le navigateur de lutilisateur en utilisant des protocoles de communication bidirectionnels tels que Blutooth ou NFC, communiquant plutôt avec le site Web que lutilisateur utilise via un code QR à sens unique.

Du point de vue de la convivialité, les choses sont un peu plus compliquées. En apparence du moins, WebAuthn gagne à nouveau. Parce que cest 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. En pratique cependant, la plupart des implémentations existantes de WebAuthn se concentrent sur son utilisation comme une forme dauthentification au 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 dauthentification principal, WebAuthn manque encore plutôt dimplémentations viables.

Dautres considérations mineures incluent le fait que SQRL a un bâtiment méthode t-in pour faire tourner les clés des comptes en cas de vol de clé principale, alors que WebAuthn sappuie sur des 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 pour sauthentifier sur une machine distante, alors que SQRL peut fonctionner sur nimporte quelle machine avec un affichage fonctionnel.

Dans lensemble, je pense quil 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 bénéficie dun soutien beaucoup plus fort de la part des fournisseurs de navigateurs, des opérateurs de sites et dautres organisations tierces (comme le W3C). Une fois que WebAuthn aura obtenu quelques implémentations permettant son utilisation comme facteur dauthentification principal, je pense quil 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 mattends à 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 newsgroup SQRL sur grc.com.

SQRL est une solution pratique au problème du nom dutilisateur / password paradox. (cest-à-dire le compromis commodité / sécurité) sans utiliser un tiers . Il offre une alternative simple au modèle dauthentification 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 aujourdhui, 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 rater le point de SQRL. SQRL lui-même ne fournit pas nécessairement une sécurité meilleure ou pire. Si lordinateur / téléphone lui-même est compromis ou si lutilisateur est trompé étant hameçonné, il sagit dune attaque par canal secondaire au lieu dune faute directe de SQRL lui-même. Chaque méthode dauthentification conventionnelle pose ce problème dattaques par canal latéral Le pavé unique incassable est également vulnérable aux attaques par canal latéral comme le compromis du pad lui-même, ou une mauvaise sécurité ou implémentations environnantes.

Si vous avez écouté la proposition originale de lidée sur Steve Gibson « s podcast , suivi des Q & A « , de nombreuses questions soulevées sur ce fil de discussion de pile 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 cest 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 nintroduit pas de nouvelle classification des problèmes que nos méthodes dauthentification traditionnelles nont pas déjà.

SQRL est excellent sil 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 commodité et sécurité , et cette solution est probablement la meilleur équilibre des deux que jai vus.

Commentaires

• Merci Ansichart. Mais les ‘ t solutions dauthentification existantes peuvent-elles simplement conserver des fonctionnalités de sécurité égales ou supérieures à SQRL, puis utiliser lautomatisation pour augmenter leur confort dutilisation? Quelle propriété fondamentale de la facilité dutilisation de SQRL ‘ nest pas due à lautomatisation? Je demande parce que si un utilisateur a deux boîtes noires qui font la même chose; lun intitulé  » Mature  » et lautre intitulé  » SQRL  » et ils peuvent être à la fois conçus / automatisés ont la même interface / boutons à lextérieur de la boîte – quelle valeur ajoutée SQRL apporte-t-il?
• Cela résout le problème du paradoxe des mots de passe sans avoir à faire appel à un tiers.
• Je vois. Donc, si quelquun ne souhaite pas ‘ le risque tiers de lauthentification unique et ne ‘ pas générer / stocker ses mots de passe avec un gestionnaire de mots de passe, SQRL peut intensifier. Mais si SQRL est une boîte noire mobile qui demande un mot de passe pour déverrouiller la clé principale utilisée pour régénérer / stocker les SQRLID, puis effectuer une liaison back-channel du cookie / QR du client ‘ session_id avec le serveur ‘ enregistré SQRLID pour se connecter – comment est-ce une boîte noire mobile différente dun gestionnaire de mots de passe mobile avec connexion automatique via le même canal arrière; ou un plug-in de certificat de client mobile à deux parties avec la génération automatique de & connexion via le même back-channel?
• Jai effectué des modifications majeures de mon message dorigine après quelques secondes considérations et une lecture plus approfondie de ce que dautres ont dit, car je lai peut-être surexagéré. Je suppose que le fait davoir le téléphone portable comme clé centrale change le problème et rendrait plus important une sécurité renforcée sur votre téléphone. Steve Gibson en parle également dans la réponse Q & A.

SQRL ne fournit 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 lexpiration des informations didentification? Le site pourrait simplement rejeter directement un identifiant expiré.

Donc, le plus gros problème de sécurité que jai avec ceci protocole est: Réinventer la roue carrée .

Update

En lisant de nouvelles réponses et commentaires, jaimerais souligner à quel point il est facile de faire quelque chose de similaire à SQRL via automatisation simple de la technologie existante mature :

1. Le site Web demande des CAPTCHA ou une vérification « Je » ma human « similaire. Une fois que lutilisateur sest conformé (POSTed), le site Web renvoie un HTTP 403.7 - Client Certificate Required 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 dune 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é « conforme S403L » dans lesprit 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 tiers- partie cache si le chiffrement du keystore de votre navigateur est nul). Le plug-in crée un CSR standard pour le certificat client et envoie le CSR à lURL spécifiée dans le balisage 403. (par exemple, <s403l ref="https://www.example.com/S403L" />)
5. Le serveur compatible S403L utilise lidentifiant de session de lutilisateur (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. Lauthentification générale du serveur acceptera tout certificat client qui a été signé par le serveur (et qui répondait donc aux critères denregistrement exigés à létape 1).
6. Le plug-in S403L stocke ce certificat client signé dans le cache du navigateur. De ensuite, le navigateur standard sans assistance plugin peut « se connecter automatiquement » au serveur de la manière standard SSL / TLS jusquà lexpiration du certificat.

La nature « mobile » et « visuelle » de SQRL est en quelque sorte une mauvaise direction car il ne fournit pas dauthentification à deux facteurs détachée et vous avez maintenant besoin de deux ordinateurs pour naviguer sur Internet au lieu dun. À 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 peut avoir une entropie folle et de bonnes fonctionnalités de gestion PKI (expiration , révocation, extensions de politique, etc.). SQRL ne sintègre proprement dans aucun des deux camps; et si cela dérive vers le camp moins humain et plus informatique comme il semble – il a des années de développement et danalyse de sécurité pour répéter les fonctionnalités X.509 existantes.

Commentaires

• > pourrait simplement utiliser un certificat client stocké sur le mobile à la place.— sauf que cette technologie existe depuis des années à la fois sur mobile et sur ordinateur, et ‘ nest pas aussi répandue quon le souhaiterait. Et contrairement au certificat client, SQRL ne ‘ t vous oblige à prouver votre véritable identité pour créer une  » Identité SQRL « . Si vous le souhaitez, vous pouvez créer autant didentités que vous le souhaitez. Cela signifie que lavantage par rapport aux certificats clients est que vous bénéficiez de lanonymat du côté du protocole dauthentification ‘.
• @jpkrohling Cest une idée fausse courante que les certificats clients exiger la divulgation didentité à utiliser. Cest une exigence des autorités de signature commerciales dutiliser leurs chaînes de confiance interchangeables à léchelle mondiale. En pratique, un certificat client peut simplement être un CSR anonyme créé par le client et signé par un serveur spécifique, après avoir satisfait aux critères souhaités (CAPTCHA, compte antérieur, etc). Les certificats peuvent également avoir une expiration intégrée. Type 40-L Les codes-barres QR pourraient envoyer / stocker le certificat client de 1 Ko X.509 si vous le souhaitez.
• Ok, cest vrai, cest dommage. De ce point de vue, le client (application mobile, par exemple), pourrait générer un certificat client pour chaque site Web que lutilisateur enregistre. Cela semble plus coûteux que le hachage de certaines informations, mais pourrait être une solution intéressante. Dans tous les cas, je ne suis toujours ‘ pas daccord avec vos affirmations selon lesquelles SQRL est pire quinutile.
• Jai peut-être été sévère sur ce libellé et je vais le supprimer. Mais je ne ‘ pas voir SQRL comme autre chose quune manière plus sexy de distribuer les informations didentification client négociées; et celui qui na pas ‘ résolu certains des problèmes subtils résolus par les schémas dauthentification matures. Un gestionnaire de mots de passe est fastidieux (je ne ‘ pas me soucier de l’intégration du navigateur car je ‘ ma paranoïaque) mais je sais que seulement moi et un site Web partage chaque mot de passe unique dans mon magasin de clés crypté. ‘ Je nai pas à me soucier des nouveaux schémas de hachage / authentification sophistiqués, juste la qualité du PRNG / TRNG que mon gestionnaire de mots de passe utilise pour générer des mots de passe.
• @LateralFractal qui se soucie de savoir si ‘ est nouveau ou pas? SQRL permet une authentification conviviale où la première partie nexpose pas son secret à la deuxième partie ou à une tierce partie qui aurait pu compromettre la sécurité de la deuxième partie ‘. Cest ‘ une tentative de résoudre un problème du monde réel que, jusquà présent, personne dautre na été en mesure de résoudre.

Je voudrais répondre à la première question: « lun des problèmes auxquels je peux penser est si le lecteur QR est compromis, pour 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 ladresse 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 dauthentification qui serait normalement envoyé à www.google.com (dans lexemple).

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

1. anonymat en nutilisant pas de tiers
2. facilité dutilisation
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 y a des compromis qui en fait proviennent du premier objectif. Si aucun tiers nest impliqué dans lauthentification, comment peut-on révoquer ses informations dauthentification? De plus, la sécurité de la clé principale est une préoccupation évidente. Jenvisage que cela soit bien protégé par les futurs appareils mobiles dans un HSM comme une puce. 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 à le forcer. « >