OAuth-Geheimnisse in mobilen Apps

Wenn Sie das OAuth-Protokoll verwenden, benötigen Sie eine geheime Zeichenfolge, die Sie von dem Dienst erhalten, an den Sie delegieren möchten. Wenn Sie dies in einer Web-App tun, können Sie das Geheimnis einfach in Ihrer Datenbank oder im Dateisystem speichern. Wie können Sie es jedoch am besten in einer mobilen App (oder einer Desktop-App) handhaben?

Das Speichern der Zeichenfolge in der App ist offensichtlich nicht gut, da jemand sie leicht finden und missbrauchen könnte.

Ein anderer Ansatz wäre, es auf Ihrem Server zu speichern und die App es bei jedem Lauf abrufen zu lassen, ohne es auf dem Telefon zu speichern. Dies ist fast genauso schlimm, da Sie die URL in die App aufnehmen müssen.

Die einzige praktikable Lösung, die ich finden kann, besteht darin, zuerst das Zugriffstoken wie gewohnt zu erhalten (vorzugsweise über eine Webansicht in der App) und dann die gesamte weitere Kommunikation über unseren Server weiterzuleiten, wodurch das Geheimnis an die Anforderungsdaten angehängt und kommuniziert wird mit dem Anbieter. Andererseits bin ich ein Sicherheits-Noob, daher würde ich gerne die Meinung einiger sachkundiger Leute dazu hören. Es scheint mir nicht, dass die meisten Apps diese Anstrengungen unternehmen, um die Sicherheit zu gewährleisten (Facebook Connect geht beispielsweise davon aus, dass Sie das Geheimnis direkt in Ihre App einfügen).

Eine andere Sache: Ich glaube nicht, dass das Geheimnis darin besteht, das Zugriffstoken zunächst anzufordern, sodass dies ohne Beteiligung unseres eigenen Servers möglich ist. Hab ich recht?

Ja, dies ist ein Problem mit dem OAuth-Design, mit dem wir uns konfrontiert sehen. Wir haben uns dafür entschieden, alle Anrufe über unseren eigenen Server zu übertragen. OAuth war in Bezug auf Desktop-Apps nicht vollständig ausgelöscht. Es gibt keine perfekte Lösung für das Problem, das ich gefunden habe, ohne OAuth zu ändern.

Wenn Sie darüber nachdenken und die Frage stellen, warum wir Geheimnisse haben, dient dies hauptsächlich der Bereitstellung und Deaktivierung von Apps. Wenn unser Geheimnis gefährdet ist, kann der Anbieter nur die gesamte App wirklich widerrufen. Da wir unser Geheimnis in die Desktop-App einbetten müssen, sind wir irgendwie durcheinander.

Die Lösung besteht darin, für jede Desktop-App ein anderes Geheimnis zu haben. OAuth macht dieses Konzept nicht einfach. Eine Möglichkeit besteht darin, dass der Benutzer selbst ein Geheimnis erstellt und den Schlüssel selbst in Ihre Desktop-App eingibt (einige Facebook-Apps haben lange Zeit etwas Ähnliches getan, indem der Benutzer Facebook erstellt hat, um seine benutzerdefinierten Quizes einzurichten und) Mist). Es ist keine großartige Erfahrung für den Benutzer.

Ich arbeite an einem Vorschlag für ein Delegierungssystem für OAuth. Das Konzept ist, dass wir mit unserem eigenen geheimen Schlüssel, den wir von unserem Anbieter erhalten, unser eigenes delegiertes Geheimnis an unsere eigenen Desktop-Clients ausgeben können (eines für jede Desktop-App im Grunde) und diesen Schlüssel dann während des Authentifizierungsprozesses an die oberste Ebene senden Anbieter, der uns zurückruft und mit uns erneut validiert. Auf diese Weise können wir unsere eigenen Geheimnisse, die wir jedem Desktop-Client preisgeben, widerrufen. (Ausleihen von SSL). Dieses gesamte System wäre auch für Webservices mit Mehrwert geeignet, die Anrufe an einen Webservice eines Drittanbieters weiterleiten.

Der Prozess kann auch ohne Rückrufe für die Delegierungsüberprüfung durchgeführt werden, wenn der Top-Level-Anbieter eine API zum Generieren und Widerrufen neuer delegierter Geheimnisse bereitstellt. Facebook macht etwas Ähnliches, indem es Facebook-Apps ermöglicht, dass Benutzer Unter-Apps erstellen können.

Es gibt einige Online-Gespräche zu diesem Thema:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

Die Lösung von Twitter und Yammer ist eine Authentifizierungs-Pin-Lösung: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Mit OAUth 2.0 können Sie das Geheimnis auf dem Server speichern. Verwenden Sie den Server, um ein Zugriffstoken zu erhalten, das Sie dann in die App verschieben, und Sie können direkt von der App aus Anrufe an die Ressource tätigen.

Bei OAuth 1.0 (Twitter) ist das Geheimnis erforderlich, um API-Aufrufe durchzuführen. Das Proxying von Anrufen über den Server ist die einzige Möglichkeit, um sicherzustellen, dass das Geheimnis nicht gefährdet wird.

Beide erfordern einen Mechanismus, von dem Ihre Serverkomponente weiß, dass er von Ihrem Client aufgerufen wird. Dies geschieht normalerweise bei der Installation und unter Verwendung eines plattformspezifischen Mechanismus, um beim Aufruf Ihres Servers eine App-ID zu erhalten.

(Ich bin der Herausgeber der OAuth 2.0-Spezifikation)

Eine Lösung könnte darin bestehen, das OAuth-Geheimnis fest in den Code zu codieren, jedoch nicht als einfache Zeichenfolge. Verschleiern Sie es auf irgendeine Weise - teilen Sie es in Segmente auf, verschieben Sie Zeichen um einen Versatz, drehen Sie es - machen Sie einige oder alle dieser Dinge. Ein Cracker kann Ihren Bytecode analysieren und Zeichenfolgen finden, aber der Verschleierungscode ist möglicherweise schwer herauszufinden.

Es ist keine narrensichere Lösung, sondern eine billige.

Abhängig vom Wert des Exploits können einige geniale Cracker größere Anstrengungen unternehmen, um Ihren Geheimcode zu finden. Sie müssen die Faktoren abwägen - die Kosten der zuvor genannten serverseitigen Lösung, den Anreiz für Cracker, mehr Aufwand für die Suche nach Ihrem Geheimcode zu betreiben, und die Komplexität der Verschleierung, die Sie implementieren können.

Speichern Sie das Geheimnis nicht in der Anwendung.

Sie benötigen einen Server, auf den die Anwendung (offensichtlich) über https zugreifen kann, und Sie speichern das Geheimnis darauf.

Wenn sich jemand über Ihre Mobil- / Desktopanwendung anmelden möchte, leitet Ihre Anwendung die Anforderung einfach an den Server weiter, der das Geheimnis anfügt und an den Dienstanbieter sendet. Ihr Server kann Ihrer Anwendung dann mitteilen, ob sie erfolgreich war oder nicht.

Wenn Sie dann vertrauliche Informationen vom Dienst abrufen müssen (Facebook, Google, Twitter usw.), fragt die Anwendung Ihren Server und Ihr Server gibt sie nur dann an die Anwendung weiter, wenn die Verbindung ordnungsgemäß hergestellt ist.

Es gibt eigentlich keine andere Option, als sie auf einem Server zu speichern. Nichts auf der Client-Seite ist sicher.

Hinweis

Dies schützt Sie jedoch nur vor böswilligen Clients, nicht jedoch vor böswilligen Clients und nicht vor anderen böswilligen Clients (Phising) ...

OAuth ist im Browser ein viel besseres Protokoll als auf Desktop / Mobile.

Es gibt eine neue Erweiterung des Berechtigungscode-Gewährungstyps namens Proof Key for Code Exchange (PKCE) . Damit brauchen Sie kein Kundengeheimnis.

PKCE (RFC 7636) ist eine Technik zum Sichern öffentlicher Clients, die kein Clientgeheimnis verwenden.

Es wird hauptsächlich von nativen und mobilen Apps verwendet, aber die Technik kann auch auf jeden öffentlichen Client angewendet werden. Es erfordert zusätzliche Unterstützung durch den Autorisierungsserver, sodass es nur von bestimmten Anbietern unterstützt wird.

von https://oauth.net/2/pkce/

Weitere Informationen finden Sie im vollständigen RFC 7636 oder in dieser kurzen Einführung .

Hier ist etwas zum Nachdenken. Google bietet zwei OAuth-Methoden an ... für Web-Apps, bei denen Sie die Domain registrieren und einen eindeutigen Schlüssel generieren, und für installierte Apps, bei denen Sie den Schlüssel "anonym" verwenden.

Vielleicht habe ich etwas in der Lesung beschönigt, aber es scheint, dass das Teilen des eindeutigen Schlüssels Ihrer Webanwendung mit einer installierten App wahrscheinlich sicherer ist als die Verwendung von "anonym" in der offiziell installierten App-Methode.

Mit OAuth 2.0 können Sie einfach den clientseitigen Ablauf verwenden, um ein Zugriffstoken zu erhalten, und dieses Zugriffstoken dann verwenden, um alle weiteren Anforderungen zu authentifizieren. Dann brauchst du überhaupt kein Geheimnis.

Eine schöne Beschreibung zur Implementierung finden Sie hier: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Ich habe nicht viel Erfahrung mit OAuth - aber erfordert nicht jede Anfrage nicht nur das Zugriffstoken des Benutzers, sondern auch einen Anwendungskonsumentenschlüssel und ein Geheimnis? Selbst wenn jemand ein mobiles Gerät stiehlt und versucht, Daten daraus abzurufen, benötigt er einen Anwendungsschlüssel und ein Geheimnis, um tatsächlich etwas tun zu können.

Ich dachte immer, die Absicht hinter OAuth war, dass jeder Tom, Dick und Harry, der ein Mashup hatte, Ihre Twitter-Anmeldeinformationen nicht im Klartext speichern musste. Ich denke, es löst dieses Problem trotz seiner Einschränkungen ziemlich gut. Außerdem wurde es nicht wirklich für das iPhone entwickelt.

Ich stimme Felixyz zu. OAuth ist zwar besser als Basic Auth, hat aber noch einen langen Weg vor sich, um eine gute Lösung für mobile Apps zu sein. Ich habe mit OAuth gespielt, um eine Handy-App bei einer Google App Engine-App zu authentifizieren. Die Tatsache, dass Sie das Verbrauchergeheimnis auf dem mobilen Gerät nicht zuverlässig verwalten können, bedeutet, dass standardmäßig der "anonyme" Zugriff verwendet wird.

Der Browser-Autorisierungsschritt der OAuth-Implementierung der Google App Engine führt Sie zu einer Seite, auf der Text enthalten ist wie: "Die Site <Site-Site> fordert den Zugriff auf Ihr Google-Konto für die unten aufgeführten Produkte an."

YourApp (yourapp.appspot.com) - nicht mit Google verbunden

etc

Es wird <some-site> von dem Domain- / Hostnamen übernommen, der in der von Ihnen angegebenen Rückruf-URL verwendet wird. Dies kann auf Android alles sein, wenn Sie ein benutzerdefiniertes Schema zum Abfangen des Rückrufs verwenden. Wenn Sie also einen "anonymen" Zugriff verwenden oder Ihr Verbrauchergeheimnis gefährdet ist, kann jeder einen Verbraucher schreiben, der den Benutzer dazu verleitet, Zugriff auf Ihre gae-App zu gewähren.

Die Google OAuth-Autorisierungsseite enthält auch viele Warnungen mit drei Schweregraden, je nachdem, ob Sie "anonym", "geheim" oder "öffentliche Schlüssel" verwenden.

Ziemlich beängstigendes Zeug für den durchschnittlichen Benutzer, der technisch nicht versiert ist. Ich erwarte keinen hohen Prozentsatz an Anmeldeabschlüssen mit solchen Dingen im Weg.

In diesem Blogbeitrag wird erläutert, wie Verbrauchergeheimnisse mit installierten Apps nicht wirklich funktionieren. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Ich versuche auch, eine Lösung für die mobile OAuth-Authentifizierung zu finden und Geheimnisse im Anwendungspaket im Allgemeinen zu speichern.

Und eine verrückte Idee traf mich einfach: Die einfachste Idee ist, das Geheimnis in der Binärdatei zu speichern, aber irgendwie zu verschleiern, oder mit anderen Worten, Sie speichern ein verschlüsseltes Geheimnis. Das bedeutet, dass Sie einen Schlüssel speichern müssen, um Ihr Geheimnis zu entschlüsseln, was uns den Kreis geschlossen zu haben scheint. Warum jedoch nicht einfach einen Schlüssel verwenden, der sich bereits im Betriebssystem befindet, dh vom Betriebssystem und nicht von Ihrer Anwendung definiert wird?

Um meine Idee zu verdeutlichen, wählen Sie eine vom Betriebssystem definierte Zeichenfolge aus, egal welche. Verschlüsseln Sie dann Ihr Geheimnis mit dieser Zeichenfolge als Schlüssel und speichern Sie diese in Ihrer App. Entschlüsseln Sie dann zur Laufzeit die Variable mit dem Schlüssel, der nur eine Betriebssystemkonstante ist. Jeder Hacker, der in Ihre Binärdatei schaut, sieht eine verschlüsselte Zeichenfolge, aber keinen Schlüssel.

Wird es funktionieren?

Hier habe ich die sichere Möglichkeit beantwortet, Ihre oAuth-Informationen in einer mobilen Anwendung zu speichern

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook implementiert OAuth (noch) nicht genau, hat jedoch eine Möglichkeit implementiert, Ihr Geheimnis nicht in Ihre iPhone-App einzubetten: https://web.archive.org/web/20091223092924/http://wiki. developer.facebook.com/index.php/Session_Proxy

Was OAuth betrifft, ja, je mehr ich darüber nachdenke, desto mehr sind wir vollgestopft. Vielleicht wird dies das Problem beheben.

Keine dieser Lösungen verhindert, dass ein entschlossener Hacker Pakete abruft, die von seinem mobilen Gerät (oder Emulator) gesendet wurden, um das Client-Geheimnis in den http-Headern anzuzeigen.

Eine Lösung könnte darin bestehen, ein dynamisches Geheimnis zu haben, das aus einem Zeitstempel besteht, der mit einem privaten 2-Wege-Verschlüsselungsschlüssel und -Algorithmus verschlüsselt ist. Der Dienst entschlüsselt dann das Geheimnis und bestimmt, ob der Zeitstempel +/- 5 Minuten beträgt.

Selbst wenn das Geheimnis gefährdet ist, kann der Hacker es auf diese Weise nur maximal 5 Minuten lang verwenden.

Wie andere bereits erwähnt haben, sollte es kein wirkliches Problem geben, das Geheimnis lokal auf dem Gerät zu speichern.

Darüber hinaus können Sie sich immer auf das UNIX-basierte Sicherheitsmodell von Android verlassen: Nur Ihre Anwendung kann auf das zugreifen, was Sie in das Dateisystem schreiben. Schreiben Sie die Informationen einfach in das Standard-SharedPreferences-Objekt Ihrer App.

Um das Geheimnis zu erlangen, müsste man Root-Zugriff auf das Android-Handy erhalten.