Memorizza i token API in modo sicuro su Android per identificare lo sviluppatore

Naviga le tue risposte
1

Stiamo creando una libreria Android per le nostre API Rest che gli sviluppatori di app accederanno con un token univoco. Dato che si tratta di un servizio a pagamento, e si tratta di un modello di prezzo per richiesta o per installazione, come salvaguardiamo gli sviluppatori a pagamento dall'abuso, diciamo se qualcuno, a parte lo sviluppatore, riceve il token da:

  • Decompilazione dell'app
  • Esecuzione di un attacco Man in the Middle (anche se è HTTPS) e ottiene il token

In questo momento stiamo facendo in modo che ogni sviluppatore ospiti il suo endpoint separato (URL del server) che è codificato nella libreria quando glielo diamo. Questo proxy inverso end-point alla nostra API, e in questo modo, siamo in grado di limitare le richieste di IP e anche di differenziare il traffico. Tuttavia, in realtà non risolve la parte di abuso del problema, ed è anche troppo doloroso se vogliamo scalare fino a un milione di app.

Che cosa possiamo fare?

    
posta kouton 25.11.2015 - 09:20
fonte

3 risposte

1

Lo sviluppatore (il tuo cliente) può utilizzare qualsiasi tecnica di offuscamento per proteggere la chiave, ma non vi è alcuna garanzia al 100% dal reverse engineering.

Uno dei vettori di attacco sarebbe un MITM. Se la tua app è installata su un dispositivo rooted, tutte le protezioni https possono essere ignorate.

Lo sviluppatore dell'app ha al suo servizio mezzi di sicurezza molto più forti. Ad esempio, lei può sapere se l'app è stata installata correttamente (potrebbe essere pagata) e così via. Google fornisce servizio di gestione licenze delle app per questi casi. Potrebbe anche provare a escludere i dispositivi rooted (le misure e le contromisure per rivelare il root nascosto sono un corsa agli armamenti continua).

Per proteggere meglio il tuo token, lo sviluppatore dell'app può solo consegnarlo all'app dopo aver verificato tutto ciò.

Ma per aiutare ancora di più, puoi utilizzare una doppia verifica delle tue chiamate API. Assicurati che tale richiesta sia accompagnata da una chiamata dal server registrato dello sviluppatore (puoi richiedere tale controllo una volta per sessione, o una volta per dispositivo, o usando qualche altra politica su cui sei d'accordo).

    
risposta data 28.11.2015 - 17:19
fonte
2

Hai preso in considerazione un processo in due fasi, in cui

  1. Uno sviluppatore si autentica sul tuo server, che risponderà con il token
  2. Il token viene quindi utilizzato per tutte le sessioni successive e scade dopo un certo tempo a tua scelta

Tutto quanto sopra è fatto nell'app. Il token di sessione viene archiviato normalmente ma, data la sua breve durata, è meno importante di informazioni.

Questo ti permette di:

  • revoca l'accesso di qualcuno ad es. se non hanno pagato per il servizio
  • Tieni traccia dell'uso
  • Permetti a uno sviluppatore di "disconnettersi da altre sessioni" in modo simile a ciò che Gmail fa
  • Lascia che uno sviluppatore abbia più di un token
risposta data 25.11.2015 - 09:55
fonte
0

Personalmente, creerei una modalità sviluppatore (come faccio in tutti i miei lavori recenti) Che, quando contrassegnato come on, darebbe un controllo extra.

Creerei i token manualmente per gli sviluppatori, ma se questi sono stati contrassegnati come dev nel database e la modalità dev era attiva richiederebbe una password per utilizzare il token creando effettivamente due sessioni di accesso ...

o semplicemente ritaglia il livello aggiuntivo e usa la modalità sviluppatore ...

un'altra possibilità sarebbe quella di bloccare i token su indirizzi IP? se c'è un attacco MitM buono per loro ... non farà nulla. potresti dare a tutti il token sviluppatore ma solo gli sviluppatori sarebbero in grado di usarlo

    
risposta data 25.11.2015 - 10:27
fonte

Leggi altre domande sui tag

In che modo AES-GCM gestisce blocchi di grandi dimensioni con una chiave a 128 bit? Dovrei usare il peer block per proteggere al meglio il mio computer?