2012-04-15 17 views
80

Ho intenzione di usare oAuth per recuperare mail e contatti da google. Non desidero chiedere all'utente l'accesso ogni volta per ottenere un token di accesso e segreti. Da quello che ho capito, ho bisogno di memorizzarli con la mia applicazione in un database o SharedPreferences. Ma sono un po 'preoccupato per gli aspetti di sicurezza con questo. Ho letto che puoi crittografare e decrittografare i token, ma è facile per un utente malintenzionato decompilare l'apk e le classi e ottenere la chiave di crittografia.
Qual è il metodo migliore per archiviare in modo sicuro questi token in Android?Come archiviare in modo sicuro token di accesso e segreti in Android?

+1

Come si memorizzano la chiave del cliente e il segreto (la loro applicazione non è protetta)? ho bisogno che richiedano l'accesstoken e il segreto .. come fanno le altre app esistenti usando oauth? hmm finalmente con oauth, devi occuparmi di molti altri problemi di sicurezza per me .... ho bisogno di tenere il token/segreto del consumatore in modo sicuro e anche l'accesstoken e il segreto .... finalmente non sarebbe più semplice basta memorizzare il nome utente/password criptati? ... alla fine, non è il secondo migliore? Non riesco ancora a vedere come è meglio oauth ... – yeahman

+0

puoi dirmi ... quale file memorizza il token di accesso ?? Sono nuovo di Android e ho provato a eseguire l'applicazione di esempio Plus. Ma non lo trovo da nessuna parte [metodo GoogleAuthUtil.getToken().] –

risposta

87

Memorizzarli come preferenze condivise. Questi sono di default privati ​​e altre app non possono accedervi. Sui dispositivi rooted, se l'utente consente esplicitamente l'accesso ad alcune app che stanno cercando di leggerle, l'app potrebbe essere in grado di usarle, ma non è possibile proteggerle. Per quanto riguarda la crittografia, è necessario richiedere all'utente di immettere la passphrase di decrittografia ogni volta (annullando quindi lo scopo delle credenziali di memorizzazione nella cache) o di salvare la chiave in un file e si ottiene lo stesso problema.

Ci sono alcuni vantaggi di memorizzare i token al posto della password nome utente reale:

    applicazioni
  • di terze parti non hanno bisogno di conoscere la password e l'utente può essere sicuri che mandano solo con l'originale sito (Facebook, Twitter, Gmail, ecc.)
  • Anche se qualcuno ruba un token, non viene visualizzata la password (che l'utente potrebbe utilizzare anche su altri siti)
  • I token generalmente hanno una durata e scadono dopo un certo tempo
  • I token possono essere revocati se si sospetta che siano stati compromessi
+1

thx per la risposta!ma come posso sapere se la mia chiave utente è stata compromessa? lol è difficile dirlo .. ok su come archiviare il token di accesso e il segreto, ok li li ho salvati in sharedpreferences e li ho crittografati ma per quanto riguarda la chiave del consumatore e il segreto? Non posso memorizzarli in sharedpreferences (avrei bisogno di scrivere esplicitamente la chiave del consumatore e il segreto nel codice per salvarlo in sharedpreference in primo luogo) .. non so se capisci cosa intendo. – yeahman

+2

Devi inserire l'app in un modo (in qualche modo) offuscato, in modo che non siano immediatamente visibili dopo la decompilazione o utilizzare la tua webapp proxy di autenticazione che ha la chiave e il segreto. Inserirli nell'app è ovviamente più semplice e, se pensi che il rischio di qualcuno che cerca di rompere la tua app sia sufficientemente basso, segui questo approccio. A proposito, i punti sopra sono per la password dell'utente. Se scopri che la tua chiave/segreto del consumatore è stata compromessa, puoi revocarla anche tu (ovviamente, però, rompere la tua app). –

+0

ok thx .. andrò con il modo di offuscamento (puoi consigliare qualche buon strumento per farlo?) ... avere una webapp proxy non è molto allettante in quanto dovrei costringere i miei utenti a registrarsi al mio sito .. non molto user-friendly aggiungendo un ulteriore passaggio all'intera catena ... – yeahman

10

È possibile memorizzarli in AccountManager. È considerata la miglior pratica secondo questi ragazzi.

enter image description here

Ecco la definizione ufficiale:

Questa classe fornisce l'accesso a un registro centralizzato di conti online degli utenti. L'utente inserisce le credenziali (nome utente e password) una volta per account, garantendo alle applicazioni l'accesso alle risorse online con l'approvazione "one-click".

Per la guida dettagliata su come utilizzare AccountManager:

Tuttavia, alla fine AccountManager memorizza solo il token come testo normale . Quindi, ti suggerisco di crittografare il tuo segreto prima di memorizzarlo in AccountManager. È possibile utilizzare varie libreria di crittografia come AESCrypt o AESCrypto

Un'altra opzione è quella di utilizzare Conceal library. È abbastanza sicuro per Facebook e molto più facile da usare rispetto a AccountManager. Ecco uno snippet di codice per salvare un file segreto usando Conceal.

byte[] cipherText = crypto.encrypt(plainText); 
byte[] plainText = crypto.decrypt(cipherText); 

Spero che sia d'aiuto.

+2

Un buon consiglio per nascondere. Sembra molto facile da usare. E per molti casi d'uso. – lagos

1

Bene, è possibile proteggere il token di accesso impostando due opzioni.

  1. Utilizzare Salva il token di accesso nel keystore Android che non sarebbe invertire.
  2. funzione
  3. Usa NDK con qualche calcolo che salvare il token e NDK con codice C++ che è molto difficile da invertire
3
  1. Dal riquadro Progetto di Android Studio, selezionare "file di progetto" e creare un nuovo file chiamato "keystore.properties" nella directory principale del progetto.

enter image description here

    file
  1. Aprire "keystore.properties" e salvare il token di accesso e segreto nel file.

enter image description here

  1. Ora caricare il letto il token di accesso e segreto nella vostra app build.gradle di file del modulo. Quindi devi definire la variabile BuildConfig per il tuo token di accesso e Secret in modo da poterti accedere direttamente dal tuo codice. Il tuo build.gradle può apparire come segue:

    ... ... ... 
    
    android { 
        compileSdkVersion 26 
    
        // Load values from keystore.properties file 
        def keystorePropertiesFile = rootProject.file("keystore.properties") 
        def keystoreProperties = new Properties() 
        keystoreProperties.load(new FileInputStream(keystorePropertiesFile)) 
    
        defaultConfig { 
         applicationId "com.yourdomain.appname" 
         minSdkVersion 16 
         targetSdkVersion 26 
         versionCode 1 
         versionName "1.0" 
         testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" 
    
         // Create BuildConfig variables 
         buildConfigField "String", "ACCESS_TOKEN", keystoreProperties["ACCESS_TOKEN"] 
         buildConfigField "String", "SECRET", keystoreProperties["SECRET"] 
        } 
    } 
    
  2. È possibile utilizzare il token di accesso e segreto nel codice come questo:

    String accessToken = BuildConfig.ACCESS_TOKEN; 
    String secret = BuildConfig.SECRET; 
    

In questo modo non è necessario archivia il token di accesso e il segreto in testo normale all'interno del tuo progetto. Quindi, anche se qualcuno decompila il tuo APK, non otterrà mai il tuo token di accesso e il segreto mentre li stai caricando da un file esterno.

+0

Sembra che non ci sia differenza che la creazione di un file di proprietà invece di hard coding. – Dzshean

+0

Un buon modo alternativo. –

1

SharedPreferences is not un luogo sicuro. Su un dispositivo rooted abbiamo easily in grado di leggere e modificare tutti gli xml di SharedPrefereces di tutte le applicazioni. Anche se un token scade ogni ora, i token più recenti possono ancora essere rubati da SharedPreferences. Android KeyStore deve essere utilizzato per la memorizzazione a lungo termine e il recupero delle chiavi crittografiche che verranno utilizzate per crittografare i nostri token per archiviarli, ad es. SharedPreferences. Le chiavi non vengono memorizzate all'interno del processo di un'applicazione, pertanto vengono compromesse are harder.

Problemi correlati