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

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

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

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

Bounty的其他信息

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

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

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

谢谢大家

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

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

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


当前回答

根据我对这个问题所作的评论: 有一点几乎被所有人都忽略了。我最初的反应和@Michael Brooks非常相似,直到我意识到,像@stefanw一样,这里的问题是破坏了需求,但事实就是这样。 但后来,我突然想到,事实可能并非如此!这里缺少的一点是应用程序资产的不言而喻的价值。简单地说,对于一个低价值的系统,一个完全安全的身份验证机制,包括所有涉及的过程,将是过度的,是错误的安全选择。 显然,对于银行来说,“最佳实践”是必须的,在道德上不可能违反CWE-257。但是很容易想到低价值的系统是不值得的(但仍然需要一个简单的密码)。

重要的是要记住,真正的安全专业知识是找到适当的权衡,而不是教条地宣扬任何人都可以在网上阅读的“最佳实践”。

因此,我建议另一种解决方案: 这取决于系统的价值,并且只有当系统是适当的低价值,没有“昂贵”资产(包括身份本身),并且存在有效的业务需求,使得适当的处理不可能(或足够困难/昂贵),并且客户知道所有的警告…… 那么,简单地允许可逆加密是合适的,没有特殊的障碍。 我只是说根本不需要加密,因为它实现起来非常简单/便宜(甚至考虑到可通过的密钥管理),并且它确实提供了一些保护(超过实现它的成本)。此外,值得考虑的是如何向用户提供原始密码,无论是通过电子邮件,还是显示在屏幕上,等等。 由于这里的假设是被盗密码的值(甚至是总值)非常低,因此这些解决方案中的任何一种都可能有效。


因为有一个活跃的讨论正在进行,实际上是几个活跃的讨论,在不同的帖子和单独的评论线程中,我将补充一些澄清,并回应在这里其他地方提出的一些非常好的观点。

首先,我认为这里的每个人都很清楚,允许用户的原始密码被检索,是不好的做法,通常不是一个好主意。这一点毫无争议。 此外,我要强调的是,在许多情况下,不,大多数情况下,这是错误的,甚至是肮脏的,肮脏的,丑陋的。

然而,问题的关键在于原则,是否存在任何情况下可能没有必要禁止这种行为,如果有,如何以最适合这种情况的正确方式禁止这种行为。

现在,正如@Thomas, @sfussenegger和其他几个人提到的,回答这个问题的唯一正确方法是对任何给定的(或假设的)情况进行彻底的风险分析,以了解什么是利害攸关的,值得保护的程度,以及有哪些其他缓解措施可以提供保护。 不,这不是一个流行语,这是一个基本的,最重要的工具,一个真实的安全专业人士。最佳实践在一定程度上是好的(通常是为没有经验的人和黑客提供的指导),在这之后,经过深思熟虑的风险分析就会起作用。

你知道,这很有趣——我一直认为自己是一个安全狂热者,但不知怎的,我却站在那些所谓的“安全专家”的对立面……好吧,事实是——因为我是一个狂热分子,也是一个现实生活中的安全专家——我不相信在没有非常重要的风险分析的情况下宣扬“最佳实践”教条(或CWEs)。 “当心那些安全狂热者,他们很快就会使出浑身解数,而不知道他们要防御的实际问题是什么。更多的安全并不一定等于更好的安全。” 风险分析和真正的安全狂热者会指出一个更聪明的、基于价值/风险的权衡,基于风险、潜在损失、可能的威胁、互补的缓解措施等。任何“安全专家”不能指出健全的风险分析作为他们的建议的基础,或支持逻辑权衡,而是宁愿在不了解如何执行风险分析的情况下抛出教条和CWEs,只是安全黑客,他们的专业知识不值他们打印的厕纸。

事实上,这就是我们如何得到荒谬的机场安检。

但在我们讨论这种情况下的适当权衡之前,让我们看看明显的风险(明显的,因为我们没有这种情况的所有背景信息,我们都在假设——因为问题是假设的情况会有什么……) 让我们假设一个LOW-VALUE系统,但它不是那么微不足道,以至于它是公共访问-系统所有者想要防止随意的模仿,然而“高”安全性并不像易用性那么重要。(是的,这是一个合理的权衡,接受任何精通脚本的孩子都可以入侵网站的风险……等等,APT现在不是很流行吗?) 举个例子,假设我正在为一个大型家庭聚会安排一个简单的地点,让每个人都能头脑风暴一下今年我们想去哪里露营。我不太担心某个匿名黑客,甚至不太担心弗雷德表哥再三建议我回到旺塔纳马纳比奇利奇湖,因为我担心厄尔玛姨妈在需要登录时无法登录。厄玛姨妈是一位核物理学家,她不太擅长记密码,甚至根本不会使用电脑……所以我想为她消除所有的摩擦。再说一次,我不担心黑客,我只是不想犯错误登录的愚蠢错误-我想知道谁来了,他们想要什么。

无论如何。 那么,如果我们对称加密密码,而不是使用单向哈希,我们的主要风险是什么?

冒充用户?不,我已经接受了这个风险,没什么意思。 邪恶的管理员吗?好吧,也许……但同样,我不关心是否有人可以模仿另一个用户,内部或没有…不管怎样,一个恶意的管理员无论如何都会得到你的密码——如果你的管理员坏了,它的游戏就结束了。 另一个被提出的问题是,标识实际上是在几个系统之间共享的。啊!这是一个非常有趣的风险,需要仔细观察。 让我先声明一下,这并不是共享的实际身份,而是证明或认证凭证。好吧,因为共享密码将有效地允许我进入另一个系统(例如,我的银行帐户或gmail),这实际上是相同的身份,所以这只是语义…但事实并非如此。在这种情况下,标识由每个系统单独管理(尽管可能存在第三方标识系统,例如OAuth—但它仍然与该系统中的标识分离—稍后将对此进行详细介绍)。 因此,这里的核心风险点是,用户将自愿将他的(相同的)密码输入到几个不同的系统-现在,我(管理员)或我的网站的任何其他黑客将有权限访问Erma阿姨的核导弹网站的密码。

嗯。

你觉得这里有什么不对劲吗?

它应该。

让我们从保护核导弹系统不是我的责任开始,我只是在为我的家人建造一个该死的家庭郊游地点。那么是谁的责任呢?嗯……那么核导弹系统呢?咄。 其次,如果我想窃取某人的密码(一个在安全网站和不太安全的网站之间反复使用相同密码的人)——我为什么要费心入侵你的网站呢?或者与对称加密作斗争?我可以建一个自己的简单网站,让用户注册来接收他们想要的任何重要新闻…噗噗,我“偷”了他们的密码。

是的,用户教育总是回来咬我们的屁股,不是吗? 对此你无能为力…即使你要在你的网站上散列他们的密码,并做TSA能想到的所有事情,如果他们继续乱把密码贴在他们碰到的每个网站上,你也不会一分不清楚地为他们的密码添加保护。不要费心去尝试。

换句话说,你不拥有他们的密码,所以不要试图表现得好像你拥有一样。

所以,我亲爱的安全专家们,就像一位老妇人曾经问Wendy's的那样,“风险在哪里?”

针对以上提出的一些问题,再提出几点意见:

CWE不是法律、法规,甚至不是标准。它是一个共同弱点的集合,即“最佳实践”的反面。 共享身份的问题是一个实际的问题,但这里的反对者误解了(或歪曲了)。这是一个共享身份本身的问题(!),而不是在低价值系统上破解密码。如果您在低值系统和高值系统之间共享密码,那么问题已经存在了! 顺便说一下,前面的观点实际上是反对在这些低价值系统和高价值银行系统中使用OAuth之类的东西。 我知道这只是一个例子,但(可悲的是)FBI的系统并不是最安全的。不太像你家猫的博客服务器,但也没有超过一些更安全的银行。 加密密钥的分离知识或双重控制不仅仅发生在军事领域,事实上PCI-DSS现在要求基本上所有商家都这样做,所以它真的不再那么遥远了(如果价值证明它是合理的)。 对于那些抱怨这样的问题使开发人员职业看起来如此糟糕的人来说:正是这样的答案使安全职业看起来更加糟糕。同样,以业务为中心的风险分析是必需的,否则您将使自己毫无用处。除了犯错之外。 我想这就是为什么仅仅让一个普通的开发人员承担更多的安全责任并不是一个好主意,而没有训练他以不同的方式思考,并寻找正确的权衡。无意冒犯,对在座的各位,我完全赞成——但更多的训练是必要的。

唷。好长的帖子…… 但是回答你最初的问题,@Shane:

向客户解释正确的做事方式。 如果他还坚持,那就多解释,坚持,争辩。如果需要,可以发脾气。 向他解释商业风险。细节很好,图表更好,现场演示通常是最好的。 如果他仍然坚持,并且提出了有效的商业理由——是时候让你做一个判断了: 这个网站是低价值还是没有价值?这真的是一个有效的商业案例吗?对你来说够好了吗?您是否没有其他可以考虑的风险,这些风险会超过有效的商业原因?(当然,客户端不是恶意网站,但这是废话)。 如果是的话,请继续。花费精力、摩擦和损失使用(在这种假设的情况下)来设置必要的流程是不值得的。任何其他决定(同样,在这种情况下)都是糟糕的权衡。

所以,底线和一个实际的答案——用简单的对称算法加密它,用强acl保护加密密钥,最好是DPAPI或类似的东西,记录它并让客户端(足够高级的人做出决定)签字。

其他回答

密码遗失/忘记处理:

没有人能够恢复密码。

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

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

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

中途教习所怎么样?

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

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

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

抱歉,但只要你有办法破解他们的密码,就不可能是安全的。痛苦地抗争,如果你输了,CYA。

另一个你可能没有考虑到的选择是允许通过电子邮件进行操作。这有点麻烦,但我为一个客户端实现了这个功能,该客户端需要系统“外部”的用户来查看(只读)系统的某些部分。例如:

一旦用户注册,他们就拥有完全的访问权限(就像普通用户一样) 网站)。注册必须包括电子邮件。 如果需要数据或操作,而用户不需要 记住他们的密码,他们仍然可以通过 点击一个特殊的“给我发邮件以获得许可”按钮,就在常规的“提交”按钮旁边。 然后,请求以超链接发送到电子邮件,询问他们是否希望执行该操作。这类似于密码重置电子邮件链接,但它不是重置密码,而是执行一次性操作。 然后用户点击“Yes”,它确认应该显示数据,或者应该执行操作,显示数据等等。

正如你在评论中提到的,如果电子邮件被泄露,这将不起作用,但它确实解决了@joachim关于不想重置密码的评论。最终,他们将不得不使用密码重置,但他们可以在更方便的时候这样做,或者根据需要在管理员或朋友的帮助下这样做。

该解决方案的另一种方法是将操作请求发送给第三方可信管理员。这对于老年人、智障人士、非常年轻或其他困惑的用户来说效果最好。当然,这需要一个可信的管理员来支持这些人的行动。

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