Posso interrogare su dati crittografati con righe nel mio database?

Question

Posso interrogare su dati crittografati con righe nel mio database?

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

3

Per favore fammi sapere se una delle mie supposizioni non è corretta.

Supponiamo di avere un database, in cui tutte le righe di una colonna del database sono crittografate a livello di applicazione utilizzando una passphrase singola, "SECRET", utilizzando la derivazione della chiave basata sulla password:

SiailsalecasualecheIVassicuranochelacrittografiadeglistessidatiperduerighediverseprodurràvaloricrittografatidiversi.Tuttavia,seunutentemalintenzionatohaaccessoinletturaalmiodatabaseedèingradodiforzarelacrittografiadiunasingolariga,conosconolamiapassphrase"SECRET" e possono decodificare tutte le righe crittografate.

Questo significa che il vantaggio principale nell'usare un salt random e IV per ogni riga è che nasconde la frequenza dei valori dei miei dati crittografati? Ad esempio, l'inconveniente di non usare un sale e una IV casuali sarebbe che un utente malintenzionato potrebbe guardare il mio database e vedere "50 righe hanno valore X, 49 righe hanno valore Y, e 1 riga ha valore Z", ma non saprebbero cosa X, Y e Z sono effettivamente a meno che non possano anche decifrare la crittografia? Ci sono più motivi per utilizzare un sale / IV random per riga?

Dire che avevo bisogno di interrogare il mio database per i valori che sono criptati. L'uso di un salt casuale e IV rende impossibile la query "Dammi le righe che hanno un valore N"? In che modo posso proteggere i miei dati con la crittografia ed essere ancora in grado di eseguire query su di essi e quali tipi di minacce comuni sarei quindi vulnerabile a?

encryption salt databases

posta Steven 19.05.2017 - 20:02

fonte

2 risposte

Leggi altre domande sui tag encryption salt databases

Certificato SSL - Rinnovo vs. Richiesta nuova Il ransomware che minaccia con la pubblicazione e le eliminazioni verificabili sono possibili?

score 2 · Answer 1

Prima di tutto, non è solo la frequenza che stai proteggendo. Se l'utente malintenzionato ha crackato il valore X nel tuo esempio, ora conosce tutte le 50 righe. Supponiamo che le righe siano utenti e che il valore crittografato sia una password. Ora l'attaccante ha appena fatto scattare tutti e 50 gli utenti contemporaneamente. È più prezioso che conoscere 50 voci uguali.

Sale casuale e IV per riga non rendono la tua query impossibile, di per sé, ma lo rendono davvero difficile senza fare molte altre rotazioni. Cerca il termine "crittografia omomorfica" che offre una serie di modi per eseguire alcune ricerche sui dati crittografati. In pratica, questo non è veramente scalabile, o fatto in produzione, ma non è impossibile.

link

"Quanta sicurezza" sacrificare per la funzionalità, è davvero una domanda alla quale solo tu puoi rispondere. Qual è il tuo modello di minaccia? Qual è il valore dei dati protetti? La sicurezza deve essere al servizio dei tuoi obiettivi di business, non fine a se stessa. Ha un costo che deve essere inferiore al valore che porta. Se l'attaccante ottiene il controllo della tua funzione di ricerca, ottiene tutti i tuoi dati in qualsiasi modo.

In pratica, se i tuoi dati possono essere conservati in memoria, la soluzione migliore potrebbe essere decifrare i dati, cercare in memoria sul testo normale e lasciare i dati crittografati su disco. Se non ci riesci, potresti dover perdere informazioni parziali interrompendo i dati memorizzati in subchunks di dimensioni ricercabili.

Non vuoi rinunciare alla natura mascherante dello stesso testo in chiaro che crittografa i diversi testi cifrari se le tue informazioni protette sono qualcosa come password o numeri di carte di credito. Tutto ciò che un utente malintenzionato può eseguire su una crittografia diretta può essere utilizzato per un attacco in testo normale noto.

Esempio: Baddie (con accesso in lettura al tuo database - ma non il segreto) registra il tuo servizio come utente legittimo e fornisce "password" come password. Quindi apre il database, trova il proprio record e ora conosce tutti gli altri utenti che hanno scelto anche "password". Molto male.

score 1 · Answer 2

Sì, lo scopo principale dell'utilizzo di una soluzione IV / sale è garantire che lo stesso input per una funzione di crittografia / hash non produca lo stesso risultato. Se non si utilizza un IV / sale casuale, lo stesso valore crittografato / hash verrà visualizzato nello stesso modo nel database.

Non è impossibile interrogare i dati crittografati, solo molto, molto lentamente. Se è necessario utilizzare il campo crittografato in una where, join o una clausola order by, sarà necessario utilizzare una funzione per leggere IV / salt e quindi decrittografare il valore riga per riga.