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.