Le altre risposte qui sono corrette in alcuni aspetti chiave. Il file contenente la stringa di connessione non deve essere conservato in una posizione leggibile dal mondo e, come si nota, non è possibile impedire a qualcuno di ottenere la chiave se ha compromesso il proprio server. Anche così, ci sono altri motivi per crittografare la chiave (o il file). Parte del motivo per cui OWASP consiglia di archiviare in testo semplice è quello di impedire la divulgazione accidentale delle credenziali a coloro che non ne hanno bisogno.
Mentre molti sostengono che crittografare la stringa di connessione sul sistema in esecuzione fornisce un piccolo valore reale (sicurezza per oscurità) questo è vero soprattutto nel contesto del sistema live. Supponendo una configurazione LAMP tradizionale, le autorizzazioni basate su file impedirebbero la lettura a qualsiasi utente diverso dall'utente di script in cui è in esecuzione il processo php / apache. Avere il file al di fuori del root locatin fornisce un po 'più di sicurezza potenziale (in caso di gestori MIME o .htaccess mal configurati) ma non è strettamente necessario.
Il più grande valore nel separare le impostazioni di connessione è che i dettagli e i dati di autenticazione non devono più essere distribuiti a sviluppatori / tester o altri individui che potrebbero avere una reale necessità di connettersi al server. Mantenendo i dettagli della connessione fuori dal controllo del codice sorgente e fuori dalla distribuzione generale, si riduce la possibilità di perdite o perdite.
Un secondo vantaggio è la distribuzione e il backup della fonte. Sicuramente una buona pratica sarebbe quella di trasferire solo file contenenti connessioni sensibili e informazioni sull'account crittografate, ma per molte ragioni, questo non è sempre pratico. A causa di ciò, se la crittografia è in uso, separare la chiave dal connectiontring e separare il connectiontring dall'origine è un'azione essenziale. Questa operazione ha separato i compiti e la protezione delle chiavi di crittografia (o dei file di configurazione) diventa una funzione di amministratore di sistema, piuttosto che una funzione di sviluppatore.
Questo fuori mano, in Apache / php hai un numero di opzioni.
1.) Non inserire la stringa di connessione nel codice php. Puoi inserire questi valori nel tuo httpd.conf o nel file degli host virtuali. La connessione quindi non richiede parametri quando si utilizza mysql_connect() ... l'uso più dettagliato è disponibile qui: link
2.) Includere il file di configurazione configfile.php come normale, ma spostare il file di connessione fuori da webroot, se possibile, e crittografare il file stesso. La decrypyption del sistema operativo può essere impostata dalla SA per il processo che accederà al file. Uso alternato Se non puoi spostare il file fuori dal webroot (hosting condiviso) proteggi il file con .htaccess
<files configfile>
order allow,deny
deny from all
</files>
Per Microsoft IIS con ASP.NET, la stringa di connessione è memorizzata nel file application.config o web.config e la crittografia utilizzata può essere una chiave computerizzata statica, memorizzata in uno di questi file o una chiave generata da IIS stesso - che non è memorizzato in una posizione accessibile. Sono disponibili specifiche su MSDN, che non inoltrerò a questa risposta poiché la tua domanda era specifica per LAMP.
Devo anche notare che, quando possibile, preferisco evitare il problema utilizzando l'autenticazione integrata. Mappare l'utente os a un utente db allontana quasi del tutto i requisiti di protezione dal contesto di questa domanda.