Mysql - crittografia bidirezionale di dati sensibili (indirizzi e-mail) al di fuori di Apache, PHP e MySQL

5

Archiviamo gli indirizzi email degli utenti nel nostro database, come molti altri siti web. Mentre siamo orgogliosi delle misure di sicurezza in vigore, a volte "appena sufficiente" non è sufficiente.

Abbiamo iniziato a cercare una soluzione che ci consenta di archiviare gli indirizzi e-mail in un formato crittografato e recuperarli in un formato leggibile, ma - ed ecco il trucco - al di fuori della fonte del nostro codice PHP. Cioè, se qualcuno dovesse mai violare i nostri server e recuperare il nostro codice sorgente, le nostre password del database e tutto ciò che riguarda la nostra business intelligence, vorremmo che avesse ancora dati assolutamente inutili senza l'algoritmo di crittografia.

Quale sarebbe il modo migliore per farlo e ci sono soluzioni già pronte? Stavamo pensando qualcosa sulla falsariga di un modulo php o apache, o anche di un piccolo programma Go - qualsiasi cosa compilata che potesse essere eseguita molto velocemente e sarebbe inutilizzabile se rubata a causa della sua natura compilata.

Ciò che vogliamo è qualcosa del genere:

Le e-mail nel database verrebbero archiviate in questo formato

gibbweswwvsknvknsdva
sadjfoaisjdoiasjdoiasj
skdjfajsfoiajsdoij
whatever

Quindi, quando abbiamo fatto questo:

$email = $db -> getEmailById(30);
$email = decrypt($email);

la funzione di decriptazione verrebbe applicata alla decrittazione effettiva, ma all'esterno di php. Potrebbe chiamare il comando di sistema ed eseguire un file binario, qualunque sia. Ma qualunque sia il decrpyt restituito è la vera e-mail utilizzabile allora.

Questa e-mail decrittografata può quindi essere utilizzata come destinatario di un messaggio di posta elettronica inviato dal sistema, o come informazioni di contatto visualizzate sul profilo di un utente, ecc., ma se l'utente annulla il DB in qualche modo, tutto ciò che vede è il sopraindicato.

Modifica: tdammers ha chiesto perché questo deve essere esterno a PHP, ma richiamabile da PHP. Perché usiamo i valori effettivi degli indirizzi e-mail un paio di migliaia di volte al minuto, diversi per quello. Quindi la nostra app Web richiede sempre un accesso rapido ai valori leggibili, ma dobbiamo essere sicuri che qualcuno debba prendere il codice sorgente in qualche modo o il database stesso, non avrà valori utilizzabili. Può trattarsi di chiunque, da un hacker, a una parte del codice che viene esposta a causa di un bug critico o di un insoddisfatto dipendente 5 minuti dopo essere stato licenziato, non lasciando a noi il tempo di revocare il suo accesso.

    
posta Swader 08.12.2011 - 09:29
fonte

6 risposte

7

"Ciphers are hard. Cryptography is hard. Ciphers are the easy part."

--Bruce Schneier

Venire con il proprio algoritmo di preparazione a casa per crittografare la posta elettronica è letteralmente l'errore peggiore che si possa fare nella crittografia. Non sono iperbolico, è in effetti l'errore peggiore. L'intero punto della crittografia moderna è che gli algoritmi sono pubblici in modo che possano essere sottoposti a peer review. Vorrei mai prendere in considerazione l'utilizzo di un algoritmo privato per qualsiasi motivo. La chiave è ciò che è segreto e questo fa funzionare il sistema.

Nel tuo caso. Il database può essere compromesso e i messaggi possono rimanere sicuri se ogni client utilizza la propria coppia di chiavi asimmetriche. L'infrastruttura di posta elettronica passa semplicemente il testo cifrato senza alcun mezzo per decifrarlo. Ecco come funziona Enigmail . In realtà consiglio vivamente di usare Enigmail, perché reinventare la ruota?

    
risposta data 06.12.2011 - 19:59
fonte
4

Ci sono due aspetti da tenere a mente: da una parte si crittografa i dati in modo che siano protetti "su disco" e dall'altra si deve garantire l'accesso a questi dati.

DB come Oracle (nell'edizione Enterprise) hanno alcuni add-on per fornire una crittografia trasparente dei dati. In effetti, i dati vengono crittografati su disco in modo che un utente malintenzionato che accede ai file DB non abbia testo in chiaro.

Penso che ci sia almeno una soluzione simile per MySQL: link

Safenet ha un prodotto ProtectDB / DataSecure che esegue questa crittografia trasparente (e alcune funzionalità aggiuntive, vedi sotto) come dispositivo esterno. Funziona con un paio di versioni DB: link

Il prossimo passo è controllare l'accesso a questi dati. È possibile limitare l'accesso agli account utente, IP, ma se un utente malintenzionato è in grado di controllare la propria applicazione, può leggere i propri dati. È inoltre possibile imporre limiti di query in modo che l'applicazione non possa leggere più di X record all'ora. Inoltre, dovresti utilizzare la registrazione e forse l'avviso sui valori di soglia della query.

Un'alternativa alla crittografia trasparente era implementare un tipo di servizio web che è il tuo archivio dati sicuro personale. Solo questa applicazione deve poter gestire la crittografia. Un'applicazione che richiede un messaggio di posta elettronica deve interrogare il servizio per poter accedere a un'e-mail in chiaro. È necessario inserire tale servizio su una macchina separata.

    
risposta data 08.12.2011 - 13:02
fonte
4

Prima di tutto, assolutamente, assolutamente, non cerca di inventare il tuo algoritmo. Non ottieni nulla e perdi tutto. Gli algoritmi sono facili da decodificare, anche in formato binario. E costruendo la tua crittografia, introduci la reale probabilità che il tuo sistema possa essere incrinato senza alcuna conoscenza interna, perché la tua crittografia era così terribile.

In secondo luogo, mettere i tuoi segreti in forma binaria anziché in forma di script è come annotare la tua password all'indietro in modo che l'aggressore non sia in grado di leggerlo. Se l'aggressore è affatto determinato ( e chiaramente lo è se si dà la briga di andare così lontano), allora non hai fatto altro che scomodarlo un po '. In realtà, questo tipo di lavoro di estrazione è il "mondo ciao" del mondo contro la sicurezza.

Infine, ciò che stai chiedendo è fondamentalmente problematico. Vuoi un sistema in grado di decifrare automaticamente il tuo contenuto crittografato, ma vuoi essere costruito in modo tale che se qualcuno conosce tutto quello che sa il sistema, allora non sarà in grado di fare lo stesso. Non è un'aspettativa del tutto ragionevole.

Ma la situazione non è neanche disperata; la sicurezza è un compromesso contro la convenienza e puoi quasi sempre ottenere maggiore sicurezza eliminando una certa quantità di comodità e autonomia.

La migliore sicurezza che si ottiene è dove tutti i parametri crittografici sono memorizzati in un file protetto da password che non viene mai decodificato su disco. Invece, ogni volta che si avvia il sistema, si digita manualmente una password che viene utilizzata per estrarre i parametri operativi del database direttamente nella memoria di lavoro. Solo tu hai questa password, solo tu puoi avviare o riavviare i server e nessun dipendente deve mai avere accesso a tali informazioni sensibili. In questo modo, se l'intero sistema viene rubato o copiato da una tecnologia scontenta, non sarà in grado di farlo estrai il tuo estratto i tuoi segreti o avvia il tuo sistema.  Inoltre, sei sempre l'unico a rispondere al cercapersone alle 3 del mattino. (scusate, convenienza)

In alternativa, puoi collegare la crittografia a un token hardware . Quindi il proprietario del token possiede i dati. Di nuovo, nessun rischio di copiare, ma anche se qualcuno ruba quel dispositivo, hanno rubato il tuo database.

    
risposta data 12.12.2011 - 07:33
fonte
2

Potrebbe TrueCrypt o un approccio simile essere una soluzione? Individua il database MySQL su un volume crittografato, che non richiede altre modifiche (salva le azioni per montare il volume crittografato all'avvio / smontalo dopo che il daemon MySQL si arresta).

Se l'intruso accede a un server funzionante, scambiando dati con, ad esempio, un'applicazione Web, potrebbero comunque essere in grado di intercettare i dati sensibili, come vedo io. Tuttavia, se il server viene spento e rubato, TrueCrypt sarà sufficientemente protetto, se è stata scelta una passphrase sufficientemente buona.

    
risposta data 08.12.2011 - 12:48
fonte
2

C'è una soluzione molto semplice al tuo problema:

  • Cripta gli indirizzi email usando un algoritmo standard ben controllato. (Quindi, stai memorizzando gli indirizzi e-mail crittografati nel database.)

  • Archivia la chiave di decodifica in un file sul tuo server. (Non nel codice sorgente PHP. Il codice sorgente PHP può aprire questo file, leggerlo, memorizzare la chiave di decodifica in memoria e usarlo da lì.)

In questo modo, uno sviluppatore o un hacker che decolla con una copia del codice sorgente non può decrittografare gli indirizzi email. Inoltre, la chiave di decrittografia non verrà memorizzata nel codice sorgente o nel repository di controllo del codice sorgente.

Ovviamente, un hacker che irrompe nel tuo server e ruba il contenuto del database e il contenuto del file contenente la chiave di decodifica può ancora decrittografare gli indirizzi email. Ma questo è inevitabile. Nel modello di minaccia in cui l'utente malintenzionato può rubare l'intero contenuto del database e ha pieno accesso al sistema che esegue l'applicazione Web, si viene colpiti. Se l'applicazione web è in grado di decifrare, allora anche l'hacker può farlo. Non c'è nulla che tu possa fare al riguardo; è solo un dato di fatto.

    
risposta data 11.12.2011 - 03:02
fonte
1

So di essere in ritardo di tre anni per la festa, ma mi piace sottolineare qualcosa che mi è sfuggito nelle risposte per chi trova questo in Google.

La maggior parte delle "perdite" dai siti Web compromessi sono il risultato di SQL Injection e molto meno da un server root-root in cui l'hacker ha pieno accesso ai file di database non elaborati. SQL injection è una tecnica di attacco in cui l'hacker può manipolare le query eseguite dal database e avere il normale codice del sito web renderizzare le pagine.

Quest'ultima parte è cruciale: il tuo codice PHP renderà le pagine come al solito. Ciò significa che il codice di decrittazione dell'indirizzo email verrà eseguito normalmente e aiuterà l'hacker a decrittografare le informazioni. Tutto ciò che l'hacker deve fare è manipolare quale record viene mostrato (ad es. WHERE id = 123 -)

Se l'hacker ha pieno accesso ai tuoi file, probabilmente ha anche accesso al codice PHP e alla chiave in memoria.

    
risposta data 27.03.2014 - 21:38
fonte

Leggi altre domande sui tag