Memorizza in modo sicuro le informazioni di autenticazione di terze parti

8

Supponiamo che ci sia un'applicazione web multiutente che richiede l'accesso alla casella di posta dell'utente (su servizi di terze parti, come Gmail, ecc.). Questo accesso deve essere persistente. Il che significa che dovremmo memorizzare la password dell'utente. Il che crea un punto vulnerabilità: se qualcuno ha avuto accesso a tale sistema, potrebbe rubare tonnellate di caselle di posta dell'utente. C'è un modo per ridurre il rischio in tale configurazione? Per esempio. per alcuni siti web OAuth potrebbe ridurre il rischio poiché i token hanno bisogno di chiavi del consumatore, possono essere limitati e possono essere facilmente scaduti in massa se succede qualcosa di brutto. Ma tutto questo non è disponibile per i server di posta. Quindi, qualche suggerimento su un buon modo (se c'è) per memorizzare tali informazioni in modo più sicuro?

    
posta StasM 24.12.2010 - 09:26
fonte

2 risposte

6

L'esperienza dimostra che se un sito come questo si trova sull'Internet pubblica e diventa abbastanza popolare, diventa un grande obiettivo e ha un'alta probabilità di compromessi disastrosi. Si noti bene le risposte in questa ampia discussione (su un obiettivo un po 'diverso):

Se decidi di andare avanti, assicurati di avvertire i tuoi utenti dei rischi reali. La difesa in profondità è obbligatoria: tieni la vera e propria macchina di memorizzazione delle password fuori dal web, accessibile attraverso il firewall con un'interfaccia molto semplice, costruita sulla piattaforma più sicura che puoi trovare, con un sacco di tempra e monitoraggio, un buon ID, ecc. ecc.

    
risposta data 24.12.2010 - 20:42
fonte
2

Come dici tu, questo è un potenziale punto debole. Ma come lo risolvi ha molto a che fare con il modo in cui l'applicazione è implementata. per esempio. se viene eseguito come applicazione java in un contenitore, è possibile scrivere il token nell'heap dell'applicazione dopo l'avvio. Da lì è molto difficile rileggere senza entrare nello spazio di memoria di java. Per esempio, una piattaforma di tipo PHP non è un approccio fattibile, probabilmente la soluzione migliore sarebbe utilizzare una serie di variabili ambientali all'avvio del server web. Ammetto che questa è una proposta più complessa per mantenere le password POP per migliaia di potenziali utenti piuttosto che, ad esempio, una sola password per il database, ma il principio è lo stesso. Per quanto riguarda una piattaforma condivisa .... allora deve davvero andare sul filesystem (vedi anche suphp e open_basedir per php).

Tuttavia la maggior parte di questa complicazione scompare se chiedi all'utente di fornire la password. Proteggere i dati della sessione dallo snooping è più semplice rispetto a un'impostazione di sistema - anche se qui ci sono ancora dei potenziali problemi. Se è necessario autenticare l'utente indipendentemente dalla funzione di terze parti o ci si connette a più parti terze, è possibile utilizzare la password dell'utente come parte di una chiave di crittografia per un database memorizzato dei token utenti.

Ma invece di chiedere come proteggere tale piattaforma, stai chiedendo come ridurre i rischi. Tuttavia, se non controlli il meccanismo di autenticazione di terze parti, non hai la possibilità di utilizzare altro che semplicemente un nome utente / password.

Quindi l'unica altra opzione che possiedi, ossia quella di garantire la sicurezza di dio al front end, è di aumentare i tuoi dati con i vasi di miele - quindi se vedi qualche accesso ai vasi di miele allora sai che tu sei " probabilmente sono stati compromessi.

    
risposta data 24.12.2010 - 10:33
fonte