Devo eseguire la crittografia nel front-end o nel database?

Penso che dipenderebbe da eventuali piani futuri che hai. Ti vedi usare qualcosa di diverso da MySQL? O forse ti vedi di usare un altro algoritmo di crittografia?

Se puoi rispondere sì (o forse) a uno di questi due, allora sarebbe un buon investimento per delegare quell'attività al "middle ware", che idealmente dovrebbe venire tra il front-end e il DB.

Ci sono molte cose che dipendono da questo, ma tenderei a metterlo nel livello dell'applicazione piuttosto che nel database.

1. se qualcuno scarica il tuo database, potenzialmente ha il codice di crittografia. Ciò significa che a questo proposito il tuo tentativo di proteggere i dati è inutile. Ricorda che devi sempre assumere uno scenario peggiore, quindi se hanno il codice, allora devi presumere che possano usarlo.

2. La crittografia non è ciò per cui viene utilizzato un database. Nel ridimensionamento dei sistemi, è sempre possibile aggiungere facilmente un altro server delle applicazioni. È difficile aggiungere un database (sincronizzando i due ecc.). Cerco di mantenere il più piccolo codice di logica di business possibile sul server di database, perché se si inizia a processare cpu e memoria nel database, è necessario iniziare la migrazione da quel server. È più facile non doverlo fare prima.

Poiché AES_ENCRYPT / DECRYPT sono solo funzioni che puoi applicare ai tuoi dati come parte della query, non vedo come ciò causerebbe il blocco. Se scrivi il tuo codice per usarlo, cambia idea e decidi è meglio averlo gestito dal tuo front-end, dovrai solo:

1. Modifica le tue query / visualizzazione in modo che non utilizzino più tali funzioni;
2. Cambia il codice chiamando quelle query e falle crittografare / decodificare i dati utilizzando lo stesso algoritmo.

(Queste due modifiche devono entrare in vigore simultaneamente, naturalmente, anche l'operazione inversa è possibile)

Il vantaggio principale che vedo nel farlo nel front-end è che puoi scegliere altri valori per la dimensione della chiave e il padding (MySQL usa rispettivamente 128 e 16), se necessario. Puoi anche modificare l'algoritmo più facilmente, se alla fine decidi che AES non è la scelta migliore.

Ho dimenticato le implicazioni sulla sicurezza del tuo setup, dal momento che è difficile capire da quali tipi di rischi stai cercando di proteggere i tuoi dati. Tuttavia, sono d'accordo con @Kevin sul fatto che ottieni un po 'più di sicurezza (per oscurità) se non mostri esplicitamente l'algoritmo nel database, assumendo che il tuo codice sia tenuto segreto.

Modifica: sembra aver frainteso l'argomento di Kevin; mentre sono d'accordo sul fatto che nascondere l'algoritmo è in gran parte inutile, l'hacking del tuo server non è l'unico modo per un hacker di accedere al tuo database - i processi che usi per effettuare backup regolari di esso, inclusi quelli offline, creano più opportunità per perdite di dati che non si applica necessariamente al codice (che potrebbe avere anche le proprie vulnerabilità di processo). Ma alla fine ciò che conta di più è quanto siano forti e ben protette le tue chiavi di crittografia.

Se si memorizza un testo normale, si disaccoppia la sicurezza dal database e dalla logica aziendale, tuttavia se il database è accessibile, gli indirizzi e-mail sono in testo normale. C'è stata più di un'istanza di aggressori che ha ottenuto backup e / o vecchie unità. I dipendenti che hanno accesso al DB hanno accesso ai dati di testo semplice, ma non dati encessivamente nessicisticamente (dipende se hanno accesso alla chiave) ... Cosa stai veramente dopo - un reclamo sei sicuro, se sì da chi, o in profondità di sicurezza in cui sei protetto dal maggior numero possibile di aggressori.

Personalmente se volessi la sicurezza, vorrei crittografare nel database e memorizzare la chiave su una macchina separata (se non del tutto). È un po 'più doloroso, ma molto più sicuro. Se tutto ciò che volevo era reclamare la sicurezza, avrei archiviato i dati in testo semplice.