Modo meno precario per crittografare un campo nel database in modo che possa essere ancora incluso nelle query

Question

Modo meno precario per crittografare un campo nel database in modo che possa essere ancora incluso nelle query

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

3

Ho una tabella in cui tutte le colonne devono essere crittografate (a parte il PK). Ciò sarà realizzato utilizzando AES a livello di applicazione. Tuttavia c'è un campo particolare che deve rimanere ricercabile.

Ad esempio una tabella dei messaggi ha:

MessageTitle (crittografato)
MessageBody (crittografato)
SenderID (crittografato ma abbinabile)

Dato un SimpleSender SenderID dovrei essere in grado di selezionare tutti i messaggi correlati.

Alcuni vincoli / decisioni:

Ho bisogno di crittografare i dati a riposo, inclusa questa colonna. Non ho scelta.
Il SenderID è di un formato fisso, quindi se ho cancellato il valore non sarebbe difficile forzare la forza
Ho scelto di crittografare campi specifici piuttosto che l'intero database (TDE) per mitigare le minacce diverse dai soli furti di dischi.

Attualmente la mia soluzione preferita è crittografare il SenderID (e solo il SenderID) con un IV fisso. In questo modo i dati rimangono crittografati, ma possiamo ancora abbinarli nelle query.

Uno svantaggio di questo approccio è che potrebbero verificarsi attacchi di testo in chiaro sui dati; Gli amministratori di database possono creare record con diversi SenderID e provare a trovare un record corrispondente. Tuttavia ritengo che questo possa essere mitigato dal servizio di crittografia con controllo e monitoraggio degli accessi adeguati.

Questa sembra una soluzione valida?

sql-server encryption databases

posta Dan Rowlands 16.07.2013 - 14:03

fonte

2 risposte

1

Se si tratta di un hash, è possibile calcolare l'hash e cercare utilizzando quel valore poiché la stessa frase produrrà lo stesso valore di hash. Potresti non dover necessariamente salare questo hash dal momento che presumo che il SenderID sia unico ma la salatura non è mai una cattiva idea. Inoltre, perché solo un ID mittente e la password? Se hai bisogno di rendere il corpo del messaggio ricercabile, devi recuperare il contenuto crittografato, decrittarlo e cercare una corrispondenza.

Ad esempio la parola bob calcolerà sempre a 9f9d51bc70ef21ca5c14f307980a29d8 usando md5 quindi se il senderID sembra essere bob l'utente inserirà bob. Il tuo codice cancellerà quella stringa e otterrà 9f9d51bc70ef21ca5c14f307980a29d8 quindi seleziona * dall'e-mail dove senderid = '9f9d51bc70ef21ca5c14f307980a29d8'

risposta data 16.07.2013 - 14:37

fonte

Leggi altre domande sui tag sql-server encryption databases

Ho eseguito un virus su un PC. Quali dovrebbero essere i prossimi passi? Come proteggere i dati MySQL dalle modifiche?

score 2 · Accepted Answer

Dato ciò che ci hai detto, utilizzerei comunque una funzione di hash: questo è esattamente ciò per cui sono stati progettati.

Purtroppo non puoi salare il tuo valore di hash, dato che vuoi essere in grado di trovare un record specifico basato solo sul valore in chiaro, ma puoi comunque usare un HMAC algorythm per la protezione dagli attacchi diretti: un utente malintenzionato dovrà avere accesso alla chiave utilizzata nel calcolo HMAC per ricavare un hash da un dato testo chiaro: supponendo che si stia memorizzando le tue chiavi correttamente (probabilmente il problema più critico in una tale applicazione), il tuo SenderID rimarrà nascosto ma sarai in grado di trovarlo in qualsiasi momento con una semplice ricerca.

L'uso di un HMAC ti aiuterà anche se il tuo SenderID ha bassa entropia (sebbene non risolva completamente tale problema).

Tieni presente che chiunque abbia (o possa ottenere) l'accesso alla chiave utilizzata nel calcolo HMAC sarà in grado di provare a far corrispondere il testo in chiaro con i tuoi dati, ma è qualcosa che non può essere aiutato, credo.

Tieni presente, tuttavia, che, mentre puoi (e dovresti) avere una chiave diversa su ogni installazione, NON sarai in grado di cambiare quella chiave dopo o perderai la capacità di trovare i tuoi record. Un modo per aggirare questo è aggiungere una versione encrpyed del SenderID all'interno del tuo record: devi ridigitare tutto, puoi usarlo per ricalcolare un nuovo hash.

Tuttavia, ti suggerisco di utilizzare una funzione hash strong e moderna per il tuo HMAC. ( SHA-3 , ad esempio, anche se le specifiche finali non sono ancora state pubblicate)