Best practice für die Lagerung und den Schutz von privaten API Schlüssel in Anwendungen

Meisten app-Entwickler integrieren einige Bibliotheken von Drittanbietern in Ihre apps. Wenn es zum Zugriff auf einen Dienst wie Dropbox oder YouTube, oder für die Anmeldung abstürzt. Die Zahl der third-party-Bibliotheken und-Dienstleistungen, ist atemberaubend. Die meisten dieser Bibliotheken und-services integriert werden, indem irgendwie die Authentifizierung bei dem Dienst, die meisten der Zeit, geschieht dies über einen API-Schlüssel. Für die Zwecke der Gefahrenabwehr, Dienstleistungen generieren in der Regel einen öffentlichen und einen privaten, oft auch bezeichnet als secret key. Leider, um die Verbindung zu den services, die diese privaten Schlüssel verwendet werden muss, sich zu authentifizieren, und daher wahrscheinlich ein Teil der Anwendung.
Unnötig zu sagen, dass diese Flächen in immensen Sicherheitsproblem. Öffentliche und private-API-Schlüssel extrahiert werden können, werden von APKs in einer Angelegenheit von Minuten und kann leicht automatisiert werden.

Vorausgesetzt, ich habe etwas ähnliches, wie kann ich mich schützen das Geheimnis Schlüssel:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    //SOME MORE CODE HERE

}

Was ist deiner Meinung nach das beste und sicherste Möglichkeit zur Speicherung der privaten Schlüssel? Verschleierung, Verschlüsselung, was denkst du?

rammic.github.io/2015/07/28/versteckt-Geheimnisse-in-android-apps
ich hatte speichern in image/png und bekommst den Schlüssel durch das png als BufferReader

InformationsquelleAutor Basic Coder | 2013-01-28

298
1. Als es ist, die kompilierte Anwendung enthält die Schlüssel-Zeichenfolgen, aber auch die Konstanten-Namen APP_KEY und APP_SECRET. Extrahieren von Schlüsseln aus dieser selbst-dokumentierenden code ist trivial, zum Beispiel mit der standard-Android-tool dx.
2. Können Sie anwenden ProGuard. Es wird lassen Sie den Schlüssel Saiten unberührt, aber es entfernt die Konstanten-Namen. Es wird auch umbenennen von Klassen und Methoden mit kurzen, bedeutungslosen Namen, wo immer es möglich ist. Das extrahieren der keys dauert dann einige Zeit, um herauszufinden, welche Zeichenfolge dient dem Zweck.
  
  Beachten Sie, dass die Einrichtung ProGuard sollte nicht so schwierig, wie Sie befürchten. Um mit anzufangen, müssen Sie nur aktivieren, ProGuard, wie dokumentiert im Projekt.Eigenschaften. Wenn es irgendwelche Probleme mit Drittanbieter-Bibliotheken, müssen Sie möglicherweise unterdrückt einige Warnungen und/oder verhindern, dass Sie sich verschleiert in proguard-project.txt. Zum Beispiel:
```
-dontwarn com.dropbox.**
-keep class com.dropbox.** { *; }
```
  Dies ist eine brute-force-Ansatz; Sie optimieren können, um eine solche Konfiguration sobald die verarbeiteten Anwendung funktioniert.
3. Können Sie verschleiern die strings manuell in Ihrem code, zum Beispiel mit einer Base64-Kodierung oder vorzugsweise mit etwas mehr kompliziert; vielleicht auch nativen code. Ein hacker wird dann statisch reverse-Engineering Ihrer Codierung oder dynamisch abzufangen, die Decodierung in der richtigen Stelle.
4. Können Sie anwenden, ein kommerzielles Verschlüsselungsprogramm, wie ProGuard spezialisierte Geschwister DexGuard. Es kann zusätzlich verschlüsseln/verschleiern der strings und Klassen für Sie. Extrahieren Sie die Tasten dann nimmt Sie noch mehr Zeit und know-how.
5. Könnten Sie ausführen können, um Teile der Anwendung, die auf Ihrem eigenen server. Wenn Sie können, halten Sie die Tasten dort sind Sie sicher.
In der end, es ist ein wirtschaftlicher Kompromiss, den Sie machen müssen: wie wichtig sind die keys, wie viel Zeit oder software, die Sie sich leisten können, wie anspruchsvoll sind die Hacker, die daran interessiert sind, die Schlüssel, wie viel Zeit Sie ausgeben möchten, wie viel Wert ist eine Verzögerung, bevor die Tasten gehackt werden, in welchem Umfang wird jede erfolgreiche Hacker verteilen der Schlüssel, etc. Kleine Stücke von Informationen, wie die Tasten sind schwieriger zu schützen, als ganze Anwendungen. Intrinsisch, nichts auf der client-Seite ist unzerbrechlich, aber man kann sicherlich die Messlatte.

(Ich bin der Entwickler von ProGuard und DexGuard)

Ist das ein lokaler server gesprochen wird in dem fünften Punkt? Würde dies nicht benötigen einen computer, die erfordert, um zu bleiben auf immer? Sorry, ich bin ein Neuling. Kann ich sowas Analysieren?
macht es nicht einen Unterschied machen, wenn der private Schlüssel Zeichenfolge gespeichert wird in der Java-Klasse vs in der String-resource-XML?
Ist es nun möglich, verwenden Sie den Android Keystore-system zur sicheren Speicherung der Schlüssel? ( developer.android.com/training/articles/keystore.html )
Hast du versucht, mit-keystore. Ich will zu verbergen einen API-Schlüssel, der in Java geschrieben-Klasse. Bitte Antworten
Ist Android KeyStore nützlich? (developer.android.com/training/articles/...)

InformationsquelleAutor Eric Lafortune
65

Paar Ideen, die meiner Meinung nach nur erste gibt einige Garantie:
1. Halten Sie Ihre Geheimnisse auf einige server im internet, und, wenn erforderlich, nur greifen Sie und verwenden Sie. Wenn der Benutzer über die Verwendung von dropbox dann nichts hält Sie davon ab, Anforderung an Ihre Website und erhalten Sie Ihren geheimen Schlüssel.
2. Setzen Sie Ihre Geheimnisse im jni code, fügen Sie einige Variablen code, um Ihren Bibliotheken größer und schwieriger zu dekompilieren. Sie könnten auch split key string in einzelne Teile und bewahren Sie Sie an verschiedenen stellen.
3. obfuscator verwenden, auch in Hash-code geheim und später auf unhash es bei Bedarf zu verwenden.
4. Setzen Ihren geheimen Schlüssel als Letzte Pixel eines Bildes in Vermögenswerte. Dann, wenn nötig, Lesen Sie es in Ihrem code. Verschleierung von Ihr code sollte helfen, hide-code, der es Lesen wird.
Wenn Sie wollen, um einen Blick sehen, wie einfach es ist, Lesen Sie die apk-code dann greifen APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

wenn der Nutzer kann die app dekompilieren, obwohl Sie könnten wahrscheinlich bestimmen, verlangen, dass wurde gemacht, um Ihren eigenen server und führen Sie einfach, dass zu bekommen, Geheimnis. Keine silberne Kugel, hier aber ein paar Schritte und ich Wette, du wirst in Ordnung sein! Wenn Ihre app ist super beliebt, wenn auch vielleicht nicht.. Tolle Ideen!
ja, Nummer 1 gibt keine Garantie.
Ich mag die Idee des Versteckens Schlüssel von innen Bilder. +1
Möchten Sie mehr erklären(mit Beispiel oder code snipped vorzugsweise) über die Lösung her? Danke.
dies wird als Steganographie, seinen Weg zu Komplex, um geben Sie ein Beispiel-code hier finden Sie Beispiele über google. Ich habe eins gefunden hier: dreamincode.net/forums/topic/27950-steganography. Die Idee ist toll, aber seit apk-code kann dekompiliert es verdirbt Ihre Schönheit.

InformationsquelleAutor marcinj
20

Befolgen Sie diese 3 einfachen Schritten zu sichern API/Geheimen Schlüssel

Wir verwenden können, Gradle, sichern Sie den API-key oder Secret key.

1. gradle.Eigenschaften (Projekt-Eigenschaften) : variable Erstellen mit Schlüssel.
```
GoolgeAPIKey = "Your API/Secret Key"
```
2. bauen.gradle (Module: app) : Setzen Sie die variable in bauen.gradle zu zugreifen Aktivität oder fragment. Fügen Sie folgenden code zu buildTypes {}.
```
buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}
```
3. Zugreifen Aktivität/Fragment von app BuildConfig :
```
BuildConfig.GoogleSecAPIKEY
```
Update :

Die oben genannte Lösung ist hilfreich bei der open-source-Projekt zu verpflichten, über Git. (Dank an David Rawson und riyaz-ali für Ihren Kommentar).

Gemäß dem Matthäus und Pablo Cegarra Kommentare in der oben beschriebenen Weise ist nicht sicher und Decompiler wird jemand erlauben, um die Ansicht der BuildConfig mit unserem geheimen Schlüssel.

Lösung :

Wir verwenden können, NDK, Sichere API-Keys. Wir können den store-Taster in die nativen C/C++ - Klasse und greifen Sie in unseren Java-Klassen.

Folgen Sie bitte diese blog, sichere API-Schlüssel unter Verwendung von NDK.

Ein follow-up auf, wie store-Token, die sicher auf Android

speichern eines Schlüssels in gradle Datei sicher ist?
sollten nicht eingecheckt werden auf Git, so ist dies ein Weg, um das Geheimnis aus begangen source code, zumindest
Dies verhindert nicht, dass der API-key aus gebündelt in die resultierende apk (es wird hinzufügen, um den erzeugten BuildConfig Datei), obwohl dies definitiv eine gute Idee, verwalten Sie die unterschiedlichen API-keys (wie z.B. in einem open source Projekt)
Mit einem Java-Decompiler wird jemand erlauben, zum anzeigen der Datei BuildConfig und "GoogleSecAPIKEY"
wirklich 11 upvotes? nur zu dekompilieren, open strings und voilá

InformationsquelleAutor SANAT
13

Ein weiterer Ansatz ist, um nicht über das Geheimnis, das Gerät in den ersten Platz! Sehen Mobile-API-Sicherheits-Techniken (vor allem Teil 3).

Mit der Zeit geehrt-tradition der Dereferenzierung, teilen Sie das Geheimnis zwischen Ihrem API-Endpunkt und einen app-Authentifizierung service.

Wenn Ihr Kunde will eine API-Aufruf, es fragt die app auth-Dienst zu authentifizieren (mit starken remote-attestation-Techniken), und er erhält eine zeitlich befristete (in der Regel JWT) token signiert von dem Geheimnis.

Den token gesendet, mit jeder API-Aufruf, wo der Endpunkt überprüfen können, seine Unterschrift, bevor Sie handeln auf die Anforderung.

Das eigentliche Geheimnis ist, niemals auf dem Gerät vorhanden; in der Tat, die app hat nie eine Idee, ob es gültig ist oder nicht, es ragt fordert die Authentifizierung und übergibt den resultierenden token. Als ein netter Vorteil von Dereferenzierung, wenn Sie jemals ändern wollen das Geheimnis, können Sie dies tun, ohne dass die Benutzer zum aktualisieren Ihrer installierten apps.

Also, wenn Sie wollen, schützen Sie Ihr Geheimnis, ohne es in Ihre app in den ersten Platz ist ein ziemlich guter Weg zu gehen.

Dies sollte die akzeptierte Antwort.

InformationsquelleAutor Skip Hovsmith
10

Den App-Secret-key sollte geheim gehalten werden - aber wenn die Freigabe der app
Sie kann rückgängig gemacht werden, indem einige Jungs.

für die Jungs wird es nicht ausblenden, sperren Sie die ProGuard den code. Es ist ein umgestalten und einige bezahlt obfuscators einfügen, die ein paar von bit-Operatoren, um wieder die jk433g34hg3
String. Sie können 5-15 min. länger die hacken, wenn Sie arbeiten 3 Tage 🙂

Beste Weg ist, um es zu halten, wie es ist, imho.

Selbst wenn Sie speichern auf server-Seite( dem PC ) können Sie den Schlüssel gehackt und ausgedruckt. Vielleicht dauert dies am längsten? Jedenfalls ist es eine Angelegenheit von wenigen Minuten oder ein paar Stunden im besten Fall.

Einem normalen Benutzer nicht zu dekompilieren den code.

Wohl nicht die Antwort, die ich hoffte zu bekommen =) ... ich dachte, Sie kann erreichen eine große Sicherheit 🙁
sorry, es ist nicht so, wie man wollte eine brillinant, ultra sichere Lösung, aber für diejenigen, die kann verwenden Sie die compiler, decompiler es gibt keine sichere java-code: sogar der native code kann angezeigt werden mit hexa-viewer und decrtyped. Zumindest einen Versuch Wert...
Proguard nicht verschleiern die tatsächlichen Schlüssel, wenn..? Beste, was zu tun ist, einige einfache encript/decript routine, verschleiern verstecken.
es ist "sichtbar" Entschlüsselungs-routine, ist einfach das Gegenteil machen, und Sie haben die ursprüngliche Zeichenfolge

InformationsquelleAutor

Eine mögliche Lösung ist die Codierung der Daten in Ihre app und verwenden Entschlüsselung zur Laufzeit (wenn Sie verwenden möchten, Daten). Ich empfehle auch die Verwendung progaurd machen es schwer zu Lesen und zu verstehen, die der dekompilierte Quellcode Ihrer app . zum Beispiel lege ich ein codierter Schlüssel in die app und dann eine decode-Methode in meine app zu entschlüsseln, meine geheime Schlüssel zur Laufzeit:

//"the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Der dekompilierte Quellcode der proguarded app ist diese:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

Zumindest ist es kompliziert genug für mich. dies ist die Weise, die ich tun, wenn ich keine Wahl habe, aber speichern Sie einen Wert in meiner Anwendung. Natürlich wissen wir alle: Es ist nicht der beste Weg, aber es funktioniert für mich.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    //Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Dekompiliert version:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

und finden Sie so viele encryptor Klassen mit ein wenig Suche bei google.

InformationsquelleAutor Milad Faridnia

8

Diesem Beispiel eine Anzahl verschiedener Aspekte. Ich erwähne ein paar Punkte, glaube ich, nicht ausdrücklich abgedeckt anderswo.

Schützen das Geheimnis im transit

Das erste, was zu beachten ist, dass der Zugriff auf die dropbox-API mit Ihren die app-Authentifizierung Mechanismus erfordert, dass Sie übertragen Sie Ihre Schlüssel und Geheimnis. Die Verbindung ist HTTPS, was bedeutet, dass Sie nicht abzufangen, den Datenverkehr, ohne die TLS-Zertifikat. Dies soll verhindern, dass eine person, die das abfangen und Lesen die Pakete auf Ihre Reise vom mobilen Gerät an den server. Für den normalen user ist es ein wirklich guter Weg, um die Privatsphäre Ihrer Verkehr.

Was es nicht gut kann, ist die Verhinderung einer bösartigen person, die den Download der app und der Inspektion der Verkehr. Es ist wirklich einfach zu bedienen, eine man-in-the-middle-proxy für den gesamten Verkehr in und aus einem mobilen Gerät. Es würde erfordern, keine Disassemblierung oder reverse engineering von code zu extrahieren Sie den app key und secret in diesem Fall aufgrund der Natur der Dropbox-API.

Könnten Sie tun,pinning, die prüft, ob der TLS-Zertifikat erhalten Sie vom server ist die, die Sie erwarten. Dies fügt einen Scheck an den client und macht es schwieriger, zum abfangen des Datenverkehrs. Dies würde es schwieriger machen, zu inspizieren, um den Verkehr im Flug, aber die Belegung überprüfen Sie geschieht auf dem client, so wäre es wahrscheinlich noch möglich sein, deaktivieren Sie die pinning-test. Es macht es schwieriger aber.

Schützen das Geheimnis in Ruhe

Als einen ersten Schritt, mit so etwas wie proguard wird Ihnen helfen, damit es weniger offensichtlich ist, wo keine Geheimnisse sind, gehalten. Konnte man auch mit dem NDK zum speichern der Schlüssel und das Geheimnis, und senden Sie Anfragen direkt, das würde erheblich reduzieren die Anzahl von Menschen mit den entsprechenden Fähigkeiten zum extrahieren der Informationen. Weitere Verschleierung kann erreicht werden, indem nicht die Speicherung der Werte direkt im Arbeitsspeicher für jede Länge der Zeit, können Sie diese verschlüsseln und entschlüsseln Sie Sie gerade, bevor Sie verwenden, wie vorgeschlagen, durch eine andere Antwort.

Erweiterte Optionen

Wenn du jetzt paranoid darüber machen, dass das Geheimnis überall in Ihrer Anwendung, und Sie haben Zeit und Geld zu investieren in umfassendere Lösungen, dann könnten Sie erwägen, das speichern der Anmeldeinformationen auf Ihren Servern (vorausgesetzt, Sie eine haben). Erhöht das die Latenz der Aufrufe an die API, wie er die Kommunikation über den server, und vielleicht erhöhen die Kosten für den Betrieb Ihrer service aufgrund der erhöhten Datendurchsatz.

Sie haben dann zu entscheiden, wie am besten, um die Kommunikation mit Ihren Servern, um sicherzustellen, dass Sie geschützt sind. Dies ist wichtig, um zu verhindern, dass alle die gleichen Probleme wieder hochkommen mit Ihrem internen API. Die beste Faustregel, die ich geben kann ist nicht zu übermitteln, geheim, unmittelbar, weil der man-in-the-middle-Bedrohung. Stattdessen melden Sie den Verkehr mit Ihrem Geheimnis, und überprüfen Sie die Integrität der Anfragen, die kommen, um Ihre server. Ein standard-Weg, dies zu tun ist, zur Berechnung eines HMAC von Nachricht kodiert, auf ein Geheimnis. Ich arbeite in einem Unternehmen, hat ein security-Produkt, das arbeitet auch in diesem Bereich, die ist, warum diese Art von Sachen, die mich interessieren. In der Tat, hier ist ein blog Artikel von einer meiner Kollegen, der geht über die meisten dieser.

Wie viel sollte ich tun?

Mit Sicherheit Ratschläge, wie diese Sie brauchen, um eine Kosten/nutzen Entscheidung darüber, wie hart Sie wollen, um es für jemanden zu brechen in. Wenn Sie eine bank schützen Millionen von Kunden, die Ihr budget ist völlig anders als jemand, der Unterstützung einer app in Ihrer Freizeit. Es ist praktisch unmöglich zu verhindern, dass jemand brechen Ihre Sicherheit, aber in der Praxis nur wenige Menschen brauchen alle Glocken und pfeift, und mit einigen grundlegenden Vorsichtsmaßnahmen können Sie einen langen Weg.

Sie kopieren und einfügen dieser hier: hackernoon.com/mobile-api-security-techniques-682a5da4fe10 ohne Anerkennung der Quelle.
Ich bin damit einverstanden, dass, sollte er zitiert den Artikel, den Sie verlinkt, aber vielleicht hat er es vergessen, weil beide arbeiten im gleichen Ort...
Auch, Überspringen Sie die Artikel und der blog-post, Sie beruhen auf kam eine Woche nach meiner Antwort.

InformationsquelleAutor ThePragmatist
7

Sicherste Lösung ist, um Ihre Schlüssel auf einem server und leiten Sie alle Anfragen müssen, dass der Schlüssel über den server. So ist der Schlüssel verlässt nie Ihren server, so lange, wie Sie Ihren server sicher ist, dann ist auch Ihr Schlüssel. Natürlich gibt es Leistungseinbußen mit dieser Lösung.

Das problem ist, zu erreichen, dass der server enthält alle secrects sollte ich verwenden, ein Geheimnis, das Key - ich Frage mich, wo ich halten ? 😉 Was ich versuche zu sagen ist - Das ist auch nicht die beste Lösung (glaube nicht, dass es hier eine ideale Lösung)
Das ist nicht wahr, Ihr server ist vollständig unter Ihrer Kontrolle. Was es verlangt, ist völlig bis zu Ihnen.
Können Sie erklären hier, wie ein client kann die Daten verschlüsseln, die er will, an den server senden, während die Schlüssel in die server-Seite ? und wenn Ihre Antwort - Der server sendet die Schlüssel an den client - Also, die gesichert werden müssen! also wieder keine Magische Lösung! kannst du nicht sehen?!
und dann wieder sind wir wieder auf Platz 1. Nehmen wir an, erstellt das Telefon eine zufällige login und der server akzeptiert das, und sendet eine pin(das ist die so genannte private server wir sind im Gespräch). Dann die person, die zerlegt Sie Ihre app sieht, dass alles, das es nimmt, um Zugang zu Ihrem privat der server ist nur ein paar zufällige login, kann er sich selbst. Sag mir, was hält ihn von der Erstellung von ein-und Zugriff auf Ihre server? In der Tat, was ist der Unterschied zwischen Ihrer Lösung und eigentlich die Speicherung von login oder api-Schlüssel, um die Haupt-server (dessen Anmeldeinformationen wollten wir speichern in unserem privaten server)
Die Zufallszahl wird authentifiziert, Telefonnummer und physischen Zugang zu Ihren SMS-Nachrichten. Wenn jemand betrügt, müssen Sie Ihre Informationen. Wenn das nicht gut genug, Sie zu zwingen, zu erstellen Sie eine vollständige Benutzer-Konto und Passwort. Wenn das nicht gut genug ist, Holen Sie sich eine Kreditkarte zu. Wenn das nicht gut genug haben Sie Sie rufen kann. Wenn das nicht gut genug ist Ihnen zu treffen von Angesicht zu Angesicht. Wie sicher/unbequem wollen Sie sein?

InformationsquelleAutor Bernard Igiri
5

Alter zwischen Alter post, aber immer noch gut genug. Ich denke, es zu verbergen in einem .also Bibliothek wäre toll, mit NDK und C++ natürlich auch. .so dass die Dateien angezeigt werden kann in einem hex-editor, aber viel Glück, Dekompilierung,: P

Benutzer können leicht eine Funktion aufrufen, die gemeinsame Bibliothek und bekommen, was ist dort versteckt. Keine Notwendigkeit, decopile.
Nach androidauthority.com/... es gibt keine sichere Möglichkeit, es zu tun in android im moment.
Verstehe nicht, warum das so ist, die 3 upvote. jedem konnte man leicht dekompilieren der app und sehen, wie die ndk-Einstiegspunkt aufgerufen werden :/
Diese Antwort ist schon fast eine der besten Optionen, aber der Autor sollte erwähnen, dass es sehr wichtig ist, sollten Sie auch einen Anruf (innerhalb Ihrer NDK-Bibliothek), um zu sehen, ob die Prüfsumme mit Ihrem APK-wie es sonst jemand nennen können, Ihre NDK-Bibliothek außerhalb Ihrer app
das wäre toll, außer es hat ein großes problem. Wie Sie wissen, welche Datei ist "calling" die native Methode? Wenn Sie hartcodieren den Namen der apk, um zu überprüfen, toll, aber was ist, wenn ich meinen "hack" apk gleichen Ordner wie die "guten" apk? Es wird geprüft, dass die "guten" apk hat eine gute Prüfsumme, und es wird mir erlauben zu führen, dass die native Methode. Es sei denn, es gibt einen Weg, um zu wissen, die Anrufer-Datei von JNI/C++ Seite, dann ist es sinnlos, wie die anderen Optionen.

InformationsquelleAutor Ahmed Awad
4

Was auch immer Sie tun, um zu sichern Sie Ihr geheimer Schlüssel ist nicht eine wirkliche Lösung. Falls der Entwickler kann dekompilieren der Anwendung gibt es keine Möglichkeit zum sichern der Schlüssel versteckt, der Schlüssel ist nur security by obscurity und so ist code-obfuscation. Problem mit Sicherung der ein geheimer Schlüssel ist, um sicherzustellen, dass Sie haben, um die Verwendung einer anderen Taste und dieser Schlüssel muss auch gesichert werden. Denken Sie an einen Schlüssel, versteckt in einer box, die ist gesperrt, mit einem Schlüssel. Legen Sie eine Kiste in einen Raum und sperren Sie das Zimmer. Sie sind mit einem anderen Schlüssel zu sichern. Und dieser Schlüssel ist immer noch hardcoded in der Anwendung.

So, es sei denn, der Benutzer eine PIN eingibt oder eine phrase, es gibt keine Möglichkeit zum ausblenden der Schlüssel. Aber das zu tun, müsste man ein System für die Verwaltung von PINs geschieht out-of-band, was bedeutet, dass durch einen anderen Kanal. Sicherlich nicht praktisch für die Sicherung Tasten für Dienste wie Google-APIs.

InformationsquelleAutor user1611728
3

Den einzig wahren Weg zu halten, diese privat zu halten Sie auf Ihren server, und haben die app senden was auch immer es ist, an den server und der server arbeitet mit Dropbox. Dass Weise, die Sie NIE verteilen Sie Ihre privaten Schlüssel in einem beliebigen format.

Aber wie wollen Sie verhindern, dass der rest der Welt aus aufrufen die server?
Wenn du mit "server" meinst du deinen webserver wo sind die Anmeldeinformationen - Sie können jede Methode, die Sie wollen. einfache Authentifizierung mit Benutzername / Passwort, oauth, active directory, etc. etc. Hängt wirklich davon ab, Ihre Anwendung.
Vielleicht bin ich etwas fehlt, aber nicht das verlangen noch das speichern von Anmeldeinformationen in der app?
Richtig, aber Sie haben gesagt, die app mit dem server authentifizieren ersten. Bedeutet das nicht, dass die Speicherung von einem anderen Satz von Anmeldeinformationen in der app? Ich verstehe die server handhaben würde die eigentliche dropbox nennt.
Nun, es könnte bedeuten, dass, aber er ist eine ganz eigene Berechtigung. Aber Sie müssen nicht. Der Anwendungsfall die ich spreche, ist, dass Sie Ihre app-Benutzer über ein login, um Ihre app sagen mit facebook oder twitter. Sie nicht speichern Sie Ihre Anmeldeinformationen in Ihrer app, den Sie gar nicht kenne. Dass Autorisierung ermöglicht Ihnen den Zugang zu Ihren api-server, der über die Anmeldeinformationen für dropbox, aber keine app oder Benutzer hat Zugriff auf Sie direkt.

InformationsquelleAutor Nick
3

Halten das Geheimnis in firebase database und es sich aus, wenn die app startet ,
Es ist weit besser, als das aufrufen eines web-service .

aber was ist mit Anmeldeinformationen auf FB?
Leider, FB-Datenbank funktioniert nicht in China.
nicht sinnvoll ist, können Angreifer sehen Sie die Feuerstellung details aus der dekompilierte code und erhalten Sie alle Daten von Ihrem datababse
Ich denke, das ist die beste Lösung als FB-Apps verwendet SHA1-Zugriff auf server. Dekompilieren, der code wird nicht helfen, machen Aufruf von FB, weil hacker das neue app nutzen sollten genaue app-Stempel Zugriff auf FB. Auch, gespeicherten Schlüssel verschlüsselt werden, bevor die Speicherung in der Feuerstellung DB und entschlüsselt nach dem Empfang zu vermeiden, Mitte Mann abfangen.
Wenn man das Geheimnis aus der FB-Datenbank über das Netzwerk, wie geht das sicherer als immer das gleiche Geheimnis von einer anderen web-service über eine sichere (https) channel? Können Sie das erklären?

InformationsquelleAutor Manohar Reddy
2

Basierend auf bitteren Erfahrungen und nach Rücksprache mit einem IDA-Pro-expert die beste Lösung ist, sich zu bewegen ein wichtiger Teil des Codes in eine DLL/SharedObject, dann Holen Sie es von einem server, und laden Sie zur Laufzeit.

Sensible Daten müssen verschlüsselt werden, da es sehr einfach ist, so etwas zu tun:
```
$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD
```
InformationsquelleAutor RonTLV
2

Hinzufügen @Manohar Reddy Lösung, FB-Datenbank oder FB RemoteConfig (mit Null default-Wert) verwendet werden können:
1. Cipher Ihre Schlüssel
2. Speichern Sie es in der FB-Datenbank
3. Bekommen es während der App-Start oder bei Bedarf
4. Schlüssel entschlüsseln und verwenden Sie es
Was ist anders in dieser Lösung?
- keine credintials für FB
- FB-Zugang ist geschützt, so dass nur app mit signiertem Zertifikat haben
  Privileg API-Aufrufe
- die Verschlüsselung/Entschlüsselung zu verhindern, dass Mitte der Mensch abfangen. Allerdings
  fordert schon https auf FB
InformationsquelleAutor Ayman Al-Absi

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Befolgen Sie diese 3 einfachen Schritten zu sichern API/Geheimen Schlüssel

Update :