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

#1 楼

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

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

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

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

如果这使他们进入其他帐户怎么办？别被黑客通过用户支持系统并获取更多信息。这是您用户的私人信息，您不需要能够看到它。这也是你的声誉。对其进行加密。

编辑：另外添加一条注释，以免将来的读者阅读任何答案和评论...

如果要加密（最严格的方法） ），那么您需要使用公钥/私钥对，这很好，但是会使您和您的用户的生活更加困难。

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

#2 楼

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

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

没有哈希，您将不得不禁止所有人访问，直到他们更改密码（即使可能，这也是很大的选择）让每个人都头疼）。如果密码已经过哈希处理，那么您可以恢复该Web服务，这将使攻击者更难访问人们的帐户。

经过适当哈希处理和加盐处理的密码基本上是单向密码。您不能轻易地从哈希密码中猜出密码。甚至您，由于服务提供商将无法猜到它，您只能重置它。使用标准库。

#3 楼

但是，如果有人进入我的数据库，我还有其他问题，即删除数据。其他用户。这是关于消除对网站上工作的人的诱惑（甚至更糟的是，潜在的责任），他们滥用存储在该网站上的数据。

...而且由于哈希密码非常容易，因此您没有理由不遵循行业最佳实践。

#4 楼

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

此外，并非所有的妥协都能为您提供完整的Shell访问权限。如果攻击者使用的漏洞只是users表上的只读SQL注入怎么办？保留密码就不会给他带来太多的完全访问权限。

这是其他答案所赋予的有关保护用户数据责任的原因的补充。我的意思是，损失的不仅仅是您的用户。

#5 楼

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

让我们来看一下定义：


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


和散列：


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


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

此外，不要只是哈希，加盐！在对密码进行哈希处理之前，请阅读整页内容。

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

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

考虑阅读此页以确保您的登录过程更加安全。

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

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

#6 楼

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

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

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

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

更常见的解决方案是：

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

原始然后，将字符串覆盖到内存中，然后，将盐腌的哈希存储在数据库中或与数据库记录进行比较。 br />
哈希的知识不直接提供身份验证。
Reve从哈希计算密码的其他方法是不切实际的。
使用彩虹表（一长串的密码及其计算出的哈希值）变得更具挑战性，因为生成的哈希值取决于用户名和密码。

#7 楼

您需要将密码“加密”（实际上是“散列”，以实现正确的散列概念）作为第二层防御：这是为了防止攻击者（以只读方式浏览数据库）逐步升级进行读写访问，并准确地开始更改数据。只读局部违规发生在现实世界中，例如通过具有只读访问权限的帐户进行的某些SQL注入攻击，或者通过从垃圾箱中获取废弃的硬盘或旧的备份磁带来进行。我已经在这里详细讨论了这个问题。

关于散列密码的正确方法，请参见此答案。这涉及到盐，迭代，而且最重要的是，这并不是在发明自己的算法（自制加密技术肯定会带来灾难）。

#8 楼

我不会重复别人说的话，但是假设您拥有PHP 5.3.8或更高版本，则应该使用PHP本机bcrypt来存储密码。这是内置在PHP中的。如果您具有PHP 5.5，则可以使用最佳的可用密码常数。
您还可以使用一个库使5.3.8或更高的行为类似于5.5。 bcrypt在PHP哈希密码？解释它，那里的其他答复解释了更多。请不要自欺欺人。

#9 楼

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

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

评论

---

+1既可以提及盐析和哈希，也可以不提及加密，这甚至都不属于这个问题。

– NobleUplift
2014年1月30日在16:49

---

#10 楼

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


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

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

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


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

#11 楼

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

#12 楼

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

您可能拥有世界上最好的IT安全性，但这并不能阻止任何人可以物理访问您的存储介质。当您的团队今天下午赢得超级碗比赛，并且办公室/托管服务提供商所在的城市闹市区爆发小规模骚乱时，会发生什么情况？ （考虑到西雅图与丹佛是美国的两个大型IT领域，我认为这是没有道理的）。暴徒闯入您的建筑物，当当局不知所措时，有人抢了您的一些硬件，上面有一个包含明文密码的数据库？设备，因为一些高级管理人员正在利用他在公司中的职位执行非法股票交易？然后，美联储使用这些密码来调查您的客户，尽管他们没有做错任何事情。然后他们意识到是让您容易受到攻击的是您。实习生，然后他们的宿舍室友找到留下的东西，并弄清楚他们可以“出售”它，而永远不会追溯到他们身上？将映像还原到新服务器，而旧服务器的“遗体”被扔到回收堆中？这些驱动器仍然很好，并且数据仍然存在。从一开始就必须将安全性作为设计的基本部分，这意味着密码是单向散列的，绝不会未经加密就传输（即使在您自己的数据中心内），并且永远不可恢复。可以检索的任何内容都会受到损害。

#13 楼

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

#14 楼

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

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

这就是为什么使用不对称加密协议存储密码的原因，以确保您可以在不读取密码的情况下进行验证。

#15 楼

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

如果有人对您感兴趣，您就会被黑。重要的是，尽最大努力防止被黑客入侵，但同时也要通过设置尽可能多的障碍来减轻损坏时的损失。散列密码。设置起来并不难，并且您由于不认真对待用户的隐私而给用户带来了损害。认为您比像Yahoo，Sony或Target这样被黑的公司更好地抵御了恶意攻击，这是一种狂妄自大。