2011-08-19 15 views
43

La mia app Android contiene OAuth secret per l'API di Twitter. Al momento è nel file .properties in formato testo, quindi non ci vuole sforzo per qualcuno per cercarlo in APK.Devo nascondere il segreto utente OAuth memorizzato dall'app Android?

Devo fare qualche passo per oscurarlo (come, rot13 o memorizzato in codice Java offuscato)? O dovrei davvero evitare di fare qualcosa di simile, poiché creerebbe un falso senso di sicurezza?

In che modo le persone solitamente distribuiscono/archiviano il segreto OAuth nelle app Android? Com'è comune che il segreto venga rubato e abusato?

+0

Ho la stessa strategia con la mia app per iOS e NodeJS + ExpressJS + PassportJS nel back-end. Io uso Twitter reverse auth per autenticare gli utenti da iOS. Ma per proteggere questo e impedire agli utenti di annusare i pacchetti HTTP nel mezzo per scoprire cosa c'è nelle intestazioni, sto pensando di usare HTTPS sui miei server per crittografare i dati. Controlla questo per evitare l'incorporamento delle chiavi dei segreti nella tua app: https: //dev.twitter.it/docs/ios/using-reverse-auth – Maziyar

+0

Nota: Reverse Auth è solo per iOS –

risposta

40

la vera domanda è che cosa fa un attaccante ottiene di rubarla ...

Si dovrebbe fare del vostro meglio per proteggere i segreti, ma alla fine, un hacker altamente motivato può sempre arrivare a lui in un app installata. Quindi è il valore del segreto contro la difficoltà di estrazione.

Il valore del segreto del client sta impersonando l'applicazione. Non dà alcun accesso ai dati dell'utente. Tuttavia, poiché Twitter supporta l'emissione automatica di credenziali per le app approvate in precedenza (il loro accesso con il flusso di Twitter), un utente malintenzionato può potenzialmente creare un'app Web con i dati segreti e rubare gli utenti utilizzando un reindirizzamento cieco.

Il problema con l'implementazione di Twitter è che non chiedono allo sviluppatore la natura dell'applicazione. Se lo facessero, non ti avrebbero dato un segreto per cominciare e bloccheranno chiunque costruisca un'applicazione web usando le credenziali del tuo cliente e rubando i dati dagli utenti che l'hanno già approvato.

L'offuscamento è un'opzione, ma debole. Spostare il segreto su un server Web che funge da proxy API è un altro, ma questo sposta semplicemente il problema altrove perché ora la tua app deve autenticarsi contro il server proxy. Tuttavia, questo modello può essere ragionevolmente sicuro se si richiede agli utenti di accedere al proprio sito (che può utilizzare, tramite le viste Web, Twitter per accedere). In questo modo, chiunque cerchi di abusare del tuo proxy avrà bisogno che i suoi utenti aprano account sul tuo servizio, il che non è molto allettante.

In breve, andare avanti e offuscare. Non fa male. Prendi in considerazione l'utilizzo anche del modello proxy. E forse far sapere a Twitter che le loro politiche di sicurezza non sono "grandiose".

+0

Grazie per la risposta. L'app a cui sto lavorando non sarà un'app social di alto profilo, il tweeting da esso è una funzionalità secondaria. Quindi penso che andrò con qualche offuscamento, ma salterò la complessità aggiuntiva del pattern proxy. –

+0

È bello vedere i miei punti rinforzati da qualcuno che sa. Mentre il proxy fa spostare il problema altrove, un potenziale hacker deve scrivere un programma specifico per abusare del proprio proxy. In realtà, raccoglieranno semplicemente i segreti dei consumatori da altre app: c'è [oltre un milione di app di terze parti] (http://techcrunch.com/2011/08/19/twitter-releases-bootstrap-a-set-of- tools-to-build-web-apps-using-css /? utm_source = feedburner & utm_medium = feed & utm_campaign = Feed% 3A + Techcrunch +% 28TechCrunch% 29) là fuori, dopo tutto. –

+1

C'è un URL CallBack nelle App di Twitter, sarà sufficiente a impedire agli hacker di creare app Web che rubano dati? Deve essere il dominio che hai impostato nelle impostazioni dell'app altrimenti non autorizzerà tutto ciò che invii. – Maziyar

-3

Il punto principale di 0Auth è che non si memorizzano preziose informazioni sensibili sul dispositivo - quindi è giusto memorizzare il segreto sul dispositivo (molto meglio che le credenziali dell'utente reale). Nel caso in cui i segreti del dispositivo venissero rubati, l'utente può sempre invalidare l'accesso senza necessità di cambiare le sue credenziali

+0

Sì, ma se qualcuno trova il segreto dell'utente della tua app può fingere di essere la tua app. Puoi cambiare la chiave e il segreto ma tutte le tue installazioni sul campo non possono più twittare. – funkybro

+0

Non c'è modo di nascondere qualcosa all'interno della tua app da una determinata persona (anche OS 360 è stato decodificato e rattoppato in codice macchina in russia). E anche se qualcuno finge di essere la tua app, l'utente dovrà comunque autenticarsi contro il servizio, quindi non c'è nessun vero compromesso. –

+2

Penso che questa risposta abbia confuso i segreti dei consumatori con token oauth. –

4

Definirei sicuramente this analysis da uno degli autori OAuth, Eran Hammer-Lahav, che cita un altro article dissecting Twitter's OAuth secret problems.

Il mio consiglio sarebbe quello di offuscare la chiave in modo che non possa essere estratta banalmente e si dovrebbe essere al riparo da emittenti e spammer.

L'opinione di Hammer-Lahav è che i segreti di OAuth non devono essere revocati e devono essere utilizzati solo per la raccolta di statistiche. Spero che Twitter segua questo consiglio.

+2

L'articolo dice "non usare i segreti dei clienti nelle applicazioni installate" e il tuo consiglio è di fare il contrario ... –

+0

@Graham Ottimo punto - avrei dovuto essere un po 'più chiaro. Se l'OP sta pianificando di procedere allora l'offuscamento * è * imporante. In caso contrario, suppongo che sia necessaria un'implementazione in cui il segreto è memorizzato su un server remoto e un servizio Web funge da proxy per le chiamate OAuth. Non so quali sono le migliori pratiche per questo approccio. –

Problemi correlati