OAuth est pas sécurisé ou je n'ai pas le comprendre?
Je pensais au sujet de la sécurité de mon Service web REST API, et a décidé de prendre un coup d'oeil à d'autres grands services et comment ils le font. Comme exemple j'ai décidé d'étudier de Twitter OAuth. Après la lecture de guide pour les débutants, je suis un peu embarrassée et choqué.
Ce que j'ai compris c'est de la responsabilité du prestataire du Service d'authentifier l'utilisateur et de montrer à l'Utilisateur quel type d'accès consommateur l'exige (par exemple, il veut s en lecture seule accès à certaines ressources). Mais j'ai vu des prestataires de services qui n'a pas d'informer l'utilisateur sur le type d'accès consommateur est exigeant (et même maintenant montrant identité du consommateur). La deuxième partie du problème est que le consommateur peut montrer son propre Fournisseur de Service formulaire d'Authentification, IFrame, et vient masquer les détails d'accès, ils peuvent voler votre mot de passe, ou de demander un accès illimité à des ressources, ils peuvent le faire en gros ce qu'ils veulent, il y a beaucoup de façon de tromper l'utilisateur.
Comme un exemple, nous allons prendre un LinkedIn. Ils demandent votre nom d'utilisateur gmail et le mot de passe à l'intérieur de leur propre forme, et vous n'avez aucune idée de comment ils vont l'utiliser. Ils peuvent voler et de le stocker dans leurs prestations, ils peuvent OAuth avec elle à gmail (et ils ne le montrent pas de gmail page avec les informations de ce type d'accès qui leur demande), ils peuvent faire ce qu'ils veulent avec cette information.
Ce que j'essaie de dire, c'est pas que OAuth protocole de communication n'est pas sûr, mais il y a beaucoup de façon de l'utiliser mal de tromper l'utilisateur et d'obtenir ses lettres de créance.
BTW il y avait quelques failles de sécurité dans le protocole d'authentification OAuth lui-même: (http://oauth.net/advisories/2009-1/) et je suis assez sûr qu'il ya plus, mais personne ne se soucie de les trouver.
Ce n'est pas OAuth dans les termes que OAuth n'a pas d'Authentification de l'adresse, mais ils peuvent utiliser le nom d'utilisateur|mot de passe à partir de à partir de à authentifier ob nom d'utilisateur sur le site du fournisseur d'accès, et d'obtenir OAuth jeton d'autorisation. Ainsi, sous le couvert il peut être OAuth bot n'est pas comme il le devrait.
OriginalL'auteur Alex Burtsev | 2011-02-14
Vous devez vous connecter pour publier un commentaire.
Je vais aller avec " Vous n'avez pas la comprendre. (Dans votre défense, très peu de gens le font.)
Soyons clairs: L'attaque de fixation de session, vous faites référence à des touchés OAuth 1.0, mais a été résolu dans OAuth 1.0 a, qui est devenu RFC 5849. Il n'y a pas les principaux responsables de l'implémentation de l'authentification OAuth 1.0 — les grands réalisateurs tout soit mis en œuvre le protocole OAuth 1.0 a/RFC 5849 ou ils ont mis en place l'une de l'OAuth 2.0 brouillons.
Comme pour le nom d'utilisateur/mot de passe anti-modèle, OAuth 1.0 a ne pas prévoir un mécanisme pour l'échange d'un nom d'utilisateur et le mot de passe d'un jeton d'accès. OAuth 2.0 fait, mais seulement pour les fins de soutenir les applications installées. Gardez à l'esprit qu'une application installée pourrait simplement keylog (ou similaire) si il voulait vraiment. Quand il s'agit de sécurité, tous les paris sont éteints si une application est déjà en cours d'exécution en mode natif et unsandboxed sur l'ordinateur du client. Mais c'est en fait un scénario très différent de ce que vous êtes en train de parler. Les applications Web dans les deux OAuth 1.0 a et OAuth 2.0 ne touchez jamais le nom d'utilisateur et mot de passe.
Le flux d'OAuth 1.0 a va comme ceci: L'application demande au fournisseur pour un jeton de demande en lui disant toutes les choses qu'il veut accéder à. Le fournisseur de problèmes temporaires non autorisée jeton, à quel point le client peut envoyer l'utilisateur vers le fournisseur d'autoriser le jeton. Les ouvertures de session utilisateur avec leur nom d'utilisateur et le mot de passe sur le site du fournisseur puis accorde ou refuse l'accès. Le fournisseur redirige ensuite de retour avec un vérificateur de chaîne qui permet au site de mise à niveau à une autorisation jeton d'accès. L'ensemble de ces interactions sont signés. Si les signatures ne correspondent pas à l'un d'eux, le fournisseur de rejeter la demande. Et l'utilisateur peut révoquer n'importe quel jeton à tout moment, le retrait de la capacité du client à accéder à leur compte.
Il y a un certain nombre de considérations relatives à la sécurité avec le protocole, mais si vous avez réellement lu la liste, c'est essentiellement la même que la liste des problèmes de sécurité qui affectent presque tous les sites sur l'internet. Ces considérations relatives à la sécurité sont tous très bien connu et très bien compris. À ma connaissance, il n'existe actuellement pas connu exploitable attaques contre les fournisseurs de bien répondre à toutes ces considérations de sécurité.
Point de l'être, vous êtes beaucoup plus sûr en utilisant OAuth 1.0 a ou OAuth 2.0 pour autoriser un tiers qu'avec toutes les alternatives. Si vous ne vous sentez pas à l'aise avec ces, la solution est simple: Ne pas autoriser des tiers à accéder à votre compte. Il y a certainement beaucoup de raisons pour lesquelles vous pourriez ne pas vouloir faire cela.
Projectiles magiques n'existent pas. Il n'y a pas une telle chose comme une sécurité parfaite, et en utilisant en utilisant OAuth ne sera certainement pas faire quelque chose de être sécurisé. Ce qu'il fait faire, est d'éliminer le besoin pour une certaine insécurité anti-modèle, à savoir exposer nom d'utilisateur et le mot de passe à des tiers, comme un formulaire d'autorisation de subvention. Critiquant le cahier des charges pour défaut de parvenir à quelque chose, il n'était pas en train de l'atteindre et ne pouvait pas atteindre, même si elle tentait est un peu étrange.
Je pense que l'OP a dit que vous pourriez ouvrir une popup avec un faux panneau de connexion et de voler quelqu'un du mot de passe de cette façon. Une sorte d'attaque de phishing, je suppose. Si l'utilisateur n'a pas inspecter l'emplacement de la barre ils ne serait pas le plus sage, et à peu près toutes les URL avec le mot google ou facebook dans il sera probablement une pièce de théâtre à un utilisateur.
OriginalL'auteur Bob Aman
On dirait que vous vous êtes confus au sujet de ce qui n'est pas sécurisé. Si je comprends bien, le protocole d'authentification OAuth lui-même, si elles sont appliquées correctement, il est sécurisé. C'est juste que c'est facile à mettre en œuvre de manière inadéquate, et les utilisateurs se confondent, car ils ne comprennent pas vraiment ce qu'ils font.
Par exemple, ce que LinkedIn est en train de faire est tout faux. Je n'aurais jamais de leur donner mon compte gmail de l'information de cette façon. Dans l'ordre pour moi de donner mon compte gmail de l'information, j'insiste sur voyant que mon navigateur est à l'aide de SSL avec Google et donc la racine de la page provient de Google.
Puis il ya la question de faire confiance à Google pour correctement dites-moi ce que l'accès est demandé et par qui. Si je n'ai pas confiance en eux, pour ce faire, je ne devrais pas être en utilisant OAuth.
Google est une grande entreprise avec une grande base de code. Il peut être raisonnable de faire confiance à gmail pour garder vos données en toute sécurité, mais ne pas faire confiance à un autre cadre de Google pour fournir une INTERFACE utilisateur claire et unspoofable. Cela dit, le protocole OAuth les gars savent comment concevoir des protocoles de sécurité. Le problème de venir avec une INTERFACE utilisateur qui met en évidence à différents utilisateurs de différentes cultures de quelle autorité ils sont octroi est encore un sujet de recherche ouvert.
OriginalL'auteur Omnifarious