Pourquoi les développeurs utilisent-ils des agents utilisateurs intégrés pour l'authentification tierce? Quelles sont les alternatives?
J'ai remarqué une tendance dans les applications mobiles et de bureau ces dernières années avec l'avènement de OAuth (et cela peut également affecter d'autres cadres) pour demander à un utilisateur de s'inscrire ou de se connecter en utilisant un tiers les fournisseurs d'authentification, généralement des comptes sociaux comme Twitter, Facebook ou Google. Le problème survient lorsque je ne peux pas faire confiance à l'application dans laquelle je saisis les informations d'identification, car le développeur a intégré un navigateur dans une boîte de dialogue/fenêtre appartenant à l'application, et Je n'ai aucun moyen de savoir si la page que je vois est une page de connexion légitime, ou que l'agent utilisateur (navigateur et couches en haut) peut faire confiance.
Je ne parle pas non plus des applications de petits développeurs indépendants, je parle des logiciels de sociétés de grande confiance (au moins dans la communauté de développement de logiciels où je passe la plupart de mon temps). Quelques exemples que j'ai vus ces dernières semaines:
- Atlassian Sourcetree vous permet de vous connecter en utilisant votre compte Google - dans une fenêtre Atlassian
- Postman La connexion à Google se produit dans une fenêtre Postman
- Microsoft Visual Studio et Office le font avec votre compte Microsoft (accordé, cela est un peu plus fiable car l'application appartient au fournisseur d'authentification, mais il approuve toujours le processus)
- Certaines applications vous demandent, par exemple, de vous connecter à Paypal dans une fenêtre de navigateur à l'intérieur de leur application
Questions similaires posées dans le passé concernant les applications mobiles (mais le problème ne se limite pas aux mobiles):
- Comment puis-je vérifier que les boîtes de dialogue de connexion sociale dans l'application sont sécurisées?
- Comment puis-je faire confiance à Google?
Une question liée à une application de bureau:
Et tangentiellement lié est l'utilisation des iframes dans les applications Web:
C'est un problème de confiance pour moi lorsque je passe de l'espace d'application au Web pour m'authentifier, obtenir un jeton et revenir à l'application. Je pourrais faire suffisamment confiance aux entreprises pour installer leur logiciel, mais pas assez pour saisir les clés principales de mon compte Google (à toutes fins utiles) dans leur logiciel.
En recherchant cette question plus loin, j'ai trouvé ce projet de l'IETF qui dit:
Les agents utilisateurs intégrés sont une méthode alternative pour l'autorisation des applications natives. Ils ne sont cependant pas sûrs pour une utilisation par des tiers sur le serveur d'autorisation par définition, car l'application qui héberge l'agent utilisateur intégré peut accéder aux informations d'authentification complètes de l'utilisateur, et pas seulement à l'autorisation d'autorisation OAuth qui était destiné à l'application.
EDIT: Le brouillon ci-dessus est devenu RFC8252 , daté d'octobre 2017, merci à @Geir de m'avoir dirigé vers cela.
et une ancienne directive, RFC6749 (datée d'octobre 2012) qui mentionne également, entre autres, des informations intéressantes:
Un agent utilisateur intégré pose un problème de sécurité car les propriétaires de ressources s'authentifient dans une fenêtre non identifiée sans accès aux protections visuelles trouvées dans la plupart des agents utilisateurs externes. Un agent utilisateur intégré apprend aux utilisateurs finaux à faire confiance aux demandes d'authentification non identifiées (ce qui facilite l'exécution des attaques de phishing).
Mes questions:
Ai-je raison de craindre qu'il s'agisse d'une opportunité croissante pour le phishing et les attaques MITM (un faux navigateur ou un piratage au milieu qui vole les informations d'identification et/ou des jetons en temps réel, battant également 2FA)? Pas tellement qu'un logiciel de confiance lui-même soit susceptible d'être rendu malveillant, mais que l'utilisation répandue décourage les utilisateurs de vérifier la confiance de bout en bout, tolérant (voire encourageant) les utilisateurs à entrer aveuglément les informations d'identification dans toute application qui les demande?
Je pense que la dernière section citée ci-dessus répond indéniablement par l'affirmative, mais je suis intéressé par d'autres commentaires et perspectives à ce sujet, en particulier en tant que développeur de logiciels moi-même.
La manière "correcte" évidente de le faire est de transférer l'utilisateur vers son navigateur de confiance pour l'authentification, mais cela peut être une mauvaise expérience utilisateur et ne résout pas réellement le problème (un développeur malveillant pourrait ouvrir une fenêtre à partir du principal application qui ressemble comme Chrome, mais ne l'est pas - les sessions utilisateur de la fenêtre principale du navigateur ne sont pas conservées, entre autres les repères visuels passeraient probablement inaperçus pour la plupart).
Existe-t-il un meilleur moyen de concevoir l'expérience utilisateur des applications de sorte qu'un utilisateur puisse être sûr qu'il utilise une pile logicielle de confiance (application et moteur de rendu), dans l'application? Devrait-il y avoir une gestion au niveau de l'appareil ou du système de ces demandes d'authentification d'une manière difficile à imiter?
Je ne suis pas vraiment impliqué dans la scène de la sécurité, juste un rôdeur ici, est-ce une préoccupation bien connue dans l'industrie? Des efforts sont-ils déployés pour limiter ce type de flux d'authentification?
Ai-je raison de craindre qu'il s'agisse d'une opportunité croissante pour le phishing et les attaques MITM (un faux navigateur ou un piratage au milieu qui vole les informations d'identification et/ou des jetons en temps réel, battant également 2FA)? Pas tellement qu'un logiciel de confiance lui-même est susceptible d'être rendu malveillant, mais dans la mesure où cette utilisation généralisée décourage les utilisateurs de vérifier la confiance de bout en bout, plutôt que d'entrer aveuglément les informations d'identification dans une application qui les demande?
Vous avez raison à 100%. En fin de compte, la plupart des utilisateurs s'attendent à ce que les sites Web soient similaires. Si chaque site Web a un cadenas vert, les utilisateurs remarquent de gros avertissements de sécurité rouges. Lorsque chaque site Web demande l'e-mail des utilisateurs, etc., les utilisateurs commencent à distribuer leurs informations de contact sans arrière-pensée.
De même, les utilisateurs seront "désensibilisés" lorsque de plus en plus d'applications demanderont des informations d'identification à l'aide d'un navigateur intégré à l'application. Espérons que cela ne conduira pas les utilisateurs à partager les informations d'identification entre les services sans cligner des yeux, mais dans le pire des cas, cela pourrait arriver.
La manière "correcte" évidente de le faire est de transférer l'utilisateur vers son navigateur de confiance pour l'authentification, mais cela peut être une mauvaise expérience utilisateur
Ces deux affirmations sont correctes.
et ne résout pas réellement le problème (un développeur malveillant pourrait ouvrir une fenêtre de l'application principale qui ressemble à Chrome, mais ce n'est pas le cas - les sessions utilisateur de la fenêtre principale du navigateur ne sont pas conservées, entre autres indices visuels, ils iraient probablement inaperçu par la plupart).
Malheureusement aussi, même si à ce stade, il s'agit, pour la plupart, de phishing simple. Les malveillants pourraient également envoyer l'utilisateur vers un site Web de phishing: /
Existe-t-il un meilleur moyen de concevoir l'expérience utilisateur des applications de sorte qu'un utilisateur puisse être sûr qu'il utilise une pile logicielle de confiance (application et moteur de rendu), dans l'application?
Je ne pense pas, malheureusement.
Devrait-il y avoir une gestion au niveau de l'appareil ou du système de ces demandes d'authentification d'une manière difficile à imiter?
C'est extrêmement intéressant. ne question connexe sur SE traite de ce problème en ce qui concerne les invites de connexion au niveau du système. L'essentiel est qu'il n'existe pas d'implémentation/solution en cours d'utilisation, mais certaines idées intéressantes incluent des raccourcis/boutons qui ferment des fenêtres qui n'appartiennent pas au système. De cette façon, le système pourrait dire "appuyez sur XYZ pour continuer" et à moins que ce ne soit vraiment le système, la fenêtre se ferme et les informations d'identification ne sont pas envoyées.
Dans ce cas spécifique, le système d'exploitation pourrait avoir une instance de navigateur système avec des fonctionnalités similaires à celles mentionnées ci-dessus. Ce navigateur peut être un moteur de rendu/analyseur HTML/css/js d'une page, sans lien hypertexte, juste pour la connexion avec une API simple pour OAuth.
Je ne suis pas vraiment impliqué dans la scène de la sécurité, juste un rôdeur ici, est-ce une préoccupation bien connue dans l'industrie?
Le souci du phishing est (ou du moins devrait être) toujours un problème, mais c'est la première fois que j'y pense personnellement dans le contexte d'OAuth, et al.
Des efforts sont-ils déployés pour limiter ce type de flux d'authentification?
Je ne connais aucun effort pour se protéger contre cette attaque, mais des cartes à puce matérielles u2f telles que yubikeys cryptent les jetons 2fa sur le site Web spécifique avec lequel ils sont configurés. Cela protège contre le phishing, mais n'empêche toujours pas un navigateur malveillant/faux de voler le nom d'utilisateur, le mot de passe, etc. En outre, un navigateur malveillant (dans l'application) pourrait simplement voler des cookies de session une fois l'utilisateur connecté.
Solution proposée pour les développeurs d'applications
OAuth doit être fait via le navigateur par défaut de l'utilisateur, pas dans l'application.
Solution possible pour les développeurs de systèmes d'exploitation
Comme indiqué ci-dessus, le système d'exploitation pourrait théoriquement fournir des méthodes d'entrée fiables pour OAuth, etc. Cela pourrait également s'étendre au-delà de OAuth pour permettre aux utilisateurs de se connecter facilement et en toute sécurité à des services tels que git dans les cli, etc.
C'est une préoccupation, quoique (je crois) qui ne fait que se recignifier à présent. Par exemple, la RFC 8252 déclare à propos d'OAuth2 que:
Les demandes d'autorisation OAuth 2.0 à partir d'applications natives doivent uniquement être effectuées via des agents utilisateurs externes, principalement le navigateur de l'utilisateur. ( https://tools.ietf.org/html/rfc8252 ).
Pas une réponse complète, mais je tiens à ajouter que 2F rend l'authentification à partir du navigateur presque impossible à rendre. Si cela devait être utilisé, votre stratégie "correcte" devient en fait une stratégie sécurisée. Avec U2F, les utilisateurs n'entrent pas de mots de passe dans leur navigateur. Au lieu de cela, il existe une négociation sécurisée entre le navigateur et l'authentificateur U2F ( résumé du protocole ). Le plus gros problème avec U2F est que les entreprises ne se sentent pas motivées à investir dans l'option.