在php变量或php常量中以纯文本形式存储密码可以吗？

根据问题，在php页面上存储密码是否安全

$password = 'pa$$w0rd';

如果用户看不到它，它是安全的，对吗

编辑：

---

实际上，有些人建议使用散列，但是，数据库服务器连接密码会有问题，不是吗？

除非站点本身被破坏，而且现在这些密码授予访问权限的所有内容（可能是您的数据库？）都会受到破坏。

这取决于您如何定义“安全”

你是对的，一般用户不会看到它

---

然而，这绝对是一种不好的做法；如果您的站点被破坏，这些密码还可以访问什么？我想说，至少你应该存储密码的散列，而不是明文。

通常他们看不到。但若服务器上发生了一些不好的事情，那个么服务器很有可能返回纯文本的php代码，而不执行它，所以用户将看到该文件的所有源代码以及密码

我会将密码存储在不在文档根目录下的某个位置（无法在浏览器中打开），然后用php打开该文件并读取内容（密码）。或者，如果您有多个密码/用户，我会将它们存储在数据库中以便快速访问

如果您想使用file方法，目录布局应该如下所示（服务器上的depneds）

/public_html/index.php

define( 'IN_CODE', '1' );

include( 'passwd.php' );

if( md5($password) == PASSWORD_HASH )
...

/password.txt

如果您希望更安全，而不是将密码作为文本存储在该文本文件中。确定它是散列，然后当您想要将其与用户输入进行比较时，从用户输入生成散列，并将其与从文本文件加载的密码散列进行比较

sha1($user_input) == $password_from_txt

---

只要您的PHP安装能够正常工作，它的安全性就不会低于任何其他方法。我更喜欢命名常量（define）而不是变量。另外，您可以考虑存储密码的散列，而不是普通密码。这可以防止窃取您的密码，即使该网站被破坏

---

至于坏习惯，这要看情况而定。如果您只需要存储一个密码，这种方法是可以的。将它们存储在文档根目录之外可能会给人一种额外安全的错觉；文档根目录并不比服务器的任何其他设置更绝对。

简短的回答是“否”，这取决于具体情况

以明文形式存储密码几乎从来都不是一个好主意，尤其是在可通过web访问的位置，如果出于否其他原因，而不是简单的服务器配置错误或错误位置的回音可能会将其暴露给全世界

如果必须存储密码（这是可能的），可以尝试将其存储在webroot之外，例如

/var/www/public\u html/

将代码放在这里

/var/www/includes/

在此处输入密码

比这更好的是让您需要密码的系统（例如数据库包装器）返回一个已经实例化的对象。因此，您不需要请求

$databasepassword

而是请求一个PDO对象，并将数据库类存储在webroot之外

这取决于什么样的攻击向量会导致某人访问该密码文本，以及它是否要求他们已经在您的文件系统中，如果是这样，您可能已经完蛋了

另外，如果是你的supa secrit订阅内容的密码，嗯，你丢失的只是一些订阅费，如果是你的数据库，你可能有问题，如果是你的网上银行详细信息，嗯，对你有好处

---

密码保护的东西有多大价值

根据您如何定义安全，任何方法都有其积极和消极的方面

如果您确实想在源代码中存储密码，最好执行以下操作：

文件：config.php

if( ! defined('IN_CODE') ) die( 'Hacking attempt' );

define( 'PASSWORD_HASH', '098f6bcd4621d373cade4e832627b4f6' );

文件：index.php

define( 'IN_CODE', '1' );

include( 'passwd.php' );

if( md5($password) == PASSWORD_HASH )
...

纯文本从来不是一个好主意，总是存储一个你想要存储的密码的散列

---

此外，请尝试将这样的定义与主源文件分开。

有时，对于只能使用普通密码而不能使用散列登录的邮件应用程序，它必须是f.e。如果您的应用程序没有安全问题，它应该不会影响您。

我相信，大多数情况下，纯文本密码将是数据库密码，因为对于exmaple，MySQL不接受哈希进行身份验证

如前所述，最好的解决方案是将带有密码的PHP配置文件保存在webroot之外

如果您担心在查看文件时有人会看到您的密码，只需使用base64函数将其设置为人类无法读取即可

---

有关详细信息，请参阅Windows、Linux和Mac的小型实用程序，这些工具使操作更加简单

我见过一些网站将php源代码作为纯文本输出。如果发生这种情况，并且文件位于docroot之外，即使每个人都知道文件的来源，他们也不能“简单地”从broswer访问它。我确实理解在docroot之外存储东西的想法，也许这会增加一些安全性，但我认为这被高估了。如果该站点转储了php源代码，那么它将被严重破坏。如果它坏了，docroot也可能是我们不希望的东西-例如/在webroot之外存储东西不是万能的，你不能随意打印变量。但它确实给了你一个分离，你可以在你的代码中强制执行，类和init在webroot之外，表示代码在webroot内部。如果你只有一个密码散列，你如何连接到数据库？是的，如果密码是用于数据库连接的（OP没有说明它是）那个么，在对数据库服务器进行身份验证期间，明文密码是通过tcp/ip发送的，而这是一个棘手的问题。大多数共享主机只有本地数据库在环回上运行，所以这并不是一个真正的问题。此外，如果您不在共享主机上，那么可能会有较少的安全问题需要担心重新访问文件系统等。尽管强烈建议不要使用相同的passwor