Non ci sono davvero funzioni MySQL integrate per gestire sofisticate configurazioni di chiavi crittografate. Dovrai implementare la maggior parte della logica di crittografia nel tuo codice PHP e / o lato browser (javascript?).
Ma le tue preoccupazioni dichiarate sono leggermente peculiari: sembra che le tue uniche vere preoccupazioni siano un attacco di SQL injection o brute force (ipotesi di password, presumo) da una workstation desktop / laptop client remota. Questo mi fa sospettare che tu abbia già pianificato altre misure di sicurezza non menzionate e che tu abbia analizzato le possibili strade del compromesso.
Per uno, presumo che tu abbia regole firewall per proteggere l'host MySQL / PHP da qualsiasi tipo di accesso da IP client remoti non approvati. Se ho ragione, ha senso che ti preoccupi solo degli attacchi da workstation degli utenti compromessi.
Inoltre, presumo che tu capisca che se un utente malintenzionato sull'host del client remoto può passare ai privilegi di amministratore / root o compromettere direttamente il proprio account dell'utente reale, i dati di quel cliente hanno una protezione pari a zero indipendentemente dalla crittografia o da qualsiasi altra protezione. (L'utente malintenzionato può leggere le chiavi da qualsiasi posizione siano salvate sul disco o curvarle mentre l'utente reale le immette al momento dell'accesso e le chiavi portano ai dati.)
Partendo da questi due presupposti, ha senso concludere che le uniche due minacce rilevanti sono A) tentativi di iniezione di password a forza bruta e B) tentativi di iniezione di SQL:
- Se l'utente malintenzionato non ottiene la chiave dell'utente reale o se desidera accedere a più dei semplici dati dell'utente reale, può provare i crediti di accesso forzati per l'utente reale o un altro account. (In teoria, è possibile bloccare ciascun account su un IP client remoto specifico, il che contribuirebbe anche a compartimentare i rischi.)
- Se l'aggressore ottiene una chiave valida per l'utente reale, ha una strada oltre la schermata di accesso (che è presumibilmente abbastanza semplice da essere sicuro), fino al morbido ventre del codice dell'app potenzialmente difettoso. Un'iniezione di SQL riuscita dal contesto dell'utente reale potrebbe anche dargli accesso ai dati di altri client.
Ora parliamo di come la crittografia lato server si applica a queste situazioni:
- La crittografia lato server aiuta decisamente contro la minaccia di iniezione SQL. Se i valori di riga sono crittografati nelle tabelle DB, l'utente malintenzionato può vedere solo un testo cifrato dei dati che appartiene ad altri account. La minaccia è contenuta, compartimentata.
- La forzatura indebita della password, tuttavia, non diventa affatto più difficile per un attaccante che affronta la crittografia lato server. Indipendentemente dal fatto che le chiavi degli utenti siano archiviate sul server o generate in loco dalla password, l'unica cosa che conta è se si dispone della password corretta. O il server decide di consentire all'utente di utilizzare la chiave memorizzata valida perché verifica che la password sia corretta oppure calcola la chiave valida per l'utente poiché la password è l'input corretto per generare quella chiave.
La crittografia lato client, d'altra parte, in realtà rende irrilevanti gli attacchi con password a forza bruta. Non puoi forzare la forza di una chiave costruita correttamente. La crittografia lato client mantiene sostanzialmente lo stesso livello di protezione contro l'iniezione SQL anche della crittografia lato server. Il client può passare la chiave al server al momento dell'accesso, mantenendo una copia in memoria fino al termine della sessione, il che pone il carico della CPU crittografica sul server. In alternativa, il client può gestire la crittografia / decrittografia da solo, nel browser. Ci sono alti e bassi di entrambe le tecniche:
- Passare la chiave al server è molto più facile da programmare e gestire, e di solito molto più veloce a causa del codice crittografico più ottimizzato (compilato C, probabilmente).
- Un puro approccio lato client offre maggiore sicurezza, perché anche se un utente malintenzionato ottiene il root sul server, non è ancora in grado di leggere i dati crittografati e non sarà mai in grado di leggerli. L'unico vettore di attacco possibile è compromettere la workstation client remota.
Infine, noterò che ci sono alcuni enormi svantaggi operativi nella crittografia dei dati nel database. Poiché le rappresentazioni di dati crittografati sono essenzialmente modelli casuali, le funzionalità di base del database come indicizzazione, join, ecc. Non funzioneranno. Il client assume un enorme onere logico e può perdere molti dei vantaggi che le funzionalità del database normalmente comportano.