Wie speichere ich den OAuth v1-Consumer-Schlüssel und das zugehörige Geheimnis für einen Open Source-Desktop-Twitter-Client, ohne ihn dem Benutzer preiszugeben?

32

Ich möchte einen Thick-Client-Desktop-Open-Source-Twitter-Client erstellen. Ich verwende .NET als Sprache und Twitterizer als OAuth / Twitter-Wrapper und meine App wird wahrscheinlich als Open Source veröffentlicht.

Um ein OAuth-Token zu erhalten, sind vier Informationen erforderlich:

  1. Access Token (Twitter-Benutzername)
  2. Zugriffsgeheimnis (Twitter-Passwort)
  3. Verbraucherschlüssel
  4. Verbrauchergeheimnis

Die zweiten beiden Informationen dürfen nicht wie ein privater PGP-Schlüssel weitergegeben werden. Aufgrund des Entwurfs des OAuth-Berechtigungsflusses müssen diese jedoch in der nativen App vorhanden sein. Selbst wenn die Anwendung nicht Open Source war und der Konsumentenschlüssel / das Konsumentengeheimnis verschlüsselt waren, konnte ein angemessen erfahrener Benutzer Zugriff auf das Konsumentenschlüssel / das Konsumentengeheimnis-Paar erhalten.

Meine Frage ist also, wie ich dieses Problem umgehen kann. Was ist die richtige Strategie für einen Desktop-Twitter-Client, um seinen Consumer-Schlüssel und sein Geheimnis zu schützen?

open-source  desktop-application  twitter  oauth 
— Justin Dearing
quelle
+1 Ich habe auch die gleichen Sorgen. Die Frage ist jedoch nicht spezifisch für Desktop-Umgebungen oder Twitter - dieses Authentifizierungsschema ist meiner Meinung nach bei Webservices sehr verbreitet.
— vemv
Da Ihre Frage in etwa so abstrahiert werden kann, dass "wie geheime Daten auf einem Client gespeichert werden", sind Sie möglicherweise in der Lage, mehr Antworten zu erhalten, wenn Sie eine neue Frage stellen, die weniger twitter-spezifisch ist. IMO.
— Jeff Welling
1
+1 Ich bin auch neugierig, was die beste Vorgehensweise hier ist. In meiner Qt-Anwendung verwende ich OAuth, speichere aber nur die Consumer-Details als Zeichenfolgen (QString) in der Binärdatei.
— Fejd
1
Jeff, das ist eine sehr gute Möglichkeit, dass ich etwas völlig Falsches mit OAuth tue. Ich bekomme allmählich das Gefühl, dass ich das Consumer-Schlüssel / Geheimnis-Paar verwenden soll, um temporäre Geheimnisse zu generieren, und dass es der richtige Weg ist, irgendwo einen Webdienst zu haben, um diese Geheimnisse zu generieren. Wenn Sie diese Frage über OAuth hinaus verallgemeinern, werden Sie solche Antworten verpassen.
— Justin Dearing

Antworten:

5

Ich habe eine Antwort gefunden, die den Weg widerspiegelt , den ich mir überlegt habe, auf dem Hueniversum zu fahren . Der Artikel Beyond the OAuth Web Redirection Flow ( Jenseits des OAuth-Webumleitungsflusses) enthält einige Vorschläge, von denen einer eine Web-URL ist, die den Token-Austauschprozess unterstützt. Ich muss einen Weg finden, um richtig zu authentifizieren, dass meine App die Authentifizierung für diese Proxy-Seite anfordert. Das ist jedoch möglich.

— Justin Dearing
quelle
3

Ich kann mich irren, aber wenn Sie Schlüssel mit dem Desktop oder der mobilen App bündeln, Open Source oder nicht, ist es möglich, darauf zuzugreifen. Wenn uns Dienste wie Twitter und Tumblr dazu zwingen, nur die OAuth-API zu verwenden, haben wir zwei Möglichkeiten:

  • Richten Sie für jede App einen Authentifizierungs-Proxy-Dienst ein
  • Schlüssel mit der App bündeln

Ersteres ist schwieriger und kostenintensiver und für kleine und Open-Source-Apps nicht unbedingt wartbar. Letzteres bedeutet, dass die App blockiert werden kann und wird, sobald die Spammer die Schlüssel stehlen. Da Twitter und Tumblr noch keine bessere Option anbieten und alle Desktop-Clients, einschließlich Open Source-Clients, auf den neuesten Stand bringen, wird vorgeschlagen, "Big Fish" -Schlüssel zu verteilen und als Fallback zu verwenden .

Schließlich besteht die Möglichkeit, jeden Benutzer zum Abrufen von API-Schlüsseln zu zwingen .

— Sastanin
quelle
3

Abschnitt 4.6 von RFC 5849 , der OAuth 1 definiert, besagt, dass das Verbrauchergeheimnis trotz der Verwendung von Twitter in der Praxis niemals für Desktop-Verbraucher vorgesehen war. Wie Nelson Elhage in " Dear Twitter " betonte, kann und kann Twitter Consumer-Keys von Desktop-Clients kündigen, vorausgesetzt, der Client ist nicht zu groß, um zu scheitern. Es gibt jedoch zwei Problemumgehungen, um die Verwendung von OAuth 1 in einer Desktop- oder Mobilanwendung zu ermöglichen.

Eine Möglichkeit besteht darin, das gesamte Twitter-Protokoll über einen von Ihnen betriebenen Server zu proxen. Auf diese Weise bleibt das Consumer-Geheimnis auf Ihrem Server. Dies ist die von Dick Hardt , Herausgeber der OAuth 1-Spezifikation, empfohlene Problemumgehung. Diese Problemumgehung betrifft nicht die Kosten für den Betrieb dieses Servers.

Die andere Möglichkeit, wie in einem Beitrag von Raffi Krikorian an die Twitter-Entwicklergruppe Google und einem Beitrag von Chris Steipp an eine Wikipedia-Mailingliste vorgeschlagen, besteht darin, dass "jeder Benutzer seine Kopie Ihrer Desktop-Anwendung als seinen eigenen Verbraucher registriert". Anschließend kopiert der Benutzer den neu registrierten Consumer-Schlüssel und das Consumer-Geheimnis und fügt sie in Ihre Anwendung ein. Das Handbuch für Ihre Anwendung muss dann detaillierte Anweisungen zum Registrieren einer neuen Anwendung auf der Entwickler-Website von Twitter enthalten. Diese offizielle Einschränkung hat einige praktische Probleme:

  • Ihr Kunde hat gegenüber bekannten proprietären Kunden einen Usability-Nachteil.
  • Das Formular zum Erstellen einer neuen App bietet offenbar keine Möglichkeit, die erforderlichen Felder im Voraus auszufüllen. Dies bedeutet, dass Sie die Anleitung zur Registrierung in Ihrem Handbuch aktualisieren müssen, wenn Twitter das Verfahren zur Registrierung einer App ändert.
  • Die Entwicklervereinbarung setzt voraus, dass Benutzer volljährig sind, um einen verbindlichen Vertrag abzuschließen. Dies bedeutet, dass ein Benutzer Ihrer Anwendung im Alter von 13 bis 17 Jahren die Zustimmung eines Elternteils im Namen des Benutzers einholen muss.
  • Die Entwicklerrichtlinie von Twitter untersagt die Massenregistrierung von Anwendungen und das "Knien von Namen", was definiert wird als "Einreichen mehrerer Anwendungen mit derselben Funktion unter verschiedenen Namen". Mir ist kein Präzedenzfall bekannt, ob Twitter nicht verwandte Benutzer, die separate Kopien einer Anwendung registriert haben, als "Namensbesetzer" behandelt hat.
— Damian Yerrick
quelle
-2

Ich werde antworten, aber sei gewarnt, dass ich mich nicht selbst darum gekümmert habe. Ich gehe von bewährten Praktiken und vorhandenen relevanten Erfahrungen aus.

Ich würde mir nicht allzu viele Sorgen machen. Wenn es sich bei Ihrem Client um Open Source handelt, haben sie ohnehin Zugriff auf die Quelle, und der Versuch, zu steuern, was sie mit Ihrem Programm tun, widerspricht der Natur von Open Source (obwohl das, was Sie versuchen, nicht zu tun ).

Wenn jemand über ausreichende Kenntnisse verfügt, um Ihr Programm zu debuggen und Ihren Schlüssel zu extrahieren, weiß er wahrscheinlich, wie er mehr tun kann, und Sie könnten sehr gut Ihre Zeit damit verschwenden, eine weitere Sperrung vorzunehmen.

Vorsichtshalber würde ich die Schlüssel von Zeit zu Zeit wechseln (wenn möglich), aber wenn sie nur so tun können, als ob sie Ihr Programm wären, klingt das für mich nicht allzu ernst.

Vollständige Offenlegung, ich bin nicht vertraut mit Twitters API, twitterizers API, oauth Anforderungen oder irgendetwas anderem, was sich fraglich anhört;)

— Jeff Welling
quelle
4
Es geht nicht darum, zu versuchen, mit dem Programm zu kontrollieren, sondern darum, dass Menschen sich selbst falsch darstellen. Der Schlüssel und das Geheimnis des Verbrauchers ist, wie ich Twitter sage, dass "diese App von mir stammt", ähnlich wie ein SSL-Zertifikat Vertrauen schafft. Ich würde niemals ein SSL-Zertifikat mit einer von mir geschriebenen Web-App verteilen. Wenn Leute meine App modifizieren, sollten sie in der Tat ihren eigenen Consumer Key / Secret beantragen und sich als Autor der App von Twitter für ihren Build registrieren.
— Justin Dearing
Hervorragender Punkt, ich hatte einen schleichenden Verdacht, dass dies der Zweck des Verbraucherschlüssels war, wusste es aber nicht genau. In diesem Fall um ehrlich zu sein, glaube ich nicht , es ist eine Möglichkeit , Ihre App zu schützen. Für mich hört sich das so an, als hätte Twitter diese Methode gewählt, damit mobile Apps geschrieben werden können, Desktop-Apps jedoch nicht - mobile Plattformen sind weitgehend gesperrt. In diesem Fall empfiehlt es sich, den Schlüssel in einer separaten Datei oder Variablen abzulegen, die Sie nicht mit dem Quellcode freigeben. Meines Wissens verstößt dies nicht gegen die GPL. Ich würde es lieben, in irgendetwas oder allem, was falsch ist, bewiesen zu werden.
— Jeff Welling
-4

Der Verbraucherschlüssel und das Geheimnis sind anwendungsgebunden und nicht benutzergebunden. Mit diesen Informationen weiß der OAuth-Anbieter, mit welcher Anwendung er es zu tun hat. Der Rest, das Zugriffstoken und das Geheimnis werden nach Abschluss der ersten Schritte abgerufen.

In diesem Blogbeitrag finden Sie weitere Informationen zur Funktionsweise des Protokolls.

— Yblih
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.