Las otras respuestas aquí son todas correctas en un par de aspectos clave. El archivo que contiene su cadena de conexión no debe guardarse en un lugar legible para todo el mundo y, como observa, no puede impedir que alguien acceda a la clave si ha comprometido su servidor. Aun así, hay otras razones para cifrar la clave (o el archivo). Parte de la razón por la que OWASP recomienda no almacenar en texto sin formato es para evitar la divulgación accidental de credenciales a quienes no las necesitan.
Si bien muchos señalan que cifrar la cadena de conexión en el sistema en ejecución proporciona poco valor real (seguridad por oscuridad), esto es cierto principalmente en el contexto del sistema en vivo. Asumiendo una configuración LAMP tradicional, los permisos basados en archivos evitarían la lectura de cualquier otro usuario que no sea el usuario del script en el que se está ejecutando el proceso php / apache. Tener el archivo fuera de la ubicación de la raíz proporciona un poco más de seguridad potencial (en caso de controladores MIME mal configurados o .htaccess) pero no es estrictamente necesario.
El mayor valor en la configuración de la conexión de separación es que los datos de autenticación y los datos ya no necesitan ser entregados a los desarrolladores / evaluadores u otras personas que puedan tener una necesidad real de conectarse al servidor. Al mantener los detalles de la conexión fuera del control de la fuente y fuera de la distribución general, reduce la posibilidad de pérdida o fuga.
Un segundo beneficio es la distribución y copia de seguridad de la fuente. Ciertamente, una práctica recomendada sería transferir solo archivos con información confidencial de conexión y de cuenta, pero por muchas razones, esto no siempre es práctico. Debido a esto, si el cifrado está en uso, separar la clave de la cadena de conexión y separar la cadena de conexión de la fuente es una acción esencial. Hacer esto ha separado los deberes y la protección de las claves de cifrado (o archivos de configuración) se convierte en una función de administrador del sistema, en lugar de una función de desarrollador.
De esta forma, en Apache / php tienes varias opciones.
1.) No ponga la cadena de conexión en el código php en absoluto. Puede poner estos valores en su archivo httpd.conf o hosts virtuales. La conexión entonces no requiere parámetros cuando se usa mysql_connect() ... el uso más detallado está disponible aquí: enlace
2.) Incluya el archivo de configuración configfile.php como de costumbre, pero mueva el archivo de conexión fuera de webroot si puede, y cifre el archivo en sí. El SA puede configurar el descifrado del sistema operativo para el proceso que accederá al archivo. Uso alternativo Si no puede mover el archivo fuera de webroot (alojamiento compartido), asegure el archivo con .htaccess
<files configfile>
order allow,deny
deny from all
</files>
Para Microsoft IIS con ASP.NET, la cadena de conexión se almacena en el archivo application.config o web.config y el cifrado utilizado puede ser una clave de máquina estática, almacenada en cualquiera de estos archivos, o una clave generada por IIS en sí, que no se almacena en una ubicación accesible. Los detalles están disponibles en MSDN, con lo que no haré esta respuesta ya que su pregunta fue específica para LAMP.
También debo tener en cuenta que, cuando sea posible, mi preferencia es evitar el problema por completo mediante el uso de la autenticación integrada. La asignación del usuario del sistema operativo a un usuario de base de datos elimina los requisitos de protección del contexto de esta pregunta casi por completo.