Mantenere privati i dati degli utenti in un ambiente cloud come Google App Engine

Question

Mantenere privati i dati degli utenti in un ambiente cloud come Google App Engine

#1 da (3 voti)
#2 da (1 voti)

7

Sto scrivendo un'applicazione Java open source per Google App Engine (GAE). L'applicazione consentirà agli utenti di creare contenuti destinati a essere privati. Voglio fornire ragionevoli garanzie che nessuno (incluso me, come amministratore del sito) sarà in grado di leggere contenuti privati che appartengono a qualcun altro. Qual è il modo migliore per farlo?

Il sito verrà pubblicato utilizzando https. Gli utenti accederanno alla mia applicazione usando OpenId, quindi non ho il controllo delle loro credenziali di accesso (non ho la loro password).

Sulla base delle ricerche che ho svolto fino ad ora, penso che una soluzione potrebbe essere quella di crittografare i dati scritti sul datastore GAE usando una chiave di crittografia basata su password. L'utente sceglierebbe una password separata da utilizzare solo per crittografare i propri dati privati. Per generare la chiave di crittografia, avrei hash la password in qualche modo (forse bcrypt?). I dati scritti sul datastore GAE verranno quindi crittografati utilizzando la chiave di crittografia più un salt, e il sale verrà memorizzato insieme al blob crittografato. Non memorizzarei mai la password o la chiave di crittografia in modo permanente, ma probabilmente dovrei conservare la chiave di crittografia nella sessione mentre l'utente ha effettuato l'accesso.

Questa è una buona soluzione? Ci sono altre soluzioni che dovrei considerare invece?

Gradirei anche qualsiasi suggerimento su applicazioni open source esistenti che facciano questo genere di cose correttamente.

Modifica (20 dic 2011):

Cercherò di chiarire che cosa sto cercando.

Google App Engine supporta due ruoli: utenti e amministratori. In questo caso, un utente è chiunque scelga di accedere al sito tramite OpenId. Un amministratore è un tipo speciale di utente che ottiene anche l'accesso alla console di amministrazione dell'applicazione. Tra le altre cose, gli amministratori possono visualizzare i registri e manipolare direttamente il datastore di back-end (lettura e scrittura). Alcuni amministratori, chiamiamoli amministratore / sviluppatori, hanno anche la possibilità di distribuire un nuovo codice.

Ci si può aspettare che gli utenti creino contenuti sia pubblici che privati. Voglio che gli utenti si sentano sicuri che i contenuti che contrassegnano come "privati" non possono essere visualizzati da nessun altro.

Riconosco che un amministratore / sviluppatore malintenzionato potrebbe caricare il codice con una backdoor per eludere il design della privacy. Tuttavia, quel problema dovrà essere risolto tramite auditing. Poiché il codice è open source, gli utenti preoccupati per l'implementazione del software hanno l'opportunità di rivedere il codice e convincersi della sua integrità.

Riconosco anche che gran parte di questo è semplicemente una buona progettazione dell'applicazione. Ad esempio, il back-end dovrebbe richiedere l'autenticazione e non consentire agli utenti autenticati di visualizzare i dati che non possiedono. Ci dovrebbe essere anche una copertura di prova sufficiente a confermare che questa funzionalità funzioni come previsto. Questa parte del design dell'applicazione è già in atto.

Quando ho posto questa domanda, speravo di trovare una soluzione che offrisse un livello più alto di sicurezza. Sto cercando un design che protegga, per quanto pratico, da utenti malintenzionati, amministratori malintenzionati e bug software non intenzionali nei sistemi che controllo. Se allo stesso tempo questa soluzione offre anche una certa protezione contro i fornitori di sistemi dannosi o incompetenti (ad esempio, il personale di Google guarda cose che non dovrebbero, o bug di App Engine che rivelano inavvertitamente i miei dati), allora è ancora meglio.

Mi rendo conto che non posso proteggere contro ogni vettore di attacco in un'applicazione come questa, e certe soluzioni saranno troppo brutte - o troppo fastidiose dal punto di vista dell'utente - per essere pratiche. Non ci può essere una soluzione che sia "migliore" di quella che ho già implementato. In tal caso, vorrei documentare il ragionamento alla base di tale conclusione. Tuttavia, se esiste una soluzione ragionevole, mi piacerebbe trovarla.

cryptography password-management hash appsec databases

posta Ken Pronovici 19.12.2011 - 20:37

fonte

2 risposte

Leggi altre domande sui tag cryptography password-management hash appsec databases

Registri di prevenzione delle intrusioni Presentazione su Web App Security (capitolo degli studenti ACM)

score 3 · Answer 1

Non puoi. Non c'è praticamente alcun meccanismo tecnico che ti impedisca di leggere il contenuto dell'utente, se lo desideri e sei malevolo.

Qui, esaminiamo alcuni ovvi tentativi e capiamo perché non funzionano realmente:

Potresti crittografare i dati dell'utente sotto una chiave che è hardcode nel tuo programma, e archiviarli nel database in forma crittografata, per impedirti di dare una sbirciata ai dati dell'utente. Ma poi il tuo codice avrà la chiave di decodifica, così potrai sempre dare un'occhiata alla chiave di decrittazione e avrai la possibilità di vedere i dati dell'utente. Non funziona.

(Anche se il programma genera la chiave per te non funziona, perché dove verrà memorizzata la chiave per l'uso futuro? Ovunque possa memorizzare la chiave, puoi leggere.)
È possibile chiedere all'utente di fornire una passphrase, derivare una chiave di crittografia dalla passphrase dell'utente, crittografare i dati dell'utente utilizzando questa chiave e quindi memorizzarla nel database in forma crittografata. Ma poi il tuo codice vede la chiave di decodifica. È possibile modificare il codice per raccogliere e registrare le password degli utenti, che consentirebbero quindi di leggere i dati degli utenti. Gli utenti non avrebbero modo di scoprirlo. Non funziona.
È possibile inviare il codice Javascript al browser dell'utente. Il codice Javascript potrebbe richiedere all'utente una passphrase, derivare una chiave di crittografia dalla passphrase dell'utente e crittografare i dati (tutti gli eseguibili sul browser, in modo che la passphrase dell'utente non lasci mai il browser). Il Javascript potrebbe quindi inviare i dati dell'utente, in forma crittografata, al tuo server per memorizzarlo. Sembra attraente. Tuttavia, c'è un problema serio con esso. Se sei malintenzionato o snoopy, puoi facilmente modificare il codice del tuo server per inviare nuovi Javascript agli utenti, che raccolgono le loro password e ne inviano una copia al tuo server. Questo ti permetterebbe di leggere i dati degli utenti. Mentre potresti dire "Accidenti, non lo farei mai", il punto è che gli utenti non avrebbero modo di scoprirlo, quindi non hanno modo di verificare se sei onesto o meno, e non c'è alcun meccanismo tecnico che ti impedisca dall'essere disonesto Non funziona.

Quindi, come puoi vedere, non esiste una soluzione tecnica a questo problema che ti impedisca realmente di leggere i dati dell'utente. Se davvero volessi leggere i dati degli utenti, potresti, e potresti persino farlo in un modo che gli utenti non noterebbero. Quali garanzie hanno gli utenti che non lo farai? Beh, devono fidarsi di te per essere un tipo onesto. I meccanismi tecnici non possono risolvere il problema.

Ora, c'è ancora un buon motivo per crittografare. Se sei onesto e vuoi proteggere i tuoi utenti non da una versione disonesta di te, ma piuttosto da errori involontari potresti creare o possibili violazioni della sicurezza del contenuto del database del server, beh, ora, questo è un problema che può essere meno parzialmente risolto utilizzando la crittografia.

Tuttavia, il problema specifico che hai citato non è uno che può essere veramente risolto con la sola crittografia, in pratica.

score 1 · Answer 2

Se vuoi che gli utenti si sentano fiduciosi, allora si tratta di aggiungere alcune immagini di lucchetti nell'interfaccia. Questa è psicologia , non sicurezza . Prendiamo ad esempio le banche del XIX secolo, che hanno sempre costruito i loro uffici in un'architettura neoclassica, con grandi colonne di pietra e pavimenti in marmo: questo era così che i clienti, inconsciamente, avrebbero collegato mentalmente la banca con nozioni di solidità e longevità - un nozione cruciale negli Stati Uniti prima della creazione della FDIC nel 1933.

Se vuoi convincere le terze parti tecnicamente esperte che non interferisci con i cosiddetti "dati utente privati", beh ... sei per lo più sfortunato. L'aggiunta di crittografia e hash non aiuterà; essendo il sysadmin / sviluppatore, hai ancora il controllo e puoi fare tecnicamente tutto quello che vuoi. Accumulare strati di crittografia ingiustificata ti farà sembrare un po 'incompetente in materia di sicurezza (almeno agli occhi dei professionisti della sicurezza IT), il che a sua volta ridurrà la sicurezza , non la aumenterà.

Il meglio che possiamo fare adesso per evitare bug e buchi e backdoor è fare un sacco di auditing . È necessario ispezionare il codice sorgente del server. Modifica le procedure scritte per ogni azione amministrativa da eseguire sui server e assicurati che vengano seguite; vale a dire, assumere un revisore esterno che sarà fisicamente testimone di tutte le operazioni. Applica il doppio controllo (ad es. La password dell'amministratore è lunga e le persone ne conoscono solo la metà, quindi occorrono due operatori per digitare la password). Richiede il nulla osta di sicurezza (compresa la situazione del debito) per tutti gli sviluppatori e gli amministratori di sistema. Esiste un framework per questo chiamato Webtrust . Due avvertenze importanti:

Sarà costoso, lungo, incredibilmente complesso e distruggerà per sempre la tua anima.
Non va bene. È solo il meglio che abbiamo.