La crittografia garantisce la riservatezza . La crittografia non garantisce assolutamente la riservatezza, ma traduce il problema nella chiave : quando i dati sono crittografati, saranno leggibili solo dalle entità che hanno accesso alla chiave di decrittografia. La chiave non deve essere memorizzata nello stesso posto dei dati stessi, e questo è il tipo di separazione di cui stiamo parlando qui. Vale a dire, i dati crittografati sono nel database ma la chiave di decrittografia è nell'applicazione , che può essere una macchina distinta, quindi offre protezione contro gli attaccanti che possono dare un'occhiata sul server del database, ma non sul computer dell'applicazione.
Come sottolinea @Lucas, questo funziona contro alcune forme di SQL injection purché la decrittografia non sia fattibile in SQL . Alcuni database hanno capacità di eseguire la crittografia da soli, quindi gli attacchi di SQL injection possono sfruttare queste capacità. Come caso estremo, considera ciò che Microsoft chiama Transparent Data Encryption in SQL Server: tutti i dati sono crittografato, ma questo viene fatto automaticamente dal server del database stesso; l'applicazione non è nemmeno a conoscenza di esso. Questo offre la protezione zero (nil, void, nada) contro le iniezioni SQL e altri hack a livello di applicazione. TDE è solo contro le persone che leggono il supporto di memorizzazione senza passare attraverso il codice SQL Server.
Un utente malintenzionato che dirotta il computer dell'applicazione sarà in grado di leggere l'intero database e decrittografarlo interamente, quindi la crittografia non può proteggerlo. In effetti, ci sono relativamente pochi scenari plausibili in cui la crittografia del database offre in realtà una protezione extra (al contrario dell'hash della password , che è a senso unico, e che offre molta protezione extra come seconda linea di difesa).