Best practice per l'archiviazione e la protezione di chiavi API private nelle applicazioni [chiuso]


373

La maggior parte degli sviluppatori di app integrerà alcune librerie di terze parti nelle loro app. Se si tratta di accedere a un servizio, come Dropbox o YouTube, o per arresti anomali della registrazione. Il numero di librerie e servizi di terze parti è sbalorditivo. La maggior parte di tali librerie e servizi sono integrati in qualche modo autenticandosi con il servizio, il più delle volte ciò avviene tramite una chiave API. Per motivi di sicurezza, i servizi di solito generano una chiave pubblica e privata, spesso definita anche segreta. Sfortunatamente, per connettersi ai servizi, questa chiave privata deve essere utilizzata per l'autenticazione e, quindi, probabilmente far parte dell'applicazione. Inutile dire che questo affronta un immenso problema di sicurezza. Le chiavi API pubbliche e private possono essere estratte dagli APK in pochi minuti e possono essere facilmente automatizzate.

Supponendo di avere qualcosa di simile a questo, come posso proteggere la chiave segreta:

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

}

Qual è secondo te il modo migliore e più sicuro per archiviare la chiave privata? Offuscamento, crittografia, cosa ne pensi?



avevo memorizzato in image / png e ho ottenuto la chiave tramite png come BufferReader
Sumit

Penso che questa sia una preoccupazione valida e che abbia pubblicato un problema simile sulla pagina github dell'SDK Android di Firebase: github.com/firebase/firebase-android-sdk/issues/1583 . Vediamo se questo viene gestito.
Grebulon,

Risposte:


348
  1. Allo stato attuale, l'applicazione compilata contiene le stringhe chiave, ma anche i nomi costanti APP_KEY e APP_SECRET. L'estrazione di chiavi da tale codice autocompensante è banale, ad esempio con lo strumento Android standard dx.

  2. È possibile applicare ProGuard. Rimarrà invariate le stringhe chiave, ma rimuoverà i nomi delle costanti. Rinominerà anche classi e metodi con nomi brevi e insignificanti, ove possibile. L'estrazione delle chiavi richiede un po 'più di tempo, per capire quale stringa serve a quale scopo.

    Si noti che la configurazione di ProGuard non dovrebbe essere così difficile come si teme. Per cominciare, devi solo abilitare ProGuard, come documentato in project.properties. In caso di problemi con le librerie di terze parti, potrebbe essere necessario eliminare alcuni avvisi e / o impedire che vengano offuscati, in proguard-project.txt. Per esempio:

    -dontwarn com.dropbox.**
    -keep class com.dropbox.** { *; }

    Questo è un approccio a forza bruta; puoi perfezionare tale configurazione una volta che l'applicazione elaborata funziona.

  3. Puoi offuscare manualmente le stringhe nel tuo codice, ad esempio con una codifica Base64 o preferibilmente con qualcosa di più complicato; forse anche codice nativo. Un hacker dovrà quindi decodificare staticamente la codifica o intercettare dinamicamente la decodifica nella posizione corretta.

  4. È possibile applicare un offuscatore commerciale, come il fratello specializzato DexGuard di ProGuard . Può inoltre crittografare / offuscare le stringhe e le classi per te. L'estrazione delle chiavi richiede ancora più tempo ed esperienza.

  5. Potrebbe essere possibile eseguire parti dell'applicazione sul proprio server. Se riesci a tenere le chiavi lì, sono al sicuro.

Alla fine, è un compromesso economico che devi fare: quanto sono importanti le chiavi, quanto tempo o software puoi permetterti, quanto sono sofisticati gli hacker che sono interessati alle chiavi, quanto tempo vorranno spendere, quanto vale un ritardo prima che le chiavi vengano hackerate, in che misura gli hacker di successo distribuiranno le chiavi, ecc. Piccole informazioni come le chiavi sono più difficili da proteggere rispetto a intere applicazioni. Intrinsecamente, nulla sul lato client è infrangibile, ma puoi sicuramente alzare il tiro.

(Sono lo sviluppatore di ProGuard e DexGuard)


2
@EricLafortune non fa differenza se la stringa della chiave privata è archiviata nella classe Java rispetto all'XML della risorsa String?
Alan,

1
@EricLafortune È ora possibile utilizzare il sistema Android Keystore per archiviare le chiavi in ​​modo sicuro? ( developer.android.com/training/articles/keystore.html )
David Thomas

1
@DavidThomas: hai provato a usare il keystore. Voglio offuscare una chiave API scritta in classe Java. Per favore, rispondi
Sagar Trehan,

1
Android KeyStore è utile per questo? ( developer.android.com/training/articles/… )
Weishi Zeng,

1
Non capisco # 5. Non ha gli stessi problemi esatti del problema originale?
pete,

80

Poche idee, secondo me solo la prima dà una garanzia:

  1. Conserva i tuoi segreti su alcuni server su Internet e, quando necessario, prendili e usali. Se l'utente sta per utilizzare Dropbox, nulla ti impedisce di effettuare richieste al tuo sito e ottenere la tua chiave segreta.

  2. Inserisci i tuoi segreti nel codice jni, aggiungi un po 'di codice variabile per rendere le tue librerie più grandi e più difficili da decompilare. È inoltre possibile dividere la stringa di chiavi in ​​alcune parti e conservarle in vari punti.

  3. usa obfuscator, metti anche il codice con l'hash hash segreto e in seguito lo sbricioli quando serve.

  4. Inserisci la tua chiave segreta come ultimo pixel di una tua immagine nelle risorse. Quindi, quando necessario, leggilo nel tuo codice. Offuscare il codice dovrebbe aiutare a nascondere il codice che lo leggerà.

Se vuoi dare una rapida occhiata a quanto è facile leggere il tuo codice apk, prendi APKAnalyser:

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


46
se l'utente può decompilare l'app sebbene possa determinare la richiesta che è stata fatta al proprio server ed eseguirla semplicemente per ottenere segreti. Nessun proiettile d'argento qui ma fai qualche passo e scommetto che andrà tutto bene! Se la tua app è super popolare, forse forse no. Grandi idee!
Matt Wolfe,

3
sì, il numero 1 non offre alcuna garanzia.
marcinj,

42
Mi piace molto l'idea di nascondere le chiavi all'interno delle immagini. +1
Igor Čordaš

1
@ MarcinJędrzejewski Vuoi spiegare di più (preferibilmente con codice di esempio o snipped) sulla quarta soluzione? Grazie.
Dr.jacky,

2
@ Mr.Hyde questo si chiama steganografia, è troppo complesso per fornire un codice di esempio qui, puoi trovare esempi su google. Ne ho trovato uno qui: dreamincode.net/forums/topic/27950-steganography . L'idea è fantastica ma dal momento che il codice apk può essere decompilato, ne rovina la bellezza.
marcinj,

32

Un altro approccio è quello di non avere il segreto sul dispositivo in primo luogo! Consulta le tecniche di sicurezza dell'API mobile (in particolare la parte 3).

Usando l'antica tradizione di indiretta, condividere il segreto tra l'endpoint API e un servizio di autenticazione delle app.

Quando il tuo client desidera effettuare una chiamata API , chiede al servizio di autenticazione dell'app di autenticarlo (utilizzando tecniche di attestazione remota avanzate) e riceve un token limitato nel tempo (di solito JWT ) firmato dal segreto.

Il token viene inviato con ogni chiamata API in cui l'endpoint può verificare la propria firma prima di agire sulla richiesta.

Il vero segreto non è mai presente sul dispositivo; infatti, l'app non ha mai idea se sia valida o meno, richiede l'autenticazione e trasmette il token risultante. Come utile vantaggio dell'indirizzamento indiretto, se mai vuoi cambiare il segreto, puoi farlo senza richiedere agli utenti di aggiornare le loro app installate.

Quindi, se vuoi proteggere il tuo segreto, non averlo nella tua app in primo luogo è un buon modo per andare.


5
Questa dovrebbe essere la risposta accettata.
ortonomia,

4
Il problema persiste quando si desidera accedere al servizio di autenticazione. Ti darà un ID cliente e un segreto cliente. Dove dovremmo salvarli?
Ashi,

non risolve le API private in cui è necessario prima eseguire l'autenticazione con l'API per poterle utilizzare. dove ottieni le credenziali per tutti gli utenti dell'app?
Kibotu,

25

Vecchio modo non garantito:

Segui 3 semplici passaggi per proteggere l'API / chiave segreta ( Vecchia risposta )

Possiamo usare Gradle per proteggere la chiave API o la chiave segreta.

1. gradle.properties (Proprietà del progetto): crea una variabile con chiave.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Modulo: app): imposta la variabile in build.gradle per accedervi in ​​attività o frammento. Aggiungi il codice sottostante per buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Accedilo in Attività / Frammento tramite BuildConfig dell'app:

BuildConfig.GoogleSecAPIKEY

Aggiornare :

La soluzione sopra è utile nel progetto open source per eseguire il commit su Git. (Grazie a David Rawson e riyaz-ali per il tuo commento).

Secondo i commenti di Matthew e Pablo Cegarra, il modo sopra descritto non è sicuro e Decompiler consentirà a qualcuno di visualizzare BuildConfig con le nostre chiavi segrete.

Soluzione:

Possiamo usare NDK per proteggere le chiavi API. Siamo in grado di memorizzare le chiavi nella classe C / C ++ nativa e accedervi nelle nostre classi Java.

Segui questo blog per proteggere le chiavi API utilizzando NDK.

Un follow-up su come archiviare i token in modo sicuro su Android


4
la memorizzazione di una chiave nel file gradle è sicura?
Google,

4
@Google gradle.propertiesnon dovrebbe essere registrato su Git, quindi questo è un modo per mantenere il segreto fuori dal codice sorgente impegnato, almeno
David Rawson

4
Ciò non impedisce che la chiave API venga raggruppata nel risultante apk(verrà aggiunta al BuildConfigfile generato ), sebbene sia sicuramente una buona idea gestire diverse chiavi API (ad esempio in un progetto open source)
riyaz-ali

5
L'uso di un decompilatore Java consentirà a qualcuno di visualizzare il file BuildConfig e "GoogleSecAPIKEY"
Matthew

3
Il tuo BuildConfig.javafile avrà la chiave in formato testo normale. Questo non è meglio di ciò che l'OP sta già facendo.
iceman

16

La chiave segreta dell'app deve essere mantenuta privata, ma quando si rilascia l'app possono essere annullati da alcuni ragazzi.

per quei ragazzi non si nasconderà, blocca ProGuardil codice. È un refattore e alcuni offuscatori pagati stanno inserendo alcuni operatori bit a bit per recuperare la jk433g34hg3 stringa. Puoi prolungare di 5-15 minuti l'hacking se lavori 3 giorni :)

Il modo migliore è mantenerlo così com'è, imho.

Anche se si memorizza sul lato server (PC), è possibile hackerare e stampare la chiave. Forse questo richiede più tempo? Comunque è nel giro di pochi minuti o poche ore nel migliore dei casi.

Un utente normale non decompilerà il tuo codice.


1
Bene - non la risposta che speravo di ottenere =) ... Pensavo che tu potesse ottenere una grande sicurezza :(
Basic Coder

scusa non è come volevi una soluzione brillante e ultra sicura, ma per coloro che possono usare il compilatore, il decompilatore non esiste un codice java sicuro: anche il codice nativo può essere visualizzato con hexa viewer e decrittato. Almeno merita una prova ...

1
Proguard non offuscherà la chiave reale però ..? La cosa migliore da fare è una semplice routine di codifica / decript, che nasconderà l'offuscato.
Doomsknight,

3
è "visibile" la routine di decodifica, è facile fare il contrario e hai la stringa originale

14

Una possibile soluzione è codificare i dati nell'app e utilizzare la decodifica in fase di esecuzione (quando si desidera utilizzare tali dati). Consiglio anche di usare progaurd per rendere difficile la lettura e la comprensione del codice sorgente decompilato della tua app. ad esempio ho inserito una chiave codificata nell'app e quindi ho usato un metodo di decodifica nella mia app per decodificare le mie chiavi segrete in fase di esecuzione:

// "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=="));
}

Il codice sorgente decompilato di un'app proguarded è questo:

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

Almeno è abbastanza complicato per me. questo è il modo in cui lo faccio quando non ho altra scelta che memorizzare un valore nella mia applicazione. Ovviamente sappiamo tutti che non è il modo migliore ma funziona per me.

/**
 * @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";
}

Versione decompilata:

 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";
      }
    }
  }

e puoi trovare tante classi di criptatori con una piccola ricerca su google.


13

Aggiunta alla soluzione @Manohar Reddy, Firebase Database o Firebase RemoteConfig (con valore predefinito Null) può essere utilizzato:

  1. Cifra le tue chiavi
  2. Conservalo nel database firebase
  3. Scaricalo durante l'avvio dell'app o quando necessario
  4. decifrare le chiavi e usarlo

Cosa c'è di diverso in questa soluzione?

  • nessuna credenziale per firebase
  • l'accesso firebase è protetto, pertanto solo le app con certificato firmato hanno il privilegio di effettuare chiamate API
  • cifratura / decifratura per prevenire l'intercettazione da uomo di mezzo. Tuttavia chiama già https su Firebase

con tutto rispetto con questa soluzione siamo ancora il primo quadrato. Invece di utilizzare le credenziali, si consiglia di utilizzare un certificato. Chiunque sia in grado di rubare le tue credenziali è in grado di rubare il tuo certificato firmato.
Ashi,

Un vantaggio però, con la soluzione suggerita, stiamo aggiungendo un'altra complicazione di fronte all'hacker.
Ashi,

11

Questo esempio presenta diversi aspetti. Citerò un paio di punti che non credo siano stati esplicitamente trattati altrove.

Proteggere il segreto in transito

La prima cosa da notare è che l'accesso all'API di Dropbox utilizzando il loro meccanismo di autenticazione dell'app richiede la trasmissione della chiave e del segreto. La connessione è HTTPS, il che significa che non è possibile intercettare il traffico senza conoscere il certificato TLS. Questo per impedire a una persona di intercettare e leggere i pacchetti nel loro viaggio dal dispositivo mobile al server. Per gli utenti normali è un ottimo modo per garantire la privacy del loro traffico.

Ciò a cui non è bravo è impedire a una persona maliziosa di scaricare l'app e ispezionare il traffico. È davvero facile usare un proxy man-in-the-middle per tutto il traffico in entrata e in uscita da un dispositivo mobile. Non richiederebbe il disassemblaggio o il reverse engineering del codice per estrarre la chiave dell'app e segreti in questo caso a causa della natura dell'API Dropbox.

È possibile eseguire il pinning che verifica che il certificato TLS ricevuto dal server sia quello previsto. Ciò aggiunge un controllo al client e rende più difficile intercettare il traffico. Ciò renderebbe più difficile l'ispezione del traffico in volo, ma il controllo degli accessi avviene nel client, quindi sarebbe probabilmente ancora possibile disabilitare il test degli accessi. Rende però più difficile.

Proteggere il segreto a riposo

Come primo passo, l'uso di qualcosa come proguard aiuterà a rendere meno ovvio dove si nascondono segreti. È inoltre possibile utilizzare NDK per archiviare la chiave e il segreto e inviare richieste direttamente, il che ridurrebbe notevolmente il numero di persone con le competenze appropriate per estrarre le informazioni. Ulteriore offuscamento può essere ottenuto non memorizzando i valori direttamente in memoria per un certo periodo di tempo, è possibile crittografarli e decrittografarli appena prima dell'uso come suggerito da un'altra risposta.

Opzioni più avanzate

Se ora sei paranoico nel mettere il segreto ovunque nella tua app e hai tempo e denaro per investire in soluzioni più complete, allora potresti prendere in considerazione la possibilità di archiviare le credenziali sui tuoi server (presumendo che tu ne abbia). Ciò aumenterebbe la latenza di qualsiasi chiamata all'API, poiché dovrà comunicare tramite il server e potrebbe aumentare i costi di esecuzione del servizio a causa della maggiore velocità di trasmissione dei dati.

Devi quindi decidere come comunicare al meglio con i tuoi server per assicurarti che siano protetti. Questo è importante per evitare che tutti gli stessi problemi si ripresentino con l'API interna. La migliore regola empirica che posso dare è quella di non trasmettere alcun segreto direttamente a causa della minaccia man-in-the-middle. Invece puoi firmare il traffico usando il tuo segreto e verificare l'integrità di tutte le richieste che arrivano al tuo server. Un modo standard per farlo è calcolare un HMAC del messaggio digitato su un segreto. Lavoro in un'azienda che ha un prodotto di sicurezza che opera anche in questo campo, motivo per cui questo genere di cose mi interessa. In effetti, ecco a articolo sul blog di uno dei miei colleghi che analizza la maggior parte di questo.

Quanto dovrei fare?

Con qualsiasi consiglio di sicurezza come questo è necessario prendere una decisione in termini di costi / benefici su quanto sia difficile far sì che qualcuno possa entrare. Se sei una banca che protegge milioni di clienti, il tuo budget è totalmente diverso da qualcuno che supporta un'app nella loro tempo libero. È praticamente impossibile impedire a qualcuno di violare la tua sicurezza, ma in pratica poche persone hanno bisogno di tutte le campane e fischietti e con alcune precauzioni di base puoi fare molta strada.


1
Hai appena copiato e incollato questo da qui: hackernoon.com/mobile-api-security-techniques-682a5da4fe10 senza riconoscere la fonte.
ortonomia,

1
@ortonomia Sono d'accordo che avrebbe dovuto citare l'articolo che hai collegato, ma potrebbe averlo dimenticato perché entrambi funzionano nello stesso posto ...
Exadra37,

2
Anche l'articolo di Skip e il post sul blog su cui si basano sono usciti una settimana dopo la mia risposta.
ThePragmatist,

8

La soluzione più sicura è mantenere le chiavi su un server e instradare tutte le richieste che richiedono quella chiave attraverso il server. In questo modo la chiave non lascia mai il tuo server, quindi fintanto che il tuo server è sicuro, lo è anche la tua chiave. Ovviamente c'è un costo prestazionale con questa soluzione.


32
Il problema è - per raggiungere quel server che contiene tutti i segreti dovrei usare un'altra chiave segreta - mi chiedo dove lo terrò? ;) Quello che sto cercando di dire è - Anche questa non è la soluzione migliore (non pensare che ci sia una soluzione ideale qui)
Mercury

Non è vero, il tuo server è completamente sotto il tuo controllo. Ciò che richiede dipende interamente da te.
Bernard Igiri,

5
Puoi spiegare qui come il client può crittografare i dati che desidera inviare al server, mentre le chiavi si trovano sul lato server? e se la tua risposta sarà: il server invia le chiavi al client, quindi anche questo deve essere protetto! quindi di nuovo nessuna soluzione magica! non vedi ?!
Mercurio,

2
@BernardIgiri e poi di nuovo torniamo al punto 1. Supponiamo che il telefono crei un accesso casuale e il server lo accetti e invii un pin (questo è il cosiddetto server privato di cui stiamo parlando). Quindi la persona che disassembla la tua app vede che tutto ciò che serve per accedere al tuo server privato è solo un login casuale che può creare da solo. Dimmi cosa gli impedisce di crearne uno e di accedere al tuo server? In effetti, qual è la differenza tra la tua soluzione e l'archiviazione effettiva di una chiave di accesso o API sul server principale (le cui credenziali volevamo memorizzare nel nostro server privato)
Ken

3
@ken Il numero casuale è autenticato rispetto al numero di telefono e all'accesso fisico ai suoi messaggi di testo. Se qualcuno ti tradisce, hai le loro informazioni. In caso contrario, forzali a creare un account utente completo e una password. Se ciò non è abbastanza, procurati anche una carta di credito. Se non è abbastanza buono, chiamali. Se non è abbastanza, incontrali faccia a faccia. Quanto sicuro / scomodo vuoi essere?
Bernard Igiri,

7

Mantenere il segreto firebase databasee ottenerlo all'avvio dell'app, è molto meglio che chiamare un servizio web.


13
ma per quanto riguarda le credenziali da Firebase?
the_joric

2
Sfortunatamente, il database Firebase non funziona in Cina.
Konjengbam,

9
non ha senso, gli aggressori possono vedere i dettagli della tua base di fuoco dal codice decompilato e ottenere tutti i dati dal tuo database
user924

3
Penso che questa sia la soluzione migliore in quanto le app Firebase utilizzano SHA1 per consentire l'accesso al server. La decompilazione del codice non aiuterà a effettuare chiamate a firebase perché la nuova app hacker dovrebbe usare il timbro esatto dell'app per accedere a firebase. Inoltre, la chiave memorizzata deve essere crittografata prima di essere archiviata nel database Firebase e decifrata una volta ricevuta per evitare l'intercettazione intermedia.
Ayman Al-Absi,

Quando si ottiene il segreto dal database firebase attraverso la rete, in che modo è più sicuro che ottenere lo stesso segreto da un altro servizio Web attraverso un canale sicuro (https)? Puoi spiegare?
Csaba Toth,

6

Qualunque cosa tu faccia per proteggere le tue chiavi segrete non sarà una vera soluzione. Se lo sviluppatore è in grado di decompilare l'applicazione, non c'è modo di proteggere la chiave, nascondere la chiave è solo sicurezza per oscurità e lo stesso vale per l'offuscamento del codice. Il problema con la protezione di una chiave segreta è che per proteggerla è necessario utilizzare un'altra chiave e anche quella chiave deve essere protetta. Pensa a una chiave nascosta in una scatola chiusa con una chiave. Metti una scatola dentro una stanza e chiudi la stanza. Ti resta un'altra chiave per proteggere. E quella chiave sarà ancora codificata all'interno dell'applicazione.

Quindi, a meno che l'utente non inserisca un PIN o una frase, non c'è modo di nascondere la chiave. Ma per farlo dovresti avere uno schema per la gestione dei PIN fuori banda, il che significa attraverso un canale diverso. Certamente non pratico per proteggere le chiavi di servizi come le API di Google.


5

Posta vecchia, ma abbastanza buona. Penso che nasconderlo in una libreria .so sarebbe fantastico, usando NDK e C ++ ovviamente. I file .so possono essere visualizzati in un editor esadecimale, ma buona fortuna decompilando che: P


9
Gli utenti possono facilmente effettuare chiamate di funzione alla libreria condivisa e ottenere tutto ciò che si nasconde lì. Non è necessario decopilarlo.
david72,

5
Secondo androidauthority.com/… al momento non esiste un modo sicuro per farlo in Android.
david72,

1
@AhmedAwad Non capisco perché questo abbia 3 voti positivi. chiunque potrebbe facilmente decompilare l'app e vedere come viene chiamato il punto di ingresso ndk: /
Johny19

1
Questa risposta è quasi una delle migliori opzioni, ma l'autore dovrebbe ricordare che è molto importante includere una chiamata (all'interno della libreria NDK) per vedere se il checksum corrisponde al tuo APK, altrimenti qualcuno può chiamare la libreria NDK al di fuori di la tua app
Stoycho Andreev il

@Sniper sarebbe fantastico, tranne che ha un grosso problema. Come fai a sapere quale file "chiama" il metodo nativo? Se si codifica il nome dell'apk per verificare, ottimo, ma cosa succede se faccio l'apk "hack" nella stessa cartella dell'apk "buono"? Controllerà che l'apk "buono" abbia un buon checksum e mi permetterà di eseguire quel metodo nativo. A meno che non ci sia un modo per conoscere il file del chiamante dal lato JNI / C ++, allora è inutile come le altre opzioni.
SocketByte,

5

L'unico vero modo per mantenerli privati ​​è tenerli sul tuo server e fare in modo che l'app invii qualunque cosa sia al server e il server interagisce con Dropbox. In questo modo non distribuisci MAI la tua chiave privata in nessun formato.


11
Ma come si impedisce al resto del mondo di chiamare il server?
user2966445

Se per "server" si intende il server Web in cui si trovano le credenziali, è possibile utilizzare qualsiasi metodo desiderato. autenticazione semplice con nome utente / password, oauth, active directory, ecc. ecc. Dipende molto dall'applicazione.
Nick,

Forse mi manca qualcosa, ma questo non richiede ancora la memorizzazione delle credenziali all'interno dell'app?
user2966445

3
Giusto, ma hai detto che l'app si autenticherà prima con il server. Questo non significa archiviare un altro set di credenziali nell'app? Comprendo che il server gestirà le effettive chiamate dropbox.
user2966445

4
Bene, potrebbe significare questo, ma è un'autorizzazione completamente separata. Ma non devi. Il caso di cui sto parlando è che l'utente della tua app avrebbe effettuato l'accesso alla tua app, ad esempio utilizzando Facebook o Twitter. Non memorizzi le loro credenziali nella tua app, non le conosci nemmeno. Tale processo di autorizzazione consente loro di accedere al tuo server API, che ha le credenziali per dropbox, ma nessuna app o utente ha accesso direttamente a loro.
Nick,

0

Sulla base dell'esperienza amara e dopo aver consultato un esperto IDA-Pro, la soluzione migliore è spostare una parte chiave del codice in una DLL / SharedObject, quindi recuperarla da un server e caricarla in fase di esecuzione.

I dati sensibili devono essere codificati in quanto è molto facile fare qualcosa del genere:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD

3
E dove stai memorizzando le credenziali per detto server?
ZX9,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.