È "Perché dovresti evitare AES in MySQL?" vero?

Question

È "Perché dovresti evitare AES in MySQL?" vero?

#1 da (17 voti)
#2 da (5 voti)
#3 da (4 voti)
#4 da (4 voti)

23

Da articolo della rivista Smashing 2012 una dichiarazione abbastanza audace per evitare AES in MySQL. O come dicono "Perché dovresti evitare AES in MySQL?". Tuttavia, se cerchi la crittografia SQL, spesso trovi il AES_ENCRYPT da (My) SQL menzionato. Non sto dicendo che molti risultati di ricerca indicano che la dichiarazione non è vera, ma mi ha solo fatto pensare: le tre ragioni citate qui sotto sono effettivamente vere?

Che cosa pensano qui gli esperti di sicurezza riguardo alle ragioni per cui "PHP Mcrypt è superiore alle funzioni AES di MySQL":

MySQL needs a database link between the application and database in order for encryption and decryption to occur. This could lead to unnecessary scalability issues and fatal errors if the database has internal failures, thus rendering your application unusable.

Non riesco a capire questo problema; se si cripta / decodifica in php, è necessario anche memorizzare i valori nel database con un collegamento al database? Se la decifrazione fallisce dal lato php, questo porta anche a problemi applicativi? Qual è il punto fatto qui?

PHP can do the same MySQL decryption and encryption with some effort but without a database connection, which improves the application’s speed and efficiency.

Php può farlo "con un po 'di sforzo" e migliora la velocità dell'applicazione? Poiché stai crittografando prima di essere inviato via cavo, l'applicazione (che gestirà la crittografia) ottiene maggiore velocità ed efficienza? Come potrebbe essere vero? Secondo me, si tratta dello "strumento migliore per il lavoro", quindi l'argomento secondo cui "php è anche capace" non significa di per sé che sia lo strumento migliore . È solo uno strumento a , senza l'argomento perché è lo strumento migliore.

MySQL often logs transactions, so if the database’s server has been compromised, then the log file would produce both the encryption key and the original value.

Questo è un punto valido se si crittografano i valori nel database e si attiva la registrazione. Almeno dovresti disattivare il log generale delle query come binary log registra solo le transazioni ma non seleziona le istruzioni. Se non hai bisogno di logging, puoi semplicemente rendere la dichiarazione "se usi AES in MySQL, disattiva tutto il logging". Mi sembra più valido di "se vuoi usare AES in MySQL, fallo in php".

Qualcuno può spiegarmi perché i suddetti punti potrebbero essere validi e perché, in generale, è meglio crittografare i dati nella tua applicazione (php) piuttosto che in (My) SQL.

mysql encryption web-application aes databases

posta Jurian Sluiman 21.11.2013 - 11:30

fonte

4 risposte

Leggi altre domande sui tag mysql encryption web-application aes databases

Il problema di Cohen È possibile utilizzare ECC senza violare i brevetti?

score 17 · Answer 1

Il motivo principale per non utilizzare le funzioni AES_ * in MySQL è perché stanno utilizzando la modalità di blocco del blocco ECB, che non è sicura.

Ulteriori informazioni su:

link

Modifica: Dal momento che MySQL 5.6.17 le cose sono cambiate e MySQL supporta la modalità blocco CBC, ma deve essere abilitato manualmente. Leggi link

score 5 · Answer 2

Per quanto riguarda le prestazioni, suggerisco di lasciare che MySQL esegua la crittografia AES non è un grosso problema. Probabilmente sprecherà (in media) molto più tempo nel recupero / scrittura dei dati piuttosto che nella crittografia. Questo a meno che tutto il tuo database non faccia mai la crittografia e la decifrazione.

Tuttavia c'è un grosso problema nel permettere a MySQL di fare l'AES: hai bisogno della tua applicazione PHP per pubblicare una query su MySQL dove la chiave di crittografia è passata come testo in chiaro. Per proteggere devi usare una connessione sicura, altrimenti un comando tcpdump è facilmente in grado di intercettare la tua discussione su PHP-MySQL.

Se la tua app PHP crittografa i dati internamente, beh questa è una minore esposizione dei tuoi dati e un componente in meno che si occupa di dati non crittografati o chiavi visualizzabili.

score 4 · Answer 3

(Non sono d'accordo che si tratti di un duplicato di È preferibile eseguire la crittografia utilizzando le funzioni o il codice del database? sebbene vi siano molte sovrapposizioni)

L'unica giustificazione a cui posso pensare per il post - ed è importante e valida - è che è facile scalare il livello dell'applicazione (PHP) ma è difficile scalare un livello di database relazionale (MySQL). Per il primo basta aggiungere più server - ma quest'ultimo ha bisogno di caselle più grandi / clustering coordinato. Quindi fare la crittografia in PHP riduce il carico sul DBMS.

Inoltre, per quanto riguarda "MySQL ha bisogno di un collegamento al database ...", l'invio dei dati altrove per l'elaborazione introduce la latenza. Calcolare il valore crittografato o decrittografato di alcuni dati potrebbe essere un compito arduo, ma è improbabile che richieda quasi il tempo necessario per l'invio di materiale su una rete.

Ma la domanda principale è come questo si inserisce nel modello di sicurezza - ed è qui che entra in gioco la questione dei log e della gestione delle chiavi.

score 4 · Answer 4

Come da documentazione di MySQL sulle funzioni di crittografia, link

Caution

Passwords or other sensitive values supplied as arguments to encryption functions are sent in plaintext to the MySQL server unless an SSL connection is used. Also, such values will appear in any MySQL logs to which they are written. To avoid these types of exposure, applications can encrypt sensitive values on the client side before sending them to the server. The same considerations apply to encryption keys. To avoid exposing these, applications can use stored procedures to encrypt and decrypt values on the server side.

Per evitare ciò, suggeriscono la crittografia sul lato client.