Query di database crittografata

StackOverflow https://stackoverflow.com/questions/181130

Domanda

Ho appena scoperto Stack Overflow e sto solo verificando se ci sono idee per un vincolo che sto avendo con alcuni amici in un progetto, anche se questa è più una domanda teorica a cui sono stato cercando di trovare una risposta per qualche tempo.

Non sono molto interessato alla crittografia, ma se non sono abbastanza chiaro cercherò di modificare / commentare per chiarire eventuali domande.

Cercando di essere breve, l'ambiente è qualcosa del genere:

  • Un'applicazione in cui il front-end come accesso per crittografare / decrittografare le chiavi e il back-end viene utilizzato solo per l'archiviazione e le query.

  • Avere un database a cui non è possibile accedere per un paio di campi, ad esempio diciamo " address " che è text / varchar come al solito.

  • Non hai accesso alla chiave per decrittografare le informazioni e tutte le informazioni arrivano al database già crittografate.

Il problema principale è qualcosa del genere, come fare costantemente query sul database, è impossibile fare cose come " dove indirizzi come '% F§YU / ´ ~ # JKSks23%' " ;. (SE c'è qualcuno che ha una risposta per questo sentiti libero di sparare).

Ma va bene fare dove address = '±! NNsj3 ~ ^ º-:' ? O avrebbe anche completamente rovinato il database?

Un altro limite che potrebbe essere applicato è che il front-end non ha molta potenza di elaborazione disponibile, quindi già le informazioni di crittografia / decrittografia iniziano a spingerle al limite. (Detto questo solo per evitare risposte come " Esportare un join di tabelle sul front-end e interrogarlo lì " ;.)

Qualcuno potrebbe indicarmi una direzione per continuare a pensarci?

Bene, grazie per le risposte così veloci alle 4 del mattino, per la prima volta mi sento davvero colpito da questa community. (O forse sono solo per il diverso fuso orario)

Fornendo solo alcune informazioni:

Il problema principale riguarda la corrispondenza parziale. Come requisito obbligatorio nella maggior parte dei database è consentire corrispondenze parziali. Il vincolo principale è in realtà il proprietario del database non è autorizzato a cercare informazioni nel database . Negli ultimi 10 minuti ho trovato una possibile soluzione che si estende nuovamente ai possibili problemi del database, a cui aggiungerò qui:

Possibile soluzione per consentire la corrispondenza semi parziale:

  • La password + un paio di campi pubblici dell'utente sono in realtà la chiave per la crittografia. Per l'autenticazione l'idea è di crittografare un valore statico e confrontarlo all'interno del database.
  • Creazione di un nuovo set di tabelle in cui le informazioni sono memorizzate in modo analizzato, il che significa qualcosa come: "4th Street" diventerebbe 2 righe crittografate (una per "4" e un'altra per "Street"). Ciò consentirebbe già una corrispondenza semi-parziale in quanto una ricerca potrebbe già essere eseguita su tabelle separate.

Nuova domanda:

  • Probabilmente questo divorerebbe di nuovo il server di database o qualcuno pensa che sia una soluzione praticabile per il problema di corrispondenza parziale?

Post Scriptum: non ho accettato la risposta di Cade Roux solo per consentire ulteriori discussioni e specialmente una possibile risposta alla nuova domanda.

È stato utile?

Soluzione

Puoi farlo come descrivi - interrogando efficacemente l'hash, diciamo, ma non ci sono molti sistemi con quel requisito, perché a quel punto i requisiti di sicurezza interferiscono con altri requisiti affinché il sistema sia utilizzabile - cioè nessun parziale corrisponde, poiché la crittografia lo esclude. È lo stesso problema con la compressione. Anni fa, in un ambiente molto piccolo, ho dovuto comprimere i dati prima di metterli nel formato dei dati. Naturalmente, non è stato possibile cercare facilmente quei campi.

In un'applicazione più tipica, in definitiva, le chiavi saranno disponibili per qualcuno nella catena, probabilmente il web server.

Per il traffico dell'utente finale SSL protegge quella pipe. Alcuni switch di rete possono proteggerlo tra il server Web e il database e la memorizzazione di dati crittografati nel database va bene, ma non eseguirai query su dati crittografati del genere.

E una volta che i dati sono visualizzati, sono là fuori sulla macchina, quindi qualsiasi dispositivo di elaborazione per scopi generali può essere aggirato a quel punto e hai difese perimetrali al di fuori della tua applicazione che entrano davvero in gioco.

Altri suggerimenti

perché non crittografare il disco contenente le tabelle del database, crittografare le connessioni al database e lasciare che il database funzioni normalmente?

[Non capisco davvero il contesto / i contrappunti che richiedono questo livello di paranoia]

EDIT: " vincoli di legge " eh? Spero che tu non sia coinvolto in qualcosa di illegale, odierei essere un accessorio involontario ... ;-)

se i - ahem - vincoli legali - impongono questa soluzione, allora è tutto quello che c'è da fare - nessuna corrispondenza LIKE e risposta lenta se i computer client non riescono a gestirla.

Alcuni mesi fa ho riscontrato lo stesso problema: l'intero database (tranne gli indici) è crittografato e il problema relativo alle corrispondenze parziali è stato sollevato.

Ho cercato su Internet alla ricerca di una soluzione, ma sembra che non ci sia molto da fare al riguardo, ma un "rimedio".

La soluzione che ho finalmente adottato è:

  1. Crea una tabella temporanea con i dati del campo rispetto al quale viene eseguita, decrittografata la query e un altro campo che è la chiave primaria della tabella (ovviamente, questo campo non deve essere decifrato così com'è plain-text).

  2. Esegue nuovamente la corrispondenza parziale della tabella temporanea e recupera gli identificatori.

  3. Interroga la tabella reale per quegli identificatori e restituisce il risultato.

  4. Elimina la tabella temporanea.

Sono consapevole che ciò presuppone un sovraccarico non banale, ma non ho trovato un altro modo per eseguire questa attività quando è obbligatorio che il database sia completamente crittografato.

A seconda di ciascun caso particolare, potresti essere in grado di filtrare il numero di righe inserite nella tabella temporanea senza perdere i dati per il risultato (considera solo quelle righe che appartengono all'utente che sta eseguendo la query, ecc. ..).

Si desidera utilizzare l'hash md5. Fondamentalmente, prende la tua stringa e la trasforma in un hash che non può essere riprodotto. È quindi possibile utilizzarlo per convalidare le cose in seguito. Ad esempio: 

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

Quindi, per convalidare un indirizzo in futuro: 

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

Ora è crittografato sul lato del database in modo che nessuno possa scoprirlo, anche se ha cercato nel tuo codice sorgente. Tuttavia, trovare il sale li aiuterà a decifrarlo però.

http://en.wikipedia.org/wiki/MD5

Se è necessario archiviare i dati sensibili di cui si desidera eseguire una query in un secondo momento, si consiglia di archiviarli in testo normale, limitando l'accesso a tali tabelle il più possibile.

Se non puoi farlo e non vuoi un overhead nel front-end, puoi creare un componente nel back-end, in esecuzione su un server, che elabora i dati crittografati.

Effettuare query su dati crittografati? Se stai usando un buon algoritmo di crittografia non riesco a immaginare come farlo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top