i * deve * memorizzare credenziali di terze parti nel mio database. miglior modo?

Question

La mia app deve leggere un URL SSL da una terza parte. Come faccio a memorizzare al meglio le credenziali di terze parti nel mio database, che protegge le credenziali di terze parti dall'essere compromessa? Considerare sia la sicurezza assoluta che la praticità. L'hashing unidirezionale delle credenziali non è utile in quanto devo ripristinare le credenziali in testo normale per la chiamata SSL. Sto usando python su Google App Engine e la mia app si autentica con le credenziali di google.

• crittografare le credenziali utilizzando ad es. AES e salvare la chiave di crittografia da qualche altra parte (sposta semplicemente il problema), o derive it from the credentials and keep the algorithm secret (semplicemente sposta il problema)
• credenziali cifrare usando un synchronous stream cipher, ricavare la (non) entropia dalle credenziali e keep the algorithm secret (appena si sposta il problema)
• su un'app web separata dedicata alla memorizzazione di credenziali di terze parti, fornire un URL SSL per ricevere le credenziali di terze parti, questo URL è accessibile con credenziali di google (come la mia app) e può utilizzare authsub o qualcosa per trasferire l'autorizzazione all'altro app web questo sembra più sicuro perché è più difficile hackerare una webapp banalmente semplice, e se la mia complessa app principale viene compromessa le credenziali di terze parti non sono esposte.

cosa ne pensi di tutti gli approcci?

Answer 1

È un compito difficile, e nessun approccio ti salverà il problema per assicurarti che non ci sia un collegamento debole. Per i principianti, non saprei dire se l'hosting su Google è il modo migliore per andare, perché si perderà il controllo (non so davvero se App Engine sia progettato con il livello di sicurezza richiesto in mente, dovresti trovarlo out) e probabilmente non è possibile eseguire test di penetrazione (cosa che si dovrebbe.)

Avere una piccola applicazione separata è probabilmente una buona idea, ma che non ti evita di dover crittografare in un modo o nell'altro le credenziali stesse in questo app più piccola Ti compra semplicemente la semplicità, che a sua volta rende le cose più facili da analizzare.

Personalmente proverei a progettare l'app in modo che la chiave cambi in modo casuale dopo ogni utilizzo, con una sorta di approccio one time pad. Non si specifica l'app in modo sufficientemente dettagliato per vedere se ciò è fattibile.

Answer 2

Se è necessario archiviare in modo reversibile le credenziali, semplicemente non c'è soluzione. Usa AES e mantieni la chiave segreta sotto una guardia armata ben pagata.

Se si utilizza Windows verificherei l'API Cred * Win32 (advapi32.dll), consentirebbe almeno la gestione della chiave di punt a windows syskey dove TPM e o password di avvio possono fornire protezione contro compromessi di basso livello (rubati disk drives)

Ovviamente se l'applicazione o il contesto di sicurezza in cui è in esecuzione è compromessa, nessuna delle precedenti sarebbe di grande aiuto.

Answer 3

Come vengono utilizzate le credenziali? Se il loro utilizzo è attivato solo dal proprietario originale (ad esempio, sta memorizzando un numero di carta di credito e sta effettuando il secondo acquisto), può fornire una password a quel punto che viene utilizzata come chiave di crittografia. Non sarà quindi necessario memorizzare la chiave in locale e il contenuto del database da solo non è utile a un utente malintenzionato.

Answer 4

Un libro decente che copre questo tipo di situazione è Cryptography In The Database.