Avere utenti di database separati (con password separate), oltre all'utente root, è una buona pratica. Ciò consente di proteggere i dati per ciascun database, in modo che se la password di un database viene persa, non comprometta i dati nell'altro database. E non devi usare la password di root ovunque, tranne quando esegui la manutenzione del database.
In altre parole, la differenza tra l'accesso condiviso per tutti gli utenti del database e gli accessi separati è che l'utente malintenzionato può accedere a meno dati quando si utilizzano accessi separati. Perché anche se l'utente malintenzionato non può accedere a root, può comunque leggere i dati appartenenti all'utente compromesso e forse fare qualche danno. Ma il resto del tuo database è protetto.
Questo perché il modo più probabile in cui gli utenti malintenzionati accederanno al tuo database è tramite l'exploit di tipo SQL injection nell'applicazione, oppure accedendo in qualche modo alla tua rete e scoprendo le credenziali dell'account nei file di configurazione.
Nel primo caso, perdi solo i dati nel database con l'exploit. Nel secondo caso (con un utente malintenzionato nella rete), hanno ancora accesso ai dati nel database solo con la configurazione trapelata. In nessun caso l'aggressore sarà in grado di accedere all'account root.
Si tratta del principio del privilegio minimo .
Inoltre, è possibile avere schemi di rotazione delle chiavi diversi per i due account, sia in termini di frequenza con cui si modificano le password, sia in base alla modalità di distribuzione. E questo, sospetto, è il valore più pratico nell'avere password diverse. Nel corso del tempo, le password probabilmente divergerebbero comunque, o causerebbero molti grattacapi operativi.