Segreti OAuth nelle app mobili

Quando si utilizza il protocollo OAuth, è necessaria una stringa segreta ottenuta dal servizio a cui si desidera delegare. Se lo stai facendo in un'app Web, puoi semplicemente archiviare il segreto nella tua base di dati o nel file system, ma qual è il modo migliore per gestirlo in un'app mobile (o in un'app desktop)?

Memorizzare la stringa nell'app non è ovviamente buono, poiché qualcuno potrebbe facilmente trovarla e abusarla.

Un altro approccio potrebbe essere quello di archiviarlo sul server e far sì che l'app lo recuperi ad ogni esecuzione, senza mai memorizzarlo sul telefono. Questo è quasi altrettanto negativo, perché devi includere l'URL nell'app.

L'unica soluzione praticabile che posso trovare è prima ottenere il token di accesso normalmente (preferibilmente utilizzando una vista Web all'interno dell'app), quindi instradare tutte le ulteriori comunicazioni attraverso il nostro server, che aggiungerebbe il segreto ai dati della richiesta e comunicare con il fornitore. Poi di nuovo, sono un sostenitore della sicurezza, quindi mi piacerebbe davvero sentire le opinioni di alcune persone competenti su questo. Non mi sembra che la maggior parte delle app faccia di tutto per garantire la sicurezza (ad esempio, Facebook Connect sembra presumere che tu abbia messo il segreto in una stringa direttamente nella tua app).

Un'altra cosa: non credo che il segreto sia coinvolto nella richiesta iniziale del token di accesso, quindi ciò potrebbe essere fatto senza coinvolgere il nostro server. Ho ragione?

Sì, questo è un problema con il design OAuth che stiamo affrontando. Abbiamo optato per il proxy di tutte le chiamate tramite il nostro server. OAuth non è stato completamente eliminato per quanto riguarda le app desktop. Non esiste una soluzione perfetta al problema che ho riscontrato senza modificare OAuth.

Se ci pensi e fai la domanda sul perché abbiamo segreti, è principalmente per il provisioning e la disabilitazione delle app. Se il nostro segreto è compromesso, il provider può davvero revocare l'intera app. Dal momento che dobbiamo incorporare il nostro segreto nell'app desktop, siamo un po 'fregati.

La soluzione è avere un segreto diverso per ogni app desktop. OAuth non semplifica questo concetto. Un modo è far andare l'utente a creare un segreto da solo e inserire la chiave da solo nella tua app desktop (alcune app di Facebook hanno fatto qualcosa di simile per molto tempo, facendo sì che l'utente andasse e creasse Facebook per impostare i propri quiz personalizzati e una schifezza). Non è una grande esperienza per l'utente.

Sto lavorando alla proposta di un sistema di delega per OAuth. Il concetto è che usando la nostra chiave segreta che otteniamo dal nostro fornitore, potremmo inviare il nostro segreto delegato ai nostri client desktop (uno per ogni app desktop in pratica) e quindi durante il processo di autenticazione inviamo quella chiave al livello superiore provider che ci richiama e riconvalida con noi. In questo modo possiamo revocare i nostri segreti che forniamo a ciascun client desktop. (Prendendo in prestito molto di come funziona da SSL). L'intero sistema sarebbe perfetto per i servizi Web a valore aggiunto e che trasferiscono le chiamate a un servizio Web di terze parti.

Il processo potrebbe anche essere eseguito senza richiamate di verifica della delega se il provider di livello superiore fornisce un'API per generare e revocare nuovi segreti delegati. Facebook sta facendo qualcosa di simile consentendo alle app di Facebook di consentire agli utenti di creare sub-app.

Ci sono alcuni discorsi sul problema online:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

La soluzione di Twitter e Yammer è una soluzione pin di autenticazione: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Con OAUth 2.0, puoi archiviare il segreto sul server. Utilizzare il server per acquisire un token di accesso che si sposta quindi sull'app ed è possibile effettuare chiamate direttamente dall'app alla risorsa.

Con OAuth 1.0 (Twitter), il segreto è necessario per effettuare chiamate API. Il proxy delle chiamate attraverso il server è l'unico modo per garantire che il segreto non sia compromesso.

Entrambi richiedono un meccanismo per cui il componente server sa che è il client che lo chiama. Questo tende a essere fatto durante l'installazione e l'utilizzo di un meccanismo specifico della piattaforma per ottenere un id app di qualche tipo nella chiamata al server.

(Sono l'editor delle specifiche di OAuth 2.0)

Una soluzione potrebbe essere quella di codificare il codice segreto OAuth nel codice, ma non come una semplice stringa. Offuscalo in qualche modo - dividilo in segmenti, sposta i caratteri di un offset, ruotalo - fai una o tutte queste cose. Un cracker può analizzare il tuo codice byte e trovare stringhe, ma il codice di offuscamento potrebbe essere difficile da capire.

Non è una soluzione infallibile, ma economica.

A seconda del valore dell'exploit, alcuni geniali cracker possono fare di tutto per trovare il tuo codice segreto. È necessario valutare i fattori: costo della soluzione lato server precedentemente menzionata, incentivo per i cracker a dedicare maggiori sforzi alla ricerca del codice segreto e alla complessità dell'offuscamento che è possibile implementare.

Non archiviare il segreto all'interno dell'applicazione.

È necessario disporre di un server a cui l'applicazione può accedere tramite https (ovviamente) e su cui è memorizzato il segreto.

Quando qualcuno desidera accedere tramite l'applicazione mobile / desktop, l'applicazione inoltrerà semplicemente la richiesta al server che quindi aggiungerà il segreto e lo invierà al fornitore di servizi. Il tuo server può quindi dire alla tua applicazione se ha avuto successo o no.

Quindi, se hai bisogno di ottenere informazioni sensibili dal servizio (Facebook, Google, Twitter, ecc.), L'applicazione chiede al tuo server e il tuo server le fornirà all'applicazione solo se è correttamente connessa.

Non esiste davvero alcuna opzione se non quella di memorizzarla su un server. Nulla sul lato client è sicuro.

Nota

Detto questo, questo ti proteggerà solo dai client dannosi ma non dai client malvagi e non dai client malvagi (phising) ...

OAuth è un protocollo molto migliore nel browser che su desktop / mobile.

Esiste una nuova estensione per il tipo di concessione del codice di autorizzazione chiamata Proof Key for Code Exchange (PKCE) . Con esso, non è necessario un segreto client.

PKCE (RFC 7636) è una tecnica per proteggere i client pubblici che non utilizzano un segreto client.

Viene utilizzato principalmente da app native e mobili, ma la tecnica può essere applicata anche a qualsiasi client pubblico. Richiede supporto aggiuntivo da parte del server di autorizzazione, quindi è supportato solo su determinati provider.

da https://oauth.net/2/pkce/

Per ulteriori informazioni, è possibile leggere l'intera RFC 7636 o questa breve introduzione .

Ecco qualcosa a cui pensare. Google offre due metodi di OAuth ... per le app Web, in cui si registra il dominio e si genera una chiave univoca, e per le app installate in cui si utilizza la chiave "anonimo".

Forse ho riflettuto su qualcosa nella lettura, ma sembra che condividere la chiave univoca della tua webapp con un'app installata sia probabilmente più sicuro dell'uso di "anonimo" nel metodo ufficiale delle app installate.

Con OAuth 2.0 puoi semplicemente utilizzare il flusso lato client per ottenere un token di accesso e quindi utilizzare questo token di accesso per autenticare tutte le ulteriori richieste. Quindi non hai assolutamente bisogno di un segreto.

Una bella descrizione di come implementare questo può essere trovata qui: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Non ho molta esperienza con OAuth, ma ogni richiesta non richiede non solo il token di accesso dell'utente, ma anche una chiave e un segreto per l'utente dell'applicazione? Quindi, anche se qualcuno ruba un dispositivo mobile e cerca di estrarre i dati da esso, avrebbe bisogno di una chiave dell'applicazione e di un segreto per poter effettivamente fare qualsiasi cosa.

Ho sempre pensato che l'intenzione dietro OAuth fosse tale che ogni Tom, Dick e Harry che avevano un mashup non dovessero archiviare le credenziali di Twitter in chiaro. Penso che risolva abbastanza bene quel problema nonostante i suoi limiti. Inoltre, non è stato davvero progettato pensando all'iPhone.

Sono d'accordo con Felixyz. OAuth, sebbene migliore di Basic Auth, ha ancora molta strada da fare per essere una buona soluzione per le app mobili. Ho giocato con l'utilizzo di OAuth per autenticare un'app per telefono cellulare su un'app di Google App Engine. Il fatto che non sia possibile gestire in modo affidabile il segreto dell'utente sul dispositivo mobile significa che l'impostazione predefinita è utilizzare l'accesso "anonimo".

Il passaggio di autorizzazione del browser dell'implementazione OAuth di Google App Engine ti porta a una pagina in cui contiene testo come: "Il sito <some-site> richiede l'accesso al tuo account Google per i prodotti elencati di seguito"

YourApp (yourapp.appspot.com) - non affiliato a Google

eccetera

Prende <some-site> dal nome dominio / host utilizzato nell'URL di callback che fornisci, che può essere qualsiasi cosa su Android se usi uno schema personalizzato per intercettare il callback. Quindi, se usi l'accesso "anonimo" o il tuo segreto del consumatore è compromesso, allora chiunque potrebbe scrivere a un consumatore che imbroglia l'utente nel dare accesso alla tua app gae.

La pagina di autorizzazione di Google OAuth contiene anche molti avvisi che hanno 3 livelli di gravità a seconda che tu stia utilizzando chiavi "anonime", riservate al consumatore o pubbliche.

Roba abbastanza spaventosa per l'utente medio che non è tecnicamente esperto. Non mi aspetto di avere un'alta percentuale di completamento dell'iscrizione con quel tipo di cose in mezzo.

Questo post sul blog chiarisce come i segreti dei consumatori non funzionano davvero con le app installate. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Sto anche cercando di trovare una soluzione per l'autenticazione OAuth mobile e la memorizzazione di segreti all'interno del bundle dell'applicazione in generale.

E un'idea folle mi ha appena colpito: l'idea più semplice è quella di archiviare il segreto all'interno del binario, ma in qualche modo offuscato o, in altre parole, archiviare un segreto crittografato. Quindi, ciò significa che devi memorizzare una chiave per decrittografare il tuo segreto, che sembra averci portato al punto di partenza. Tuttavia, perché non utilizzare semplicemente una chiave che è già nel sistema operativo, ovvero è definita dal sistema operativo e non dall'applicazione.

Quindi, per chiarire la mia idea è che scegli una stringa definita dal sistema operativo, non importa quale. Quindi crittografa il tuo segreto usando questa stringa come chiave e memorizzalo nella tua app. Quindi durante il runtime, decodifica la variabile usando la chiave, che è solo una costante del sistema operativo. Qualsiasi hacker che sbircia nel tuo binario vedrà una stringa crittografata, ma nessuna chiave.

Funzionerà?

Qui ho la risposta sicura per archiviare le tue informazioni oAuth nell'applicazione mobile

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook non implementa OAuth in senso stretto (ancora), ma ha implementato un modo per non incorporare il tuo segreto nella tua app per iPhone: https://web.archive.org/web/20091223092924/http://wiki. developers.facebook.com/index.php/Session_Proxy

Per quanto riguarda OAuth, sì, più ci penso, siamo un po 'pieni. Forse questo lo risolverà.

Nessuna di queste soluzioni impedisce a un determinato hacker di sniffare i pacchetti inviati dal proprio dispositivo mobile (o emulatore) per visualizzare il segreto del client nelle intestazioni http.

Una soluzione potrebbe essere quella di disporre di un segreto dinamico costituito da un timestamp crittografato con una chiave di crittografia e un algoritmo privati. Il servizio quindi decodifica il segreto e determina se il timestamp è +/- 5 minuti.

In questo modo, anche se il segreto è compromesso, l'hacker sarà in grado di usarlo per un massimo di 5 minuti.

Come altri hanno già detto, non dovrebbe esserci alcun problema reale con l'archiviazione locale del segreto sul dispositivo.

Inoltre, puoi sempre fare affidamento sul modello di sicurezza basato su UNIX di Android: solo la tua applicazione può accedere a ciò che scrivi nel file system. Scrivi semplicemente le informazioni sull'oggetto SharedPreferences predefinito della tua app.

Per ottenere il segreto, si dovrebbe ottenere l'accesso come root al telefono Android.