如果您使用的是postgresql，那么它会在 ~/.pgpass 自动输入密码。有关更多信息，请参阅手册。

实际上，最佳做法是将数据库索引存储在环境变量中，因为：
这些凭据取决于环境，这意味着您在dev/prod中不会有相同的凭据。将它们存储在所有环境的同一文件中是一个错误。
凭证与业务逻辑无关，这意味着登录和密码与代码无关。
您可以在不创建任何业务代码类文件的情况下设置环境变量，这意味着您永远不会犯在git中将凭证文件添加到提交的错误。
环境变量是超全局变量：您可以在代码中的任何地方使用它们，而不包括任何文件。
如何使用它们？
使用$\u env数组：
设置： $_ENV['MYVAR'] = $myvar 得到： echo $_ENV["MYVAR"] 使用php函数：
使用putenv函数进行设置- putenv("MYVAR=$myvar"); 使用getenv函数获取- getenv('MYVAR'); 在vhosts文件和.htaccess中，但不建议这样做，因为它位于另一个文件中，这样做并不能解决问题。
您可以轻松地删除一个包含所有环境变量的文件（如envvars.php）并执行它( php envvars.php )然后删除它。这有点老套，但它仍然有效，服务器中没有任何包含凭据的文件，代码中也没有凭据。因为这有点费劲，所以框架做得更好。
例如symfony（好的，不仅仅是php）现代框架，如symfony建议使用环境变量，并将它们存储在.env not committed文件中或直接存储在命令l中

最好的方法是根本不存储密码！
例如，如果您在windows系统上，并且连接到sql server，则可以使用集成身份验证，使用当前进程的标识连接到数据库，而无需密码。
如果确实需要使用密码进行连接，请首先使用强加密（例如，使用aes-256，然后保护加密密钥，或者使用非对称加密并让操作系统保护证书）对其进行加密，然后将其存储在具有强ACL的配置文件（web目录之外）中。

通常的做法是将其放入某个配置文件中。只要确保你：
不允许从网络之外的任何服务器访问数据库，
注意不要意外地向用户显示密码（在错误消息中，或通过php文件意外地用作html等等）

另一个技巧是使用一个单独的php配置文件，如下所示：

<?php exit() ?>

[...]

Plain text data including password

这并不妨碍您正确设置访问规则。但是，如果您的网站被黑客攻击，那么“require”或“include”将在第一行退出脚本，因此获取数据更加困难。
但是，千万不要让配置文件位于可以通过web访问的目录中。您应该有一个“web”文件夹，其中包含您的控制器代码、css、图片和js。这就是全部。其他任何内容都会放在脱机文件夹中。

如果您谈论的是数据库密码，而不是来自浏览器的密码，那么标准做法似乎是将数据库密码放在服务器上的php配置文件中。
您只需要确保包含密码的php文件具有相应的权限。i、 e.它应该只能由web服务器和您的用户帐户读取。

将数据库密码放入文件中，使其对提供文件服务的用户为只读。
除非您有某种方法只允许php服务器进程访问数据库，否则这几乎是您所能做的全部。

我们通过以下方式解决了这个问题：
在服务器上使用memcache，并打开与其他密码服务器的连接。
将密码（甚至所有加密的password.php文件）和解密密钥保存到memcache。
该网站调用持有密码文件的memcache密钥来解密内存中的所有密码。
密码服务器每5分钟发送一个新的加密密码文件。
如果您在项目中使用encrypted password.php，那么您将进行审计，检查此文件是否在外部接触或查看。发生这种情况时，您可以自动清理内存，并关闭服务器进行访问。

您的选择有点有限，因为您说需要密码才能访问数据库。一种通用方法是将用户名和密码存储在单独的配置文件中，而不是主脚本中。然后确保将其存储在主web树之外。如果存在web配置问题，导致php文件只显示为文本而不是执行，那么您就没有公开密码。
除此之外，您对正在使用的帐户的访问权限最小。再加上
不要将用户名/密码组合用于任何其他用途
将数据库服务器配置为仅接受来自该用户的web主机的连接（如果数据库位于同一台计算机上，则localhost更好），这样即使凭据已公开，也不会对任何人有用，除非他们具有对该机的其他访问权限。
混淆密码（即使rot13也可以）如果有人访问该文件，它不会提供太多防御，但至少可以防止随意查看该文件。
彼得

有几个人将此误解为关于如何在数据库中存储密码的问题。这是错误的。它是关于如何存储让您访问数据库的密码。
通常的解决方案是将密码从源代码移到配置文件中。然后将管理和保护该配置文件的工作交给系统管理员。这样，开发人员就不需要知道任何有关生产密码的信息，并且在源代码管理中也没有密码记录。

以前，我们将db user/pass存储在一个配置文件中，但后来进入了偏执模式——采用了纵深防御策略。
如果您的应用程序遭到破坏，用户将拥有对您的配置文件的读取权限，因此可能会有黑客读取此信息。配置文件也可能会被版本控制缠住，或者被复制到服务器上。
我们已经切换到在apache virtualhost中存储用户/传入环境变量集。此配置只能由root用户读取——希望您的apache用户不是以root用户身份运行。
这样做的缺点是密码现在位于全局php变量中。
为了降低这一风险，我们采取了以下预防措施：
密码是加密的。我们扩展了pdo类，以包含用于解密密码的逻辑。如果有人阅读了我们建立连接的代码，那么很明显，连接是用加密密码建立的，而不是密码本身。
加密密码从全局变量移动到私有变量。应用程序立即执行此操作，以减少值在全局空间中可用的窗口。 phpinfo() 它是残疾的。phpinfo是一个很容易获得包括环境变量在内的所有内容概览的目标。

如果可以在存储凭据的同一文件中创建数据库连接。在connect语句中内联凭据。

mysql_connect("localhost", "me", "mypass");

否则，最好在connect语句之后取消设置凭据，因为不在内存中的凭据无法从内存中读取；）

include("/outside-webroot/db_settings.php");  
mysql_connect("localhost", $db_user, $db_pass);  
unset ($db_user, $db_pass);

此解决方案是通用的，因为它对开放源代码应用程序和封闭源代码应用程序都很有用。
为应用程序创建操作系统用户。看见http://en.wikipedia.org/wiki/principle_of_least_privilege
使用密码为该用户创建（非会话）os环境变量
以该用户的身份运行应用程序
优势：
您不会意外地将密码检查到源代码管理中，因为您不能
您不会意外地破坏文件权限。好吧，你可以，但这不会影响这个。
只能由root用户或该用户读取。root用户可以以任何方式读取您的所有文件和加密密钥。
如果使用加密，如何安全地存储密钥？
works x平台
确保不要将envvar传递给不受信任的子进程
这种方法是由非常成功的heroku提出的。

对于非常安全的系统，我们在配置文件中加密数据库密码（配置文件本身由系统管理员保护）。在应用程序/服务器启动时，应用程序会提示系统管理员输入解密密钥。然后从配置文件读取数据库密码，解密并存储在内存中以备将来使用。仍然不是100%安全，因为它是存储在内存中解密的，但您必须在某个时候称之为“足够安全”！

将它们存储在web根目录之外的文件中。