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

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

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

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

Bounty的其他信息

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

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

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

谢谢大家

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

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

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


当前回答

我以实现多因素身份验证系统为生,所以对我来说,很自然地认为可以重置或重构密码,同时暂时少使用一个因素来验证用户,仅用于重置/重新创建工作流。特别是使用otp(一次性密码)作为一些额外的因素,如果建议的工作流的时间窗口很短,则可以降低很大程度的风险。我们为智能手机(大多数用户已经随身携带了一整天)实现了软件OTP生成器,并取得了巨大的成功。在对商业插头的抱怨出现之前,我想说的是,当密码不是用于验证用户身份的唯一因素时,我们可以降低密码易于检索或重置的固有风险。我承认,在网站场景之间的密码重用情况仍然不太好,因为用户会坚持拥有原始密码,因为他/她也想打开其他网站,但你可以尝试以最安全的方式(htpps和谨慎的html外观)提供重建的密码。

其他回答

用户是否真的需要恢复(例如被告知)他们忘记的密码是什么,或者他们只是需要能够进入系统?如果他们真正想要的是登录密码,为什么不设置一个程序,简单地将旧密码(不管是什么)更改为支持人员可以提供给丢失密码的人的新密码?

我曾经使用过这样的系统。支持人员无法知道当前密码是什么,但可以将其重置为新值。当然,所有这些重置都应该记录在某个地方,最好的做法是生成一封电子邮件给用户,告诉他密码已被重置。

另一种可能是使用两个同时的密码来访问一个帐户。一个是用户管理的“正常”密码,另一个就像一个骨架/主密钥,只有支持人员知道,对所有用户都是一样的。这样,当用户有问题时,技术支持人员可以用万能钥匙登录到帐户,并帮助用户更改密码。不用说,所有使用主密钥的登录都应该由系统记录。作为一种额外的措施,无论何时使用主密钥,您都可以验证支持人员凭据。

- edit -回应关于没有主密钥的评论:我同意这是不好的,就像我认为允许用户以外的任何人访问用户的帐户是不好的一样。如果你看一下这个问题,整个前提是客户要求一个高度妥协的安全环境。

万能钥匙不需要像乍看之下那么糟糕。我曾在一家国防工厂工作,他们认为主机操作员在某些场合需要有“特殊访问权限”。他们只是把特殊的密码放在一个密封的信封里,并把它贴在操作员的桌子上。要使用密码(接线员不知道),他必须打开信封。每次换班时,值班员的一项工作就是查看信封是否被打开,如果打开了,立即(由其他部门)更改密码,新密码放入新信封,然后重新开始这个过程。操作员将被问及他为什么打开它,这一事件将被记录在案。

虽然这不是我设计的程序,但它确实有效,并提供了良好的问责制。每件事都被记录和审查过,加上所有的操作员都有国防部的秘密许可我们从未有过任何滥用。

由于审查和监督,所有操作员都知道,如果他们滥用打开信封的特权,他们将立即被解雇,并可能受到刑事起诉。

所以我想真正的答案是,如果一个人想把事情做好,就雇佣他们可以信任的人,进行背景调查,并行使适当的管理监督和问责制。

但话说回来,如果这个可怜的家伙的客户有良好的管理,他们就不会在第一时间要求这样一个安全折衷的解决方案,不是吗?

密码遗失/忘记处理:

没有人能够恢复密码。

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

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

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

我以实现多因素身份验证系统为生,所以对我来说,很自然地认为可以重置或重构密码,同时暂时少使用一个因素来验证用户,仅用于重置/重新创建工作流。特别是使用otp(一次性密码)作为一些额外的因素,如果建议的工作流的时间窗口很短,则可以降低很大程度的风险。我们为智能手机(大多数用户已经随身携带了一整天)实现了软件OTP生成器,并取得了巨大的成功。在对商业插头的抱怨出现之前,我想说的是,当密码不是用于验证用户身份的唯一因素时,我们可以降低密码易于检索或重置的固有风险。我承认,在网站场景之间的密码重用情况仍然不太好,因为用户会坚持拥有原始密码,因为他/她也想打开其他网站,但你可以尝试以最安全的方式(htpps和谨慎的html外观)提供重建的密码。

将用户安全问题的答案作为加密密钥的一部分,并且不要将安全问题答案存储为纯文本(而是散列)

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

步骤如下:

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

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