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

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

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

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

Bounty的其他信息

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

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

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

谢谢大家

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

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

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


中途教习所怎么样?

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

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

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


您可以使用公钥加密密码+盐。对于登录,只需检查存储的值是否等于从用户输入+ salt计算的值。如果需要以明文形式恢复密码,则可以使用私钥手动或半自动地解密。私钥可以存储在其他地方,还可以对称加密(这将需要人工交互来解密密码)。

我认为这实际上有点类似于Windows恢复代理的工作方式。

密码被加密存储 人们无需解密为明文即可登录 密码可以恢复为明文,但必须使用私钥,私钥可以存储在系统之外(如果您愿意,可以存储在银行保险箱中)。


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


我认为你真正应该问自己的问题是:“我怎样才能更好地说服别人?”


不要放弃。你可以用来说服你的客户的武器是不可否认性。如果你可以通过任何机制重建用户密码,你就给了他们的客户一个合法的不可抵赖机制,他们可以拒绝任何依赖于该密码的交易,因为供应商无法证明他们没有重建密码并自己完成交易。如果密码被正确地存储为摘要而不是密文,这是不可能的,因此最终客户要么自己执行交易,要么违反了他对密码的注意义务。无论哪种情况,责任完全落在他身上。我处理过的案件中,金额高达数亿美元。不是你想出错的事。


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


Michael Brooks一直对cwe257直言不讳——事实上,无论您使用什么方法,您(管理员)仍然可以恢复密码。那么下面这些选项怎么样:

使用其他人的公钥(一些外部授权机构)加密密码。这样,您就不能亲自重建密码,用户必须去外部权威机构要求恢复他们的密码。 使用从第二个口令短语生成的密钥加密密码。在客户端进行加密,绝不将其明文传输到服务器。然后,为了恢复,通过从他们的输入重新生成密钥,再次在客户端解密。不可否认,这种方法基本上是使用第二个密码,但您总是可以告诉他们把它写下来,或者使用旧的安全问题方法。

我认为1。是更好的选择,因为它允许您在客户的公司内指定某人持有私钥。确保他们自己生成密钥,并将其与指示一起存储在保险箱等。您甚至可以通过选择只加密密码并向内部第三方提供密码中的某些字符来增加安全性,这样他们就必须破解密码才能猜测它。将这些字符提供给用户,他们可能会记住它是什么!


密码遗失/忘记处理:

没有人能够恢复密码。

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

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

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


想象一下,有人委托建造一座大型建筑——比方说一座酒吧——下面的对话发生了:

建筑师:对于这种规模和容量的建筑,这里、这里和这里都需要安全出口。 客户:不,那太复杂了,维护起来也太贵了,我不想要任何侧门或后门。 建筑师:先生,消防出口不是可有可无的,这是城市消防法规规定的。 客户:我付你钱不是让你争辩的。照我说的做。

建筑师是否会问如何在没有安全出口的情况下合乎道德地建造这栋建筑?

在建筑和工程行业,对话很可能是这样结束的:

建筑师:这栋建筑没有安全出口是建不起来的。你可以去找其他有执照的专业人士,他会告诉你同样的事情。我现在要走了;等你准备好合作了再打给我。

计算机编程可能不是一个有执照的职业,但人们似乎经常想知道为什么我们的职业没有得到与土木或机械工程师同样的尊重——好吧,不用再看了。这些职业,当遇到垃圾(或完全危险的)要求时,会简单地拒绝。他们知道这不是一个借口,“嗯,我尽力了,但他坚持,我必须按他说的做。”他们可能会因此被吊销执照。

我不知道您或您的客户是否是任何上市公司的一部分,但以任何可恢复的形式存储密码都会导致您无法通过几种不同类型的安全审计。问题不在于某些进入数据库的“黑客”要恢复密码有多难。绝大多数安全威胁来自内部。你需要防止的是一些心怀不满的员工拿走所有的密码,然后把它们卖给出价最高的人。使用非对称加密和将私钥存储在单独的数据库中绝对不能防止这种情况;总有人可以访问私人数据库,这是一个严重的安全风险。

没有道德或负责任的方式以可恢复的形式存储密码。时期。


根据我对这个问题所作的评论: 有一点几乎被所有人都忽略了。我最初的反应和@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或类似的东西,记录它并让客户端(足够高级的人做出决定)签字。


出于道德考虑,您不能为以后的明文检索存储密码。就这么简单。就连乔恩·斯基特(Jon Skeet)也不能在道德上存储密码以供以后的明文检索。如果您的用户可以以某种方式以纯文本检索密码,那么黑客也可能会在您的代码中发现安全漏洞。这不仅仅是一个用户的密码被泄露,而是所有用户的密码都被泄露了。

如果你的客户对此有意见,告诉他们可恢复的存储密码是违法的。无论如何,在英国,《1998年数据保护法》(特别是附表1,第II部分,第9段)要求数据控制者使用适当的技术措施来保证个人数据的安全,除其他外,考虑到如果数据被泄露可能造成的损害——这对于在不同网站之间共享密码的用户来说可能是相当大的。如果他们仍然无法理解这是一个问题,给他们举一些现实世界的例子,比如下面这个。

允许用户恢复登录的最简单方法是通过电子邮件向他们发送一个一次性链接,该链接可以自动登录,并直接将他们带到一个可以选择新密码的页面。创建一个原型,并展示给他们看。

以下是我写的几篇关于这个主题的博客文章:

http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/ http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

更新:我们现在开始看到针对未能正确保护用户密码的公司的诉讼和起诉。例子:领英(LinkedIn)遭到500万美元的集体诉讼;索尼因PlayStation数据泄露被罚款25万英镑。如果我没记错的话,LinkedIn实际上对用户的密码进行了加密,但它使用的加密技术太弱了,不太有效。


在注册时,在加密和丢失密码之前,通过电子邮件发送明文密码怎么样?我见过很多网站这样做,从用户的电子邮件中获取密码比把密码留在你的服务器/comp上更安全。


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


看完这部分后:

在下面的注释中,我指出了这一点 网站主要面向 老年人,智障人士,或者非常 年轻会让人困惑 当他们被要求表演 安全密码恢复程序。 虽然我们觉得这很简单 在这些情况下,一些用户需要的是平淡无奇 任何一个的额外帮助 服务技术人员帮助他们进入 系统或通过电子邮件发送/显示 直接给他们。 在这样的系统中,流失率 从这些人口统计数据来看,可能会步履蹒跚 如果用户不是 考虑到这种程度的准入援助, 所以请回答这样的设置 脑海中。

我想知道这些要求中是否有要求可检索的密码系统。例如: 梅布尔阿姨打电话来说:“你的网络程序坏了,我不知道我的密码。”“好的,”客服无人机说,“让我检查一些细节,然后我会给你一个新密码。当你下次登录时,它会询问你是想保留这个密码,还是把它改成更容易记住的密码。”

然后系统设置为知道密码重置发生时,并显示“您想保留新密码还是选择一个新密码”的消息。

对于不太懂电脑的人来说,这比被告知旧密码更糟糕吗?虽然客户服务人员可能会搞恶作剧,但数据库本身在被破坏时要安全得多。

在我的建议中评论不好的地方,我会提出一个解决方案,实际上是你最初想要的。


在回答这个问题时,已经有很多关于用户安全问题的讨论,但我想再提一下好处。到目前为止,我还没有看到在系统中存储可恢复密码的合法好处。考虑一下:

通过电子邮件发送密码对用户有好处吗?不。他们从一次性密码重置链接中获益更多,这有望让他们选择一个他们能记住的密码。 在屏幕上显示密码对用户有好处吗?不,原因和上面一样;他们应该选择一个新密码。 让技术支持人员告诉用户密码对用户有好处吗?没有;同样,如果支持人员认为用户的密码请求已经过正确验证,那么为用户提供新密码和更改密码的机会对用户更有利。此外,电话支持比自动密码重置更昂贵,所以该公司也没有受益。

从可恢复的密码中获益的似乎只有那些怀有恶意的人,或者那些需要第三方密码交换的糟糕api的支持者(请永远不要使用这些api !)也许你可以通过如实向客户陈述公司存储可恢复密码没有获得任何好处,只会承担责任来赢得争论。

从这类请求的字里行间,您会发现客户端可能根本不理解,甚至根本不关心密码是如何管理的。他们真正想要的是一个对用户来说并不难的认证系统。所以,除了告诉他们其实他们并不想要可恢复的密码之外,你还应该为他们提供一些让认证过程不那么痛苦的方法,尤其是如果你不需要像银行这样的高安全级别:

允许用户使用他们的电子邮件地址作为用户名。我见过无数用户忘记自己的用户名,但很少有人忘记自己的电子邮件地址。 提供OpenID,让第三方支付用户遗忘的成本。 放宽密码限制。我敢肯定,当一些网站因为“不能使用特殊字符”或“您的密码太长”或“您的密码必须以字母开头”之类无用的要求而不允许您使用首选密码时,我们都非常恼火。此外,如果易用性比密码强度更重要,您甚至可以通过允许更短的密码或不要求混合字符类来放松不愚蠢的要求。随着限制的放松,用户将更有可能使用他们不会忘记的密码。 不要让密码过期。 允许用户重新使用旧密码。 允许用户选择自己的密码重置问题。

但如果你出于某种原因(请告诉我们原因)真的,真的,真的需要一个可恢复的密码,你可以通过给他们一个非密码认证系统来保护用户,以免他们的其他在线帐户受到潜在的威胁。因为人们已经熟悉用户名/密码系统,这是一个行之有效的解决方案,这将是最后的手段,但肯定有很多创造性的替代密码的方法:

让用户选择一个数字引脚,最好不要是4位,最好只在防止暴力尝试的情况下。 让用户选择一个只有他们自己知道的简短答案的问题,这个问题永远不会改变,他们会一直记住,而且他们不介意其他人发现。 让用户输入一个用户名,然后画一个容易记住的形状,并有足够的排列来防止猜测(看看这张G1如何解锁手机的漂亮照片)。 对于一个儿童网站,你可以根据用户名(有点像身份)自动生成一个模糊的生物,并要求用户给这个生物一个秘密的名字。然后他们会被提示输入该生物的秘密名称来登录。


保护凭证不是一个二进制操作:安全/不安全。安全是关于风险评估的,是在连续统上衡量的。安全狂热分子讨厌这样想,但丑陋的事实是,没有什么是完全安全的。具有严格的密码要求、DNA样本和视网膜扫描的散列密码更安全,但以开发和用户体验为代价。明文密码的安全性要低得多,但实现起来成本更低(但应该避免使用)。在一天结束的时候,它归结为一个漏洞的成本/收益分析。您可以根据所保护的数据的值及其时间值来实现安全性。

一个人的密码泄露到野外的代价是什么?给定系统中模拟的成本是多少?对于联邦调查局的电脑来说,代价可能是巨大的。对于Bob的一次性5页网站来说,成本可以忽略不计。专业人员为客户提供选项,并在涉及到安全性时列出任何实现的优势和风险。如果客户要求的某些东西可能会使他们处于风险之中,因为他们未能遵守行业标准,那么情况就会加倍。如果客户明确要求双向加密,我将确保您记录您的反对意见,但这不应该阻止您以您所知道的最佳方式实现。说到底,这是客户的钱。是的,你应该推动使用单向哈希,但说这绝对是唯一的选择,其他任何东西都是不道德的,这完全是无稽之谈。

如果您使用双向加密存储密码,安全性就归结于密钥管理。Windows提供了一些机制来限制对管理帐户和密码的证书、私钥的访问。如果你在其他平台上托管,你需要看看你在那些平台上有什么可用的选项。正如其他人建议的那样,您可以使用非对称加密。

据我所知,没有法律(包括英国的数据保护法案)明确规定密码必须使用单向哈希存储。这些法律中唯一的要求就是采取合理的措施保证安全。如果对数据库的访问受到限制,那么在这种限制下,即使是明文密码也可以合法地使用。

然而,这确实揭示了另一个方面:法律优先权。如果法律优先级建议您必须根据构建系统的行业使用单向散列,那么情况就完全不同了。这是你用来说服你的客户的弹药。除此之外,最好的建议是提供合理的风险评估,记录您的反对意见,并以您可以满足客户要求的最安全的方式实施系统。


用另一种方法或角度来解决这个问题怎么样?询问为什么密码必须是明文:如果是为了让用户可以检索密码,那么严格地说,您实际上不需要检索他们设置的密码(他们不记得它是什么),您需要能够为他们提供一个他们可以使用的密码。

想想看:如果用户需要检索密码,那是因为他们忘记了密码。在这种情况下,新密码和旧密码一样有效。但是,目前使用的常用密码重置机制的缺点之一是,在重置操作中生成的密码通常是一堆随机字符,因此用户很难正确地输入它们,除非他们复制-粘贴。对于不太精明的电脑用户来说,这可能是个问题。

解决这个问题的一种方法是提供自动生成的密码,这些密码或多或少是自然语言文本。虽然自然语言字符串可能没有相同长度的随机字符字符串的熵,但没有人说你的自动生成的密码只需要8个(或10个或12个)字符。通过将几个随机单词串在一起来获得一个高熵自动生成的密码短语(在它们之间留出一个空间,以便能够阅读的人仍然可以识别和键入它们)。6个不同长度的随机单词可能比10个随机字符更容易正确输入,而且它们的熵也更高。例如,从大写字母、小写字母、数字和10个标点符号(总共72个有效符号)中随机抽取的10个字符的密码的熵值为61.7比特。使用7776个单词的字典(如Diceware所使用的),可以随机选择6个单词的密码短语,密码短语的熵将为77.4位。更多信息请参见Diceware FAQ。

一个约77比特熵的密码短语:“承认散文耀斑表敏锐的天赋” 一个约有74位熵的密码:“K:&$R^tt~qkD”

我知道我更喜欢输入短语,使用复制-粘贴,短语也不会比密码更容易使用,所以没有损失。当然,如果你的网站(或任何受保护的资产)不需要77位熵来自动生成密码短语,那就生成更少的单词(我相信你的用户会喜欢的)。

我理解有人的观点,有些受密码保护的资产实际上没有很高的价值,所以密码被泄露可能不是世界末日。例如,我可能不会在意我在各种网站上使用的80%的密码被破解:唯一可能发生的事情就是有人用我的名字发垃圾邮件或发帖。那样不太好,但他们又不会侵入我的银行账户。然而,鉴于许多人在他们的论坛网站上使用的密码与他们的银行账户密码(可能还有国家安全数据库密码)相同,我认为最好将这些“低价值”密码作为不可恢复的密码来处理。


如果您不能拒绝存储可恢复密码的要求,那么您的反对论点如何?

我们可以正确地散列密码并为用户建立一个重置机制,或者我们可以从系统中删除所有个人身份信息。您可以使用电子邮件地址来设置用户偏好,但仅此而已。使用cookie可以自动提取未来访问的偏好,并在一段合理的时间后丢弃数据。

密码策略中经常被忽视的一个选项是是否真的需要密码。如果你的密码策略所做的唯一一件事就是导致客户服务电话,也许你可以摆脱它。


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


我也有同样的问题。同样的,我总是认为有人入侵我的系统不是“如果”的问题,而是“什么时候”的问题。

所以,当我必须做一个网站,需要存储一个可恢复的机密信息,如信用卡或密码,我所做的是:

使用openssl_encrypt(字符串$data,字符串$method,字符串$password)进行加密 PHP手册。 数据参数: 敏感资料(例如用户密码) 如果需要,序列化,例如,如果信息是一个数据数组,如多个敏感信息 密码arg:使用一个只有用户知道的信息,比如: 用户牌照 社会保险号码 用户电话 用户母名 在注册时通过电子邮件和/或短信发送的随机字符串 方法参数: 选择一种密码方法,如“aes-256-cbc” 永远不要将password参数中使用的信息存储在数据库(或系统中的任何地方)

当需要检索此数据时,只需使用“openssl_decrypt()”函数并向用户询问答案。例如:“要收到你的密码,请回答这个问题:你的手机号码是多少?”

PS 1:永远不要将存储在数据库中的数据用作密码。如果您需要存储用户的手机号码,那么永远不要使用此信息来编码数据。总是使用只有用户知道的信息,或者非亲属很难知道的信息。

PS 2:信用卡信息,比如“一键购买”,我所做的就是使用登录密码。这个密码在数据库中哈希(sha1, md5等),但在登录时,我将明文密码存储在会话或非持久性(即在内存中)安全cookie中。这个简单的密码永远不会留在数据库中,实际上它总是留在内存中,在节结束时销毁。当用户点击“一键购买”按钮时,系统使用此密码。如果用户使用facebook, twitter等服务登录,那么我会在购买时再次提示密码(好吧,这不是完全的“点击”),然后使用用户曾经登录的服务的一些数据(如facebook id)。


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

步骤如下:

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

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


刚刚看到这个有趣而热烈的讨论。 最让我惊讶的是,很少有人关注以下基本问题:

Q1。用户坚持访问纯文本存储的密码的实际原因是什么?为什么它这么有价值?

用户年龄大或小的信息并不能真正回答这个问题。但是,如果没有正确理解客户的关注点,如何做出业务决策呢?

为什么这很重要呢? 因为如果客户要求的真正原因是系统难以使用,那么解决具体原因可能会解决实际问题?

由于我没有这些信息,也无法与这些客户交谈,我只能猜测:这是关于可用性的,见上文。

我看到的另一个问题是:

Q2。如果用户一开始就不记得密码,为什么旧密码很重要?

这是可能的答案。 如果你有一只叫“miaumiau”的猫,用她的名字作为密码,但忘记了,你是更愿意被提醒它是什么,还是更愿意被发送像“#zy*RW(ew)”这样的信息?

另一个可能的原因是,用户认为想出一个新密码是一项艰巨的工作!所以,把旧密码发送回去给她一种错觉,让她不用再去做那件痛苦的工作了。

我只是想知道原因。但无论原因是什么,必须解决的是原因而不是原因。

作为用户,我希望事情简单!我不想努力工作!

如果我登录一个新闻网站看报纸,我想输入1111作为密码,然后就可以通过了!!

我知道这是不安全的,但我在乎别人访问我的“帐户”吗?是的,他也会看新闻!

网站是否存储我的“私人”信息? 我今天读的新闻? 那就是网站的问题,不是我的! 站点是否向已验证的用户显示私人信息? 那就先别表现出来!

这只是为了说明用户对问题的态度。

总之,我不认为这是一个如何“安全地”存储纯文本密码的问题(我们知道这是不可能的),而是如何解决客户实际关心的问题。


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

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

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


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

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

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

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


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

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

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