OAuth-Geheimnisse in mobilen Apps

137

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?

iphone android security mobile oauth Felixyz
quelle
Es tut mir leid, wenn ich das Offensichtliche nicht verstehe, aber was ist das Problem beim Speichern der Codes in der Datenbank der Anwendung? Da diese Token generiert und gespeichert werden, nachdem der Benutzer sein Konto authentifiziert hat, sollte davon ausgegangen werden können, dass der Benutzer möchte, dass das mobile Gerät den Zugriff speichert, um Zugriff zu haben.
Poke
Selbst nachdem der Benutzer Sie zum Zugriff auf sein Konto autorisiert hat (z. B. auf Twitter), müssen Sie ein Geheimnis verwenden, das Sie von dem Dienst erhalten haben, auf den Sie zugreifen möchten. Dieses Geheimnis wird bei der gesamten Kommunikation mit ihrem Server zusammen mit dem Authentifizierungsschlüssel und einigen anderen Schlüsseln verwendet. Ja, Sie können den Zugriffsschlüssel speichern, aber das Geheimnis sollte nicht gespeichert werden, da es mit jedem Authentifizierungsschlüssel verwendet werden kann , um den Dienst zu missbrauchen. Auch hier würde ich mich freuen, von Leuten korrigiert zu werden, die mehr darüber wissen.
Felixyz
1
OAuth bietet eine Authentifizierungsmethode, mit der die Anmeldedaten des ursprünglichen Benutzers gesichert werden. Um dies zu ermöglichen, wird eine neue eindeutige Anmeldekombination generiert, die nur mit der Tastenkombination der eindeutigen Anwendung zusammenarbeitet. Der große Vorteil gegenüber dem Speichern der Anmeldedaten des Benutzers besteht darin, dass diese nach der ersten Autorisierung vollständig sicher sind und der Benutzer in jedem Verstoßfall einfach den Zugriff der Autorisierung widerrufen kann. Und natürlich wäre es nicht sinnvoll, das Geheimnis nicht zu speichern, da der Benutzer sich dann erneut authentifizieren müsste (und das ist nicht das, was der Benutzer wünscht, wenn er der Anwendung Zugriff gewährt).
Poke
@poke Der Authentifizierungsschlüssel, der erhalten wird, wenn der Benutzer Ihre App beim Anbieter genehmigt, sollte gespeichert werden, das geheime Token, das Sie vor der Freigabe der App vom Anbieter erhalten haben, jedoch nicht (im Fall einer Desktop- oder mobilen App; falls vorhanden) In einer Web-App können Sie den Schlüssel natürlich auf dem Server speichern, wie in der Frage angegeben.
Felixyz
4
Gemäß meinem Verständnis von oAuth-- Bei einer Desktop - Anwendung ist es sehr einfach zu sniff / überwachen die HTTP / HTTPS - Datenverkehr mit Tools wie diese ieinspector.com/httpanalyzer/index.html Daher Token und Token - Geheimnis beide können sehr gefunden werden leicht. Der einzige Schutz ist also Ihr Verbrauchergeheimnis. Wenn Ihr Geschäft das Geheimnis in der App speichert und jemand es finden kann, ist es ein Kinderspiel, sich als eine andere App als Ihre App auszugeben. Korrigieren Sie mich, wenn ich falsch liege.
Varun

Antworten:

38

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

Zac Bowling
quelle
Dies ist sehr interessant, obwohl es bestätigt, was ich befürchtet habe, dass OAuth für Desktop- / Mobile-Apps nicht so gut ist. Natürlich müsste ein Angreifer zuerst das Geheimnis herausfinden und dann auch an den Anmeldeinformationen eines anderen riechen, was eine gewisse Entschlossenheit erfordern würde. Die Pin-Lösung ist für den Desktop in Ordnung, für das mobile Imo jedoch zu hartnäckig.
Felixyz
Wie würde Ihr vorgeschlagenes Schema dazu beitragen, Webdienste mit Mehrwert zu schaffen, da dieses Problem für sie nicht gilt? Außerdem sehe ich nicht, wie es funktionieren würde, wenn der Anbieter neue Geheimnisse generiert, da Sie ein "Hauptgeheimnis" benötigen würden, um diese neuen Geheimnisse überhaupt anzufordern, sodass Sie mindestens einen Anruf bei Ihrem eigenen Server benötigen würden (der das enthält Hauptgeheimnis). Aber das ist natürlich besser, als den gesamten Datenverkehr über Ihren eigenen Server zu leiten. Klarstellung herzlich willkommen! Und bitte aktualisieren Sie hier, während Ihr Vorschlag fortschreitet!
Felixyz
5
Nur neugierig: Wie stellen Sie fest, dass das Anrufen Ihres Proxyservers legitim ist?
Davidtbernal
1
Als Antwort auf notJim: Das Hauptrisiko bei der Herausgabe Ihres Kundengeheimnisses besteht darin, dass damit böswillige (oder dumme) Anwendungen entwickelt werden können, die Ihren Ruf beeinträchtigen und das Risiko erhöhen, dass Ihre legitime Anwendung wegen API-Missbrauchs / Missbrauchs heruntergefahren wird. Indem Sie alle Anrufe, die Ihr Geheimnis erfordern, über eine von Ihnen kontrollierte Webanwendung weiterleiten, sind Sie wieder in der Lage, nach Missbrauchsmustern zu suchen und den Zugriff auf Benutzer- oder Zugriffstoken-Ebene zu widerrufen, bevor die von Ihnen verwendete API geschlossen wird Ihren gesamten Service herunterfahren.
Quasistoic
Ich bin mit quasistoic hier einverstanden. Sie müssen einen SSL-fähigen Browser verwenden, um den oauth-Anruf zu bearbeiten. Dies ist aus mehreren Gründen eine gute Sache, einschließlich der einfachen Verwaltung zukünftiger Sicherheitsupdates, und nichts in der tatsächlichen Anwendung muss im Laufe der Zeit aktualisiert werden. Zac weist darauf hin, dass Twitter eine PIN-Lösung vorschlägt, die ich mir auch ausgedacht habe, weil Sie der Anwendung nicht vertrauen können, um den Code sicher zu erhalten. Ich schlage vor, ein 'Nonce' mit einer modernen Verschlüsselung zusammen mit der PIN und dem Geheimnis zu verwenden, um die Anforderungen über den Webserver zu vermitteln.
Mark
18

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)

Dick Hardt
quelle
2
Können Sie den "plattformspezifischen Mechanismus zum Abrufen einer App-ID" erläutern? Wie überprüft die Serverkomponente die Identität des Clients? Ich denke, dies kann mit Client-Provisioning erreicht werden. Stellen Sie beispielsweise für jeden Client ein neues und eindeutiges SSL-Zertifikat bereit. Meinst Du das? Wenn es komplexer ist, können Sie sich vielleicht auf eine ausführlichere Beschreibung beziehen?
Cheeso
2
Ich erinnere mich an einige Sicherheitsleute, die darüber sprachen, wie dies getan werden könnte. Es gibt einen Aufruf an das Betriebssystem, der ein signiertes Token zurückgibt, das Sie dann an Ihren Server senden und überprüfen können. Entschuldigung, ich habe keine Einzelheiten. Es ist ein Fehler, der einige gute Beispiele verwenden könnte.
Dick Hardt
2
@ DickHardt, aber wie stellen Sie in dieser Szenerie sicher, dass die mobile Anwendung wirklich Ihre App ist und keine betrügerische?
Rafael Membrives
11

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.

Jayesh
quelle
1
Ja, ich denke das ist vernünftig. Es würde viel Entschlossenheit erfordern, wenn jemand zuerst das Verbrauchergeheimnis herausholt und dann die Anmeldeinformationen der Leute entreißt, um etwas Gemeines zu tun. Für hochkarätige Apps bin ich mir nicht sicher, ob dies ausreichen würde, aber für eine durchschnittliche App haben Sie meiner Meinung nach Recht, dass Sie die Implementierungszeit gegen eine ziemlich geringe Sicherheitsbedrohung abwägen müssen.
Felixyz
7
Ein Benutzer muss sich nur anstrengen und dann Ihr Geheimnis veröffentlichen oder weitergeben. Sobald Ihr Geheimnis gelüftet ist, steigt das Risiko, dass Ihr Dienst wegen Missbrauchs vollständig heruntergefahren wird, und es liegt völlig außerhalb Ihrer Kontrolle.
Quasistoic
8
Verschleierung ist überhaupt keine Sicherheit. Dies ist schlimmer als gar keine Sicherheit, da es dem Entwickler ein falsches Sicherheitsgefühl gibt. en.wikipedia.org/wiki/Security_through_obscurity
Paul Legato
8
"Verschleierung ist überhaupt keine Sicherheit. Dies ist schlimmer als gar keine Sicherheit, da es dem Entwickler ein falsches Sicherheitsgefühl gibt." Unsinn. Niemand sagt, dass Verschleierung für gute Sicherheit sorgt. Aber wenn ich mit meiner apk ein OAuth-Geheimnis verteile, ist es sicherlich besser, es zu verschleiern als nicht. Verschleierung empfiehlt Google auch beim Speichern von Schlüsseln / Geheimnissen in der App. Nicht zuletzt halten diese Maßnahmen gelegentliche Hacker in Schach, was besser ist als nichts. Pauschalaussagen wie Ihre bedeuten unvollständige Sicherheit ohne Sicherheit. Das stimmt einfach nicht. Unvollkommen ist einfach unvollkommen.
Hungerghost
1
Verschleierung hilft NICHT, denn egal wie viel Verschiebung oder Codierung Sie vornehmen, Sie erstellen den Schlüssel immer noch zusammen und verwenden ihn zum Erstellen Ihrer API-Anforderung. Es ist ziemlich einfach, APIs dynamisch an den richtigen Stellen zu verknüpfen, um die von Ihnen gesendete Anforderung vor der HTTPS-Verschlüsselung auszugeben. Betten Sie also bitte keine geheimen Schlüssel in Ihre App ein, es sei denn, es gibt wirklich keine mögliche Alternative.
C0deH4cker
6

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.

Gudradain
quelle
1
macht das das Leben des Hackers nicht einfacher?! Denn jetzt benötigen wir für den Zugriff auf die Serverressourcen technisch gesehen nur die Client-ID, da der Server das Geheimnis ohnehin an die Anfrage anhängt. vermisse ich etwas
Hudi Ilfeld
@HudiIlfeld Ja, Ihnen fehlt etwas: Der Client muss sich beim Server anmelden. Solange er sich nicht anmeldet, gibt der Server nichts zurück. Eine Möglichkeit, dies zu verwalten, besteht darin, dass der Server nach dem erstmaligen Senden des Berechtigungsnachweises ein Zugriffstoken an den Client zurückgibt und der Client dieses Zugriffstoken dann bei jeder zukünftigen Anforderung sendet. Hier gibt es viele Möglichkeiten.
Gudradain
4

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 .

Johannes Filter
quelle
2

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.

LetMyPeopleCode
quelle
2

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

Joel Richard
quelle
Vorausgesetzt, der Dienst unterstützt "den clientseitigen Ablauf". Viele tun dies nicht, sondern benötigen die Client-ID und das Client-Geheimnis, um dieses Zugriffstoken zu erhalten.
Damian Yerrick
0

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.

bpapa
quelle
Sie haben Recht, OAuth wurde hauptsächlich für Web-Apps entwickelt, und ich bin sicher, dass es dafür gut funktioniert. Ja, Sie benötigen das Verbrauchertoken und das Geheimnis, um jede Anfrage zu signieren, und das Problem besteht darin, wo das Geheimnis gespeichert werden soll. Wenn jemand den Zugangsschlüssel stiehlt, ist dies keine große Sache, da er widerrufen werden kann. Wenn jedoch jemand den Verbraucherschlüssel erhält, wurde jede Kopie Ihrer App kompromittiert.
Felixyz
Für OAuth 1 muss jede Anforderung signiert werden. OAuth 2 benötigt nur das Zugriffstoken. Beide benötigen den Schlüssel und das Geheimnis, wenn sie einen Token erwerben.
Dick Hardt
0

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/

Martin Bayly
quelle
0

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?

Daniel Thorpe
quelle
3
Guter Gedanke, aber nein. Der Cracker würde nur die Binärdatei sehen, die auf die Adresse der Betriebssystemkonstante zeigt.
GrayB
0

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.

Maximvs
quelle
-2

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.

Christopher Orr
quelle
3
Wie wer schon erwähnt? Wenn Sie den Kommentar von Poke meinen, sehen Sie meine Antwort auf dieses Geheimnis! = Authentifizierungsschlüssel. Letzteres kann sicher aufbewahrt werden, Ersteres nicht. Ich weiß nichts über Android, aber es ist überhaupt nicht schwer, Root-Zugriff auf ein iPhone zu erhalten. Beachten Sie, dass das Geheimnis in allen Instanzen der App gleich ist, sodass ein Angreifer nur auf eine Binärdatei zugreifen muss. Und selbst wenn sie keinen Root-Zugriff auf das Gerät erhalten könnten, könnten sie die Binärdatei in einem anderen in die Hände bekommen und das geheime Token daraus ziehen.
Felixyz
1
Nur um es hinzuzufügen, ist es sehr einfach, auch Android-Handys zu
rooten