Per prima cosa devi assicurarti di non affrontare un problema x-y, perché avere un database per utente dietro la stessa applicazione non è il progetto più comune. È molto più comune condividere il database e consentire all'applicazione di implementare la separazione dell'utente. Tra gli altri vantaggi, hai una sola connessione al database, che facilita enormemente la scalabilità e la manutenzione del database.
Se hai davvero bisogno di questo design, la mia scelta preferita sarebbe quella di lasciare la responsabilità della password agli utenti. Se è un'opzione, la password del database potrebbe essere semplicemente la password dell'utente web. In questo modo non è nemmeno necessario memorizzarlo e basta creare la connessione al database al momento del login e chiuderlo al logout (o alla fine della sessione web). In alternativa, è possibile ricavare una chiave da ogni singola password Web e utilizzarla per crittografare la password del database per ciascun utente se si desidera mantenerli separati = > il risultato è lo stesso, è necessaria la password Web che non si archivia, per accedere al database
Se nessuna di queste opzioni è accettabile, è necessario memorizzare le password in una forma invertibile sul server delle applicazioni, ma è un incubo per la sicurezza. Le tue opzioni sono:
- non ti preoccupare affatto: archivia le password in chiaro e prega che nessuno possa mai accedere a quei dati - a sorpresa è un'opzione troppo comune (*) ...
- non importa molto: come sopra ma cripta le password con una chiave fissa codificata nell'applicazione - un po 'meglio perché l'attaccante ora ha bisogno di due elementi ma uno di essi non può mai cambiare
- fai del tuo meglio: crittografa le password con una chiave modificabile. Potrebbe essere letto dall'ambiente al momento del boot e cambiato su base regolare, ad esempio ogni mese per esempio. Ma ciò significa che quando si modifica la password principale è necessario modificare tutte le password del database in modo atomico - ok, qualsiasi database può farlo, ma beuhhh .... In alternativa è possibile simulare i vault della password e crittografare un intero file al costo che l'accesso a una singola password richiede una decrittazione completa, a meno che non si accetti di mantenere il database completo in testo in chiaro.
(*) ... ma può essere un'opzione accettabile se il server delle applicazioni e i server del database si trovano nella stessa zona di sicurezza .
.