如果密码存储在安全的数据库中，为什么还要加密？

我有一个网络服务。现在，我的密码以纯文本格式存储在服务器上的MySQL表中。我知道这不是最佳做法，这就是为什么我正在努力。

如果密码存储在安全的数据库中，为什么还要加密？我意识到，如果有人入侵我的数据库，他们将获得每个人的密码。但是如果有人进入我的数据库，我还有其他问题，例如删除数据。

我能想到的情况是您被黑了。您从几个小时前还原了数据库，一切都很好。但是，如果您的密码是纯文本...小偷拥有所有密码，则必须重置所有密码。麻烦您的用户。

如果密码已加密，则可以还原到以前的数据库。这是正确的想法吗？

首先，您应该拥有比只读更多的自由访问权限。黑客可能会访问您的数据，但无法对其进行编辑。

但是，更重要的是，这与您无关。如果某人具有对数据库的完全访问权限，您可能会被搞砸，这一事实是无关紧要的。更重要的是用户的数据。

如果您恢复数据库，则黑客仍然有权访问您的用户帐户。

还有谁知道呢？如果他们在Google使用相同的密码怎么办？还是贝宝？如果这样可以使黑客访问其母亲的姓氏或信用卡的后4位数字，该怎么办？

如果这使他们进入其他帐户怎么办？不要让黑客通过用户支持系统来获取更多信息。

只是...只是不。这是您用户的私人信息，您不需要能够看到它。这也是你的声誉。加密。

编辑：一个额外的注释，以保存任何未来的读者从阅读每个答案和评论...

如果要进行加密（从最严格的意义上讲），则需要使用公钥/私钥对，这很好，但是会使您和您的用户的生活更加困难。

一种更简单有效的解决方案是对密码进行随机加盐和哈希处理。仅靠散列是不够的。如果您的用户使用通用密码，则它将显示在反向哈希表中，通过简单的Internet搜索即可轻松获得。

如果遭到黑客入侵，则可以从备份中还原站点并进行修复。 但是黑客仍然拥有每个人帐户的密码！ 有记录在案的现实世界中的例子（Sony，已链接），在这些例子中，如果正确地对哈希表进行哈希处理和添加盐分，那么快速保护和恢复服务就容易得多。

考虑到这一假设，假设您将被黑客入侵，并设计备份策略并加密所有敏感数据可能是一个好主意。而且不仅仅是需要防御的黑客。不满，不诚实或无知的员工可能会泄露纯文本密码。

如果不进行散列，则必须禁用所有人的访问权限，直到他们更改密码为止（即使可能，这也将使所有人头疼）。如果密码已经过哈希处理，那么您可以恢复该Web服务，这将使攻击者更难于访问人们的帐户。

正确散列和加盐的密码基本上是单向的。您不能轻易地从哈希密码中猜出密码。甚至您，由于服务提供商将无法猜测，您只能重置它。

另外，正如Elin所说，请勿尝试滚动自己的哈希（或加密）。使用标准库。

但是如果有人进入我的数据库，我还有其他问题，即删除数据。

这与您遇到的问题无关，而与所有其他用户可能遇到的问题有关。这是关于消除对网站上的工作人员滥用存储在其中的数据的诱惑（甚至更糟的是，潜在的责任）。

看到，即使人们应该在不同的系统上使用不同的密码，事实是事实并非如此。

...而且由于很容易对密码进行散列，因此您没有理由不遵循行业最佳实践。

诸如删除数据之类的引人注目的攻击通常是业余爱好者的事，并且是您最少的担心。有经验的攻击者要做的第一件事就是尝试获得合法的访问权限，因此，即使您修补了他使用的原始漏洞，他也仍然可以进入。他将尽一切可能避免引起对他的注意，直到他完成他想要的。通过不打乱密码，您可能会使他的工作容易得多。您也使检测和隔离他未来的恶意行为变得更加困难。

另外，并非所有妥协都可以让您完全使用shell。如果攻击者使用的漏洞只是users表上的只读SQL注入，该怎么办？保留密码不变，这给了他几乎完全的访问权限。

除此之外，其他答案还提供了有关您有责任保护用户数据的原因。我的意思是，损失的不仅仅是您的用户。

我必须在这里就问题本身的谬误发表答案。您在询问是否应加密密码。没有人会加密密码。除了Firefox Sync和Roboform之类的服务和程序，其唯一目的是对密码进行加密，没有人可以拒绝。

让我们看一下定义：

在密码术中，加密是对消息（或信息）进行编码的过程，以使只有授权方才能读取它。

和哈希：

哈希函数是将任意长度的数据映射到固定长度的数据的任何算法。

换句话说，加密是双向转换，而哈希是单向转换，因此除非您稍后解密以查看它们，否则这不是加密。

另外，不要只是哈希，盐！散列密码之前，请先阅读整个页面。

至于OP现在正在研究的哈希算法，我建议使用任何高端SHA-2变量，例如SHA-384或SHA-512。

并确保使用回合哈希。不要散列一次，散列多次。

考虑阅读此页面以进一步保护您的登录过程。

其次，您的数据库永远不可能足够安全。始终会有安全漏洞和不断变化的风险。您应该遵循墨菲定律，并始终为最糟糕的情况做准备。

pdr提出的其他观点恰恰是我要说的：对每个网站使用相同密码的人，利用社会工程学获取更多信息的黑客等等。

这里有一个重要的原则在讨论。只有一个从事任何业务的人都知道用户密码。那是用户。不是他们的妻子/丈夫，他们的医生甚至是牧师。

它绝对不包括负责他们使用的服务的程序员，数据库管理员或系统技术人员。这就带来了挑战，因为程序员确实有责任接收证明用户实际上知道密码的证据，这纯粹是解决不小的问题。

纯粹的解决方案是具有一种机制，使用户面临一些新的且不可预测的数据的挑战，然后必须基于此数据及其密码返回响应。一种实现方式是要求用户使用他们的数字签名对一些新生成的数据进行数字签名，并且我们可以从数学上证明他们使用了与最初创建帐户时相同的加密密钥对。

实际上，纯解决方案需要大量的客户端基础结构和处理，并且对于许多网站而言，这通常不适用于受保护的数据。

一个更常见的解决方案是：

在应用程序中首次接收到密码时，该密码将与应用程序的随机“ salt”值一起传递给哈希函数。

然后，原始字符串将在内存中被覆盖，从那时起，加盐的哈希将存储在数据库中或与数据库记录进行比较。

这里提供安全性的关键方面是：

1. 哈希的知识不会直接提供身份验证。
2. 从哈希反向计算密码是不切实际的。
3. 使用彩虹表（一长串密码及其计算出的哈希值）变得更具挑战性，因为生成的哈希值取决于用户名和密码。

您需要对口令进行“加密”（实际上是“散列”，以获得适当的散列概念）作为第二层防御：这是为了防止攻击者（以只读方式查看数据库）升级进行读写访问，并确切地开始更改数据。在现实世界中会发生只读的部分破坏，例如，通过具有只读访问权限的帐户的某些SQL注入攻击，或者通过从垃圾箱中回收废弃的硬盘或旧的备份磁带，来发生这种情况。我在那儿写了很长的篇幅。

至于散列密码的正确方法，请参见此答案。这包括盐，迭代，以及最重要的，不是你自己发明的算法（自制加密是一种肯定后患无穷）。

我不会重复别人说的话，但是假设您拥有PHP 5.3.8或更高版本，则应该使用PHP本机bcrypt来存储密码。这是内置在PHP中的。如果您有PHP 5.5，则可以使用最佳的可用密码常数。您还可以使用库使5.3.8或更高的行为类似于5.5。

堆栈溢出问题如何使用bcrypt在PHP中对密码进行哈希处理？解释它，那里的其他答复解释了更多。请不要自欺欺人。

由于该答案中所述的原因，我同意pdr的答案。

我将添加以下内容：您应该这样做，因为它易于执行，并且通常被认为是任何应用程序的最佳实践。更具体地说，在写入任何持久性存储之前，应始终对密码进行加密和哈希处理。这是关于加盐和选择良好的加密哈希（还提供几种流行语言的免费源代码）的重要性的很好的参考：https : //crackstation.net/hashing-security.htm

少量的额外开发时间非常值得，它为您的用户提供了保护，并赢得了您作为开发人员的声誉。

我能想到的情况是您被黑了。

您需要考虑的另一种情况是：某人让您的DBA滑倒（或者其他任何人可以在您的DB上运行选择查询）$ 100，以向他们提供用户密码。或由社会工程师来实习。

然后，他们使用这些密码登录到用户的Gmail ...或商业网站...（因为人们……我们不应该这么聪明-并在各个网站上使用相同的密码）。

然后，愤怒的用户起诉您的公司以公开其密码。

NOBODY（包括您公司中的人员）应该能够读取纯文本密码。曾经 没有合法的业务或技术需求。

首先，即使数据库管理员也不应看到用户的密码。如果管理员决定查看密码并登录其用户帐户，则对它们进行哈希处理将防止这种情况。

好吧，令人惊讶的是没有人提到这件事，但是数据库的物理安全性又如何呢？

您可能设置了世界上最好的IT安全性，但这并不能阻止任何人可以物理访问您的存储介质。当您的团队今天下午赢得超级碗比赛，并且办公室/托管服务提供商所在的城市闹市区爆发小规模骚乱时，会发生什么情况？（考虑到西雅图与丹佛是美国的两个大型IT领域，我认为这是不合理的）。暴民闯入您的建筑物，当当局不知所措时，有人抢了您的一些硬件，上面有一个包含明文密码的数据库？

当美联储出现并抓住您的设备时，会发生什么？然后，美联储使用这些密码来调查您的客户，尽管他们没有做错任何事情。然后他们意识到是您让他们脆弱。

当您的IT部门在按计划进行替换之前忘记擦拭保存数据库的旧RAID驱动器，然后将旧驱动器“分发”给实习生，然后他们的宿舍室友找到留下的东西，并弄清楚他们可以“清除”时，会发生什么情况？出售”，而它却从未追溯到他们？

当您的数据库服务器损坏主板，IT将映像还原到新服务器并将旧服务器的“遗体”扔到回收堆中时，会发生什么？这些驱动器仍然很好，并且数据仍然存在。

任何体面的架构师都知道，防火墙和操作策略不会在以后“加强”安全性。从一开始就必须将安全性作为设计的基本部分，这意味着密码是单向散列的，绝不会在未加密的情况下传输（即使在您自己的数据中心内部），并且永远不可恢复。可以检索的任何内容都会受到损害。

撇开数据库被黑客入侵的情况来看：作为客户，我不想让您知道我的密码。我知道您可以在请求中轻松获取密码，但是当您不愿意使用它随时查询时，我会感觉更好。

如果密码以纯文本格式存储，则意味着用户以及有权访问该表的任何人都知道密码。关于实现用户和密码的整个想法是，出于隐私和安全方面的考虑，确保系统中的某个会话属于该用户。

如果一群人知道用户名/密码，那么毫无疑问地无法识别一个人，这将为身份盗窃，欺诈创造许多可能的情况。

这就是使用非对称加密协议存储密码的原因，以确保您可以验证密码而又无法读取它们。

我认为这个问题有一个根本性的缺陷。事实是，没有“安全数据库”之类的东西。应当认为，您的系统中存在一些漏洞，这些漏洞可能允许恶意用户访问您服务器上的任意数据。Heartbleed是一个很好的例子，这是一种在研究人员发现之前就已经存在了两年多的野蛮漏洞。您可能已经做了所有您知道该怎么做才能保护数据的事情，但是您无法说明服务器上正在使用的所有其他软件以及它们交互的复杂方式。

如果有人对您感兴趣，您将被黑。重要的是，尽最大努力防止被黑客入侵，同时通过尽可能多地设置障碍来减轻发生这种情况时所造成的损害。散列密码。设置起来并不难，并且您由于不认真对待用户的隐私而给用户带来了损害。认为您比Yahoo，Sony或Target等公司都遭到了黑客攻击时，能以某种方式更好地抵御恶意攻击是一种骄傲。