当我继续建立越来越多的网站和网络应用程序时,我经常被要求存储用户的密码,如果/当用户有问题时,它们可以被检索(要么通过电子邮件发送一个忘记密码的链接,通过电话等),当我可以与这种做法作斗争时,我做了大量的“额外”编程,使密码重置和管理协助成为可能,而不存储他们的实际密码。

当我无法对抗它(或无法获胜)时,我总是以某种方式对密码进行编码,这样至少它不会以明文形式存储在数据库中——尽管我知道如果我的数据库被黑客攻击,罪犯不需要花费太多时间就能破解密码,所以这让我感到不舒服。

在一个完美的世界里,人们会经常更新密码,而不会在许多不同的网站上重复密码——不幸的是,我知道很多人都有相同的工作/家庭/电子邮件/银行密码,甚至在他们需要帮助的时候免费给我。如果我的数据库安全程序因为某种原因失败了,我不想成为他们财务崩溃的罪魁祸首。

从道德和伦理上讲,我觉得我有责任保护一些用户的生活,即使他们对他们的生活不那么尊重。 我确信有许多方法和论点可以用于盐散列和不同的编码选项,但当您必须存储它们时,是否存在单一的“最佳实践”?在几乎所有的情况下,我使用PHP和MySQL,如果这使任何不同的方式,我应该处理的细节。

Bounty的其他信息

我想澄清的是,我知道这不是你想要做的事情,在大多数情况下,拒绝这样做是最好的。然而,我并不是在寻求关于采用这种方法的优点的说教,我是在寻找如果你确实采用这种方法,应该采取的最佳步骤。

在下面的注释中,我指出了主要面向老年人、智障人士或非常年轻的人的网站,当他们被要求执行安全密码恢复程序时,他们会感到困惑。尽管在这些情况下,我们可能会发现这很简单,但有些用户需要额外的帮助,要么让服务技术人员帮助他们进入系统,要么通过电子邮件/直接显示给他们。

在这样的系统中,如果用户没有得到这种级别的访问帮助,来自这些人口统计数据的流失率可能会阻碍应用程序,所以请在回答时考虑到这样的设置。

谢谢大家

这是一个有趣的问题,有很多争论,我很喜欢。最后,我选择了一个答案,它既保留了密码安全性(我不必保留纯文本或可恢复的密码),又使我指定的用户群能够登录到一个系统,而不存在我在正常密码恢复中发现的主要缺陷。

像往常一样,由于不同的原因,大约有5个答案我想标记为正确,但我必须选择最好的一个——其余的都是+1。谢谢大家!

同时,感谢Stack社区中为这个问题投票和/或将其标记为最喜欢的人。我把获得100票作为一种赞美,希望这个讨论能帮助到和我有同样担忧的人。


当前回答

密码遗失/忘记处理:

没有人能够恢复密码。

如果用户忘记了密码,他们至少必须知道自己的用户名或电子邮件地址。 根据请求,在Users表中生成GUID,并向用户的电子邮件地址发送包含GUID作为参数的链接的电子邮件。

链接后面的页面验证参数guid是否真的存在(可能带有一些超时逻辑),并要求用户输入新密码。

如果您需要热线帮助用户,请向授予模型中添加一些角色,并允许热线角色临时以已识别的用户登录。记录所有此类热线登录。例如,Bugzilla为管理员提供了这样的模拟功能。

其他回答

在独立服务器上打开一个数据库,并给每个需要此功能的web服务器一个加密的远程连接。 它不必是关系DB,它可以是具有FTP访问权限的文件系统,使用文件夹和文件而不是表和行。 如果可以的话,给web服务器只写权限。

像正常人一样,在网站的数据库中存储不可检索的密码加密(让我们称之为“pass-a”):) 对于每个新用户(或密码更改),在远程DB中存储密码的普通副本。使用服务器id,用户id和“pass-a”作为这个密码的组合密钥。你甚至可以在密码上使用双向加密,这样晚上睡得更好。

现在,为了让某人同时获得密码和它的上下文(站点id +用户id +“pass-a”),他必须:

入侵网站的数据库,以获得(“pass-a”,用户id)对或对。 从配置文件中获取网站的id 找到并侵入远程密码数据库。

您可以控制密码检索服务的可访问性(仅将其公开为安全的web服务,每天只允许一定数量的密码检索,手动进行,等等),甚至为此“特殊安全安排”收取额外费用。 密码检索数据库服务器是相当隐藏的,因为它不提供很多功能,可以更好地保护(你可以定制权限,进程和服务紧密)。

总而言之,你让黑客的工作变得更加困难。在任何一台服务器上出现安全漏洞的几率都是一样的,但是有意义的数据(帐户和密码的匹配)将很难组合起来。

中途教习所怎么样?

使用强加密存储密码,不要启用重置。

与其重置密码,不如允许发送一次性密码(必须在第一次登录时立即更改)。然后让用户更改为他们想要的任何密码(如果他们选择,是之前的密码)。

你可以把它作为一种重置密码的安全机制来“推销”。

从我对这个主题的了解来看,我相信如果你正在构建一个有登录/密码的网站,那么你甚至不应该在你的服务器上看到明文密码。在密码离开客户端之前,应该对其进行散列处理,可能还需要加盐。

如果您从未看到明文密码,那么就不会出现检索问题。

此外,我(从网上)收集到(据称)一些算法,如MD5不再被认为是安全的。我自己没有办法判断,但这是值得考虑的。

允许用户检索其原始密码的唯一方法是使用用户自己的公钥对其加密。只有该用户才能解密他们的密码。

步骤如下:

用户在您的站点上注册(当然是通过SSL)而无需设置密码。自动登录或提供临时密码。 您提供存储他们的公共PGP密钥,以便将来检索密码。 他们上传他们的公共PGP密钥。 你让他们设置一个新密码。 他们提交密码。 您使用可用的最佳密码哈希算法(例如bcrypt)哈希密码。在验证下一次登录时使用此选项。 使用公钥加密密码,并单独存储。

如果用户随后询问他们的密码,您将使用加密的(而不是散列的)密码进行响应。如果用户不希望将来能够检索他们的密码(他们只能将其重置为服务生成的密码),可以跳过步骤3和7。

像往常一样对用户密码进行盐加散列处理。当用户登录时,允许用户的密码(经过salting/hashing),但也允许用户按字面输入匹配。

这允许用户输入他们的秘密密码,但也允许他们输入他们的咸/散列版本的密码,这是某人将从数据库读取的密码。

基本上,让加盐/散列的密码也是一个“明文”密码。