Memorizzare in modo sicuro token Oauth nel file

Question

Sto sviluppando una piccola webapp in python che interagirà con un account casella personale dell'utente. Qual è il modo migliore per memorizzare i token Oauth per quell'account in un file flat?

L'hashing dei token è abbastanza sicuro? O dovrei crittografarli? Se la crittografia è la strada da percorrere, come suggeriresti di memorizzare la chiave, dal momento che sarebbe necessaria la crittografia a 2 vie per decrittografare i token per l'invio a Dropbox?

È possibile caricare sqlite e archiviare i token, ma mi chiedo se ci sia un buon modo per farlo usando file flat. Lo stesso problema viene eseguito con Sqlite, poiché è anche un file. Naturalmente, le autorizzazioni per i file dovrebbero essere impostate sul privilegio minimo consentito a cui accede l'applicazione web.

Answer 1

L'hashing non funziona, poiché, come menziona skjaidev, è un modo.

Se si ha il ragionevole timore che il proprio file o database venga rubato (*), la crittografia è la strada da percorrere. Ma come dici tu, la tua app avrà bisogno della chiave di decodifica, quindi la domanda è dove memorizzarla. Ovviamente memorizzarlo nello stesso punto dei dati, non aumenta la sicurezza. Considerare quanto segue:

• Quando i dati si trovano in un database, è (molto probabilmente) meno sicuro rispetto a un file flat. Questo perché esistono tecniche di iniezione di database che possono consentire di leggere il database, ma non i file. In questo caso mettere la chiave di decrittografia da qualche parte sul file system (nel tuo codice) ha senso: i dati dal solo database sono in quel caso inutili.
• Anche quando i dati si trovano in un file flat, inserendo la chiave di decrittografia da qualche parte in un file, è possibile ridurre il rischio. Molti sistemi vengono "hackerati" quando l'hacker accede a un sistema che non avrebbe dovuto contenere quei dati, che conteneva vecchi backup dei dati, o in qualche altro modo non (necessariamente) contiene il codice con la decrittografia chiave.

• La cosa migliore è avere la chiave di decodifica non sul filesystem, ma solo nella memoria del computer. Un buon hacker con accesso root o accesso fisico potrebbe ancora arrivare ad esso, ma direi che nel 99% dei casi che gli hacker ottengono l'accesso ai file system, non saranno in grado di leggere la memoria (nel casi in cui rubano i backup, rubano la macchina fisica (disattivandola nel processo), ottengono l'accesso a livello utente, ecc.). Questo è fondamentalmente l'approccio keychain. Il problema è, come ottenere la chiave di decodifica nella memoria, e c'è solo una soluzione che conosco: digitarla (o un'altra password che decrittografa la chiave di decodifica) ogni volta che l'applicazione si avvia. Se questo è accettabile dipende da quanto spesso la tua applicazione si riavvierà.

• C'è un altro metodo. Se hai solo bisogno di accedere a Dropbox quando gli utenti sono effettivamente connessi alla tua app, puoi considerare di crittografare il token con qualche proprietà utente unica (o istanziare la password che l'utente usa per accedere al tuo sito, o qualche stringa casuale che tu impostato in un cookie alla prima visita). In questo caso puoi anche considerare di archiviare l'intero token di accesso crittografato in un cookie (e non sul tuo server).

Qualsiasi metodo tu scelga, non proteggerà mai veramente, come dici tu stesso. Se la tua app può ottenere token decodificati (cosa che può, altrimenti la tua app non avrebbe bisogno di memorizzarli in primo luogo), un hacker con una licenza illimitata e privilegiata. La cosa bella dei token di accesso è, tuttavia, che probabilmente possono essere facilmente revocati, quindi se vengono rubati probabilmente non è la fine del mondo; e un hacker sa che possono essere facilmente revocati, quindi difficilmente saranno interessanti come target.

(*) Nota: è sempre ragionevole presumere che le cose verranno rubate alla fine in un modo o nell'altro. Posso immaginare che se si installa un piccolo sito per 20 amici sul PC di casa, ci si preoccupa meno delle password che vengono rubate, rispetto a quando si costruisce il prossimo instagram. È sempre un compromesso tra sicurezza e quantità di lavoro. Come accennato, avere i token in un file flat invece di un database (se gestito correttamente) dovrebbe rendere meno probabile che vengano rubati.