随着我继续构建越来越多的网站和Web应用程序,我经常被要求以一种方式存储用户的密码,如果/当用户遇到问题时可以检索它们(要么通过电子邮件发送忘记的密码链接,请通过当我能够对抗这种做法时,我会做很多"额外"编程,以便在不存储实际密码的情况下进行密码重置和管理协助.
当我无法抗争(或无法获胜)时,我总是以某种方式对密码进行编码,以至于它至少不会以明文形式存储在数据库中 - 尽管我知道如果我的数据库被黑客攻击破坏密码的罪魁祸首并不需要太多,所以这让我感到不舒服.
在一个完美的世界里,人们经常更新密码,而不是在许多不同的网站上复制密码 - 不幸的是,我知道许多人拥有相同的工作/家庭/电子邮件/银行密码,甚至在需要帮助时自由地给我.如果我的数据库安全程序由于某种原因失败,我不想成为他们的财务终结负责人.
在道德和道德上,我觉得有责任保护一些用户的生活,即使他们以较少的尊重对待他们.我确信有许多途径可以用来腌制哈希和不同的编码选项,但是当你必须存储它们时,是否有一个"最佳实践"？在几乎所有情况下,我都使用PHP和MySQL,如果这对我应该处理细节的方式有任何不同.
附加信息Bounty
我想澄清一点,我知道这不是你想要做的事情,在大多数情况下拒绝这样做是最好的.但是,我并不是在寻找关于采取这种方法的优点的演讲我正在寻找采取这种方法时采取的最佳步骤.
在下面的一个注释中,我指出,当人们被要求执行安全的密码恢复程序时,主要针对老年人,智障人士或非常年轻人的网站可能会让人感到困惑.虽然在这些情况下我们可能会发现它简单而平凡,但有些用户需要额外的帮助,要么让服务技术人员帮助他们进入系统,要么将其直接通过电子邮件发送/显示给他们.
在这样的系统中,如果用户没有获得这种级别的访问协助,那么来自这些人口统计数据的流失率可能会阻碍应用程序,因此请记住这样的设置.
谢谢大家
这是一个有趣的问题,有很多争论,我很喜欢它.最后,我选择了一个保留密码安全性的答案(我不必保留纯文本或可恢复的密码),但也使我指定的用户群可以登录到系统而没有我从中找到的主要缺点正常的密码恢复.
由于不同的原因,我一直有大约5个答案,但我必须选择最好的答案 - 所有其他答案都是+1.感谢大家!
此外,感谢Stack社区中的每个人都投票赞成这个问题和/或将其标记为最喜欢的.我以100票赞成票作为赞美,并希望这次讨论能够帮助其他与我有同样关切的人.
1> Michael Burr..：
如何针对这个问题采取另一种方法或角度？问为什么密码必须是明文的:如果用户可以检索密码,那么严格来说你不需要检索他们设置的密码(他们不记得它是什么),你需要能够为他们提供他们可以使用的密码.
想一想:如果用户需要检索密码,那是因为他们忘记了密码.在这种情况下,新密码与旧密码一样好.但是,今天使用的常见密码重置机制的缺点之一是在重置操作中生成的密码通常是一堆随机字符,因此用户很难简单地键入,除非他们复制 - n-糊.对于不那么精明的计算机用户来说,这可能是个问题.
解决该问题的一种方法是提供或多或少自然语言文本的自动生成的密码.虽然自然语言字符串可能没有一串相同长度的随机字符所具有的熵,但没有任何内容表明您的自动生成的密码只需要8个(或10或12个)字符.通过将几个随机单词串在一起来获取高熵自动生成的密码短语(在它们之间留一个空格,因此任何可以阅读的人都可以识别并输入它们).不同长度的六个随机单词可能比10个随机字符更容易正确且有信心地键入,并且它们也可以具有更高的熵.例如,从大写,小写,数字和10个标点符号(总共72个有效符号)中随机抽取的10个字符密码的熵将具有61.7比特的熵.使用7776个单词的字典(如Diceware使用的那样)可以随机选择六个字密码,密码短语的熵为77.4比特.有关详细信息,请参阅Diceware FAQ.
一个约77位熵的密码:"承认散文耀斑表的敏锐天赋"
一个大约74位熵的密码:"K:&$ R ^ tt~qkD"
我知道我更喜欢输入短语,并且使用copy-n-paste,这个短语也很容易使用密码,所以没有丢失.当然,如果您的网站(或任何受保护资产)对于自动生成的密码短语不需要77位熵,则生成较少的单词(我确信您的用户会欣赏).
我理解存在密码保护资产的论点,这些资产确实没有很高的价值,因此破解密码可能不是世界末日.例如,我可能不会关心我在各种网站上使用的80%的密码是否被破坏:所有可能发生的事情都是有人发送垃圾邮件或在我的名下发帖一段时间.那不会很好,但不像他们会侵入我的银行账户.但是,鉴于许多人使用与他们的银行账户(可能是国家安全数据库)相同的密码用于他们的网站论坛网站,我认为最好将这些"低价值"密码处理为非-recoverable.
你也可以做一个完整的句子,例如<形容词> <名词>是<动词> <副词>.绿猫疯狂地跳跃.有类别的列表.每个选项有1024个,你有40位熵.
密码短语+1,目前似乎提供密码强度和用户召回的最佳平衡.
"考虑一下 - 如果用户需要检索密码,那是因为他们忘记了密码" - 不一定是真的!我经常想得到我的密码,因为我在笔记本电脑上,我知道我的机器在家里存有我的密码,或者它写在一个安全的地方,我不想通过发布一个新密码来打破它.
+1用于将密码重用视为避免密码重用的关键问题
[新IT安全SE网站上得分最高的问题](http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase)处理这种熵计算的有效性.(从技术上讲,它处理@Pieter链接的xkcd.)
(+1 + Bounty) - @Michael Burr,我觉得这个解决方案最适合提出的问题以及赏金信息.密码短语将允许我指定用户群最简单的登录站点的方法来从系统中休息密码和电子邮件系统.我会在必要时使用类似方法(可能是一个单词密码)的电话支持混合使用.好答案.
@AwalGarg:这不是密码熵的工作原理.问题中的熵计算已经通过密码的生成方式来衡量熵,而不是攻击者如何尝试猜测密码.知道密码结构的攻击者仍然需要77位熵才能通过.
这是我感到愚蠢的情况之一,因为我没有想到它.很好的解决方案和很好的解释!
@ Codefun64即使您知道所有密码都是6个字典单词,这仍然相当于一个包含数万个字符的语言中的6个字符的密码(有数十万,甚至可能是数百万个"单词",但是据推测,它只会选择相对常见的单词,其中仍有数万可供选择).有趣的字典攻击.
@ Codefun64但是这个答案不是*谈论密码中常用的单词,而不是说用户选择它们而只选择<= 3.Quoth,"解决这个问题的另一种方法是提供或多或少自然语言文本的自动生成的密码":即生成*一个完整的语法英语句子并让用户记住(如果他们忘了它 - 很好,生成一个新的).例如,太多的密码不太可能使用"急性"这个词(如答案中的例子),但它不是过时的或任何东西.
只是要说明没有理由将自己限制在7776(6⁵)字典中.很容易想出一个大约2 ^ 15个单词的字典,并且只用5个单词就可以获得75位的熵.
2> Aaronaught..：
想象一下,有人委托建造了一座大型建筑 - 比如一个酒吧 - 并且会发生以下对话:
建筑师: 对于这样大小和容量的建筑,这里,这里和这里都需要消防通道.
客户: 不,这太复杂,维护成本太高,我不想要任何侧门或后门.
建筑师: 先生,消防通道不是可选的,根据城市的消防法规要求.
客户: 我不付钱给你辩论.做我问的事.
那么建筑师是否会在没有消防通道的情况下询问如何在道德上建造这座建筑？
在建筑和工程行业,谈话最有可能像这样结束:
建筑师: 这栋建筑不能在没有消防通道的情况下建造.你可以去任何其他有执照的专业人士,他会告诉你同样的事情.现在我要走了; 当你准备合作时,给我回电话.
计算机编程可能不是一个许可的专业,但人们似乎常常想知道为什么我们的专业不会得到与民用或机械工程师相同的尊重 - 好吧,不要再看了.那些职业,当交给垃圾(或完全危险)的要求时,将简单地拒绝.他们知道这不是一个借口说,"好吧,我尽了最大努力,但他坚持说,我必须按照他说的去做." 他们可能因为这个借口而失去执照.
我不知道您或您的客户是否属于任何上市公司,但以任何可恢复的形式存储密码将导致您失败几种不同类型的安全审核.问题不在于有些"黑客"访问您的数据库以恢复密码的难度. 绝大多数安全威胁都是内部威胁. 您需要防范的是一些心怀不满的员工走出所有密码并将其出售给出价最高者.使用非对称加密并将私钥存储在单独的数据库中绝对没有什么可以阻止这种情况; 总会有人访问私人数据库,这是一个严重的安全风险.
以可恢复的形式存储密码没有道德或负责任的方式.期.
@Aaronaught - 我认为这是一个公平有效的观点,但让我在你身上扭转这一点.您正在为公司作为员工开展项目,而您的老板说"这是我们系统的要求"(无论出于何种原因).你是否离开了充满义愤的工作？我知道,当我完全掌控自己有责任承担责任时 - 但如果公司选择冒险审计或责任的失败,那么我有责任牺牲我的工作来证明自己的观点,或者我是否寻求最佳和SAFEST方式做他们说的话？只是扮演魔鬼的拥护者......
开发人员总是试图说明我们的工作比其他工作更难,因为我们的垃圾需求一直在变化.嗯,这是一个完美的例子; 我们的职业迫切需要一个支柱.我们的职业迫切需要能够说"不,这不是一个可以接受的要求,这不是我真诚能够发展的事情,你可能是我的客户/雇主,但我对你的客户和公众负有专业责任,如果你想要这样做,那么你将不得不寻找其他地方."
我不是律师,但考虑一下.如果您的主管命令您做一些违反公司利益的事情,例如让他们承担一项容易避免的责任,那么您的工作是服从还是礼貌地拒绝？是的,他们是你的老板,但他们有自己的老板,即使是投资者.如果你不*过头,当你的安全漏洞被利用时,它的头部会滚动？只是需要考虑的事情.
好的,让我们在这里和现在进行风险评估."如果您以可恢复的形式存储密码,则会造成密码被盗的非常重要的风险.至少有些用户可能会使用相同的密码来处理他们的电子邮件和银行帐户.如果密码被盗并且银行账户已经耗尽,它可能会成为头条新闻,没有人会再与你做生意,你很可能会被起诉." 我们现在可以切废话吗？你把"纳粹"这个词带入这个事实清楚地表明你没有理智.
@sfussenegger:你不需要知道背景.这是不可接受的.你假设客户是100%值得信赖的 - 如果他特别要求这个要求,那么他以后可以用密码取消怎么办？安全性是开发中为数不多的**项目之一.有些事情你不做,存储可恢复的密码就是其中的十个.
@Thomas:每个人总是使用相同的借口来实现弱密码安全,即数据的"非关键性".你和其他所有的辩护士一样,忽略了密码被重用**的事实,这意味着你的"更接近"的类比实际上是毫无价值的.将其更改为要求某人为您提供他们的警报代码和整个密钥环以"保管",然后将其保留在军事级别的安全之上; 你可能不会让那个人被杀,但你很容易毁掉他的生命.
@sfussenegger:你想说的是事实上**我的答案的全部要点**.工程师,医生和其他专业也不受"联邦法律"的约束,他们受到职业道德和标准的约束.如果我们想像专业人士一样对待,那么我们必须开始像专业人士一样行事.我们不是孩子,我们不必遵循客户提供的每一个指示我们知道的事实**不理解潜在威胁的范围,无论他说了多少次"是的,是的,无论如何,只要这样做."
@Shane:我想这取决于你是否认为自己是专业人士.专业人员有义务坚持某些标准,无论他们是否"无法控制".我并不是说我会冲出办公室,永远不会回来,但我对此的反应是,"不,这不是**系统的要求,不再是."*让我扭曲这个如果您的雇主要求您开始使用注册密码并使用它们试图劫持已注册的垃圾邮件地址,您会这样做吗？
是的,风险程度与解密密钥的保护有关,但这种风险仍然总是非常重要的.密钥将始终由组织中的某个人读取(否则您可能使用单向哈希),这意味着他们可能被盗.企业有"灾难恢复"计划是有原因的 - 这不是发生重大事情的可能性*,这是*后果*.而对于声称我没有观点的人来说,你已经证明了对这个问题的范围有多么广泛的理解.密码盗窃**不能**发生.
@Shane:我想,如果是我,如果他们把一把众所周知的枪放在我的头上,我可能会走开.也许这听起来很牵强或理想主义,但当采取一项行动来破坏公众信任时,其他人肯定会效仿.首席执行官或首席信息官不是这方面的专家; 我是,如果我说某些事情不能安全/负责任地完成,那就是讨论的结束,**除非**我被证明是错误的**事实**.这个问题的答案都没有为恶意*内部人*提供任何保障,这些人通常被认为是最重要的安全威胁.
@Thomas:我不知道你在这里想说些什么.首先,您说单向哈希不排除密码强度要求.我同意.然后你重复相同的"无关系统"参数,这本身是无关紧要的,因为相同的密码可以并将用于其他系统.最后你回到了"支付支票的人"的论点,这是一个非首发,因为你不能保证这个人和他所代表的人都是值得信赖的.您的主要责任在于客户.所有这些要点都已经讨论过了.
@Aaronaught所以你会告诉一个客户/老板谁想要一个RSS-to-Twitter(早期,如上所述)服务,你不能这样做,直到假冒或委托子系统到位.但是如果他问外地的其他人怎么办,你会怎么说？他们没有像你那样符合道德规范吗？您是否相信通过将您的客户发送给"非道德"工程师,您可以帮助改善潜在用户的状况？如果我知道尽我所能尽可能地保存,而不是简单地移开视线,我可以更轻松地休息,这是肯定的.
@Aaronnaught - 总的来说,我同意你的观点,并且我专业地对待自己的责任,这就是为什么每当有人提出这样的请求时我就会相当痛苦地打架(我在我的问题中说明).然而,有些时候我没有真正选择这个问题而不是走开,这并不总是可能的.我真正担心的是如果你要这样做可以如何处理,我真的不是在争论这样做的优点,因为没有.在过去,我曾经被"安全"人员讲过,风险是必要的 - 有时真的没有胜利.
@Thomas:单向哈希是完整密码策略的*部分*; 它们也是**中最重要的部分.**如果你将单向哈希等同于"FBI犯罪数据库",那么你无权在任何地方处理任何安全代码.你继续前进并咆哮; 我已经完成了与这个胡扯的争论.
你有空白说,任何低于单向哈希的东西都不安全.那是极端主义的废话.这类似于说,如果没有报警系统,家庭就不安全.我使用FBI数据库作为安全纳粹所采取的滑坡的例子:"我们必须有单向哈希,最小密码长度,复杂性要求和密码到期......".如果没有合理的风险评估,每一个理由都会成为基于恐惧的理由.
坦率地说,我唯一建议的是有解决方案.你建议的每一个风险都可以减轻,但你不想听到.如果风险不为零,那么您无法接受.现实世界很少能在这样的绝对中运作.最后,要说我没有添加任何实质内容比水壶叫锅黑更糟糕.你唯一的答案是:"你不能".世界不会停止在其轴上旋转,因为有人使用非对称加密而不是单向散列来处理无关紧要的系统.
当然不是,如果我知道有人这样做,我会把他们带走.我不认为这是一对一的比较 - 防御可能的安全漏洞和自己利用它们之间存在差异.即使我认为我们在哲学上远离这个问题,你的声明在这里我觉得我应该假设任何网站在没有SSL证书的情况下要求我的用户名和密码就像那些刚刚攻击我的人一样邪恶电子邮件帐户,因为他们允许嗅探我的凭据的可能性？
@sfussenegger:非常弱的论点.可恢复的密码并不意味着可恢复的信用卡号码,即使这样,窃取信用卡号码的人更有可能被抓获,并且只有在通知信用合作社后才能进行有限的损害.我从未声称有一个"政府机构"执行这些安全审计 - 您是否意识到审计可能由投资者,董事会甚至业务合作伙伴或客户强制执行,具体取决于合同？
@sfussenegger:说实话,我不会开发或使用任何声称在未经他们明确许可的情况下使用某人的凭据的服务,*每一次*.从技术,道德和法律角度来看,这都是一大堆蠕虫.需要允许此类行为的系统将具有*模拟*或*委托*子系统,其中用户或服务可以登录到具有作为另一个用户的特定权限的代理帐户.电子邮件(即Microsoft Exchange)就是一个简单的例子.委托专门用于*防止*拥有共享密码.
顺便说一句,认为建筑师和建筑师以及其他什么行为都是道德行为是无稽之谈,有很多人会对被盗材料进行处理或降低水泥的质量(通过添加更多的沙子)等等.无论如何,这与手头的问题完全无关,但总是假设其他职业有更好的职位拒绝事情是天真的...... [继续]
@Shane:我的意图不是将收集电子邮件地址/密码的"邪恶"等同于以可恢复的形式存储它们的"邪恶"; 我只是指出,作为一名IT专业人员,您的责任不仅仅是遵循订单.在某些时候,你必须放下脚,并说"这是不道德的行为",并且它不应该像上面的例子一样糟糕.您不能允许不了解安全性的人员为*public*服务规定安全策略.
这是一个错误的比喻.它将安全性降低与威胁生命的火灾退出遗漏等同起来.认为所有系统都需要NSA安全措施是无稽之谈.一个更接近但有缺陷的类比将强制要求所有门都有锁定螺栓而不是简单的旋钮锁,安装任何比死锁更少的东西是不道德的.
@Aaronnaugh:每个安全人员都使用同样的弱点来进行极端安全措施.安全性基于风险评估.你想在cookie jar上放一个警报代码,当每个人都使用12345作为他们的警报代码时,你会感到骇然.如果您不强制执行强密码要求并限制密码重用,那么存储密码的方式就没有任何意义.声称在一个不相关的系统上拥有弱密码安全性会破坏某人的生命再次极端.这是关于生活在现实世界中支付支票的人打电话,而不是开发人员.
哈哈,好的!作为一名建筑师,我可以说这确实是真的.不是在那个方面,但实际上客户正试图"纠正"你,即使他们绝对不知道......奇怪的世界.
@Aaronaught所以有一个政府机构对可恢复的密码进行强制性检查？如果有,你不能合法地建立这个系统？... 不.另外,如果一个恶意的人可以简单地走出所有其他数据,他们为什么要烦恼呢？信用卡号码有人吗？客户必须理解和评估这是一个弱点(诚然是一个严重的弱点).不多也不少.期.
@Aaronaught只是举个例子:在Twitter的早期,第三方服务需要用户的密码代表他行事(思想本身让我的脊椎发抖).在这个时候,我会感谢任何开发人员在这个问题上花费的时间和@Shane一样多.实际上,许多善意的服务肯定将密码存储为纯文本.无论如何,重点是存储可恢复的密码是这个用例的必要条件.唯一的选择就是在这个蓬勃发展的市场中缺席自己.
@sfussenegger,这正是OAuth所针对的.
你提出的"无关系统"论点是根本问题:风险评估.你想要像FBI犯罪数据库一样对待每个系统.弱密码和密码重用是用户的错误; 不是系统,而是单独证明任何有关凭证的安全措施.我指出你的arg中的错误是1-hashes还不够.对于你来说,要成为"道德的",你必须拥有pwd length reqs,pwd复杂性reqs,pwd重用限制等等.如果系统无关紧要,那么所有这些都是不合理的.
...对于手头的问题,我认为已经提到了最好的方法,即通过让技术支持人员为他们提供新密码来完全回避问题,确保他们至少是可发音的密码.如果这是不可能的,那么客户对老年人或精神上的挑战几乎没有信心:)
您可以通过在多个人之间拆分密钥来降低风险,这样任何人都无法访问密钥.有关键管理的解决方案.你继续在各地使用相同的密码竖起大拇指.坦率地说,这是一个更大的风险,由用户创建和诞生,比任何实现都希望的那样,并且说每个系统的每个设计者,无论多么微不足道,都必须考虑到这种风险,以免被认为是不道德的没有普遍分享.
完全错误的等价.在你的例子中,一旦建筑师说火灾出口是一个法律要求,建筑物将在没有它们的情况下被谴责或拆除(即使它首先建造,它可能不会),客户说"好吧该死的,太糟糕了.很好." 在适当存储和散列密码的法律要求之前,这是一个废话类比.
@sfusseneger:这与许多"密码管理"程序类似; 辅助密码可以使用用户的主密码加密,这很好,因为除了知道主密码*的用户之外,它不能被任何人恢复.当每个用户都拥有一个只有他自己知道的唯一加密密钥时,这实际上是不可恢复的,并且*完全*与拥有某个管理员/员工拥有的单个密钥完全不同.
@Aaronaught这将要求用户在服务希望代表他发布内容时输入密码.但是,如果这是不可能的,即发布更新的某种机器人怎么办？简单地想象一下,该服务可以获取博客的RSS源并自动将新条目发布到Twitter.对于此API调用,您肯定需要用纯文本的用户密码.那你怎么做？
@molf肯定是的,但我指的是"推特的早期",OAuth不是一个选择.当然还有一些其他的例子,但Twitter仍然是一个众所周知的例子.如果服务提供商不支持OAuth或类似的方法(Twitter一开始没有),你会怎么做？
@Vinko Vrsalovic:其他职业表现得不正常.这个问题确实问过如何以符合道德的方式做到这一点,而且无论你如何处理它,我的回答基本上都是不道德的.如果你不关心职业道德,那么所有的赌注都会消失!
3> stefanw..：
您可以使用公钥加密密码+盐.对于登录,只需检查存储的值是否等于从用户输入+ salt计算的值.如果有时间,当需要以明文恢复密码时,您可以使用私钥手动或半自动解密.私钥可以存储在别处,并且可以另外对称地加密(这将需要人工交互来解密密码).
我认为这实际上与Windows恢复代理的工作方式类似.
密码以加密方式存储
人们可以登录而无需解密到明文
密码可以恢复为明文,但只能使用私钥,可以存储在系统外部(如果您愿意,可以存储在银行保险箱中).
1.问题是密码应该可以恢复到明文,所以这是一个要求.我在这里使用非对称加密而不是对称加密.解密的关键不是日常操作所必需的,可以保存在银行保险箱中.链接中的论证是有效的,但不适用于这种情况.
没错,但你是否同意,鉴于要求,这是最负责任的做法？你可以用CWE-257整天打我,它不会改变安全存储和使用凭证的有趣问题,并且如果需要可以将它们恢复到原始形式.
-1密码永远不应"加密"违反CWE-257 http://cwe.mitre.org/data/definitions/257.html
+1痴迷坚持CWE-257的重点在哪里？这是一个弱点(CWE),而不是漏洞(CVE).将可恢复密码与缓冲区溢出进行比较是比较苹果和橙子.只需确保客户理解问题(让他签署一些说明的话 - 否则他可能不记得任何问题)并继续进行.此外,所需的安全措施取决于系统的价值和潜在的攻击风险.如果成功的攻击者只能取消某些简报订阅,那么就没有理由争论任何问题.
Windows Recovery Agent在这里也是一个很糟糕的例子,因为它处理的是实际加密,而不是密码管理.加密密钥**与密码不同**; 围绕每个的规则和做法*完全*不同.加密和身份验证不一样.加密用于**隐私** - 密钥用于保护*数据*.身份验证用于**身份**,其中密钥*是数据*(在身份验证过程中它是**因素*).所以我再说一遍,**加密和身份验证不一样.**你无法有效地将one的原则应用到另一个.
CWE-257特别指出以"可恢复的格式"存储密码.您提出的建议是可恢复的格式,根据NIST,这是一个漏洞.这就是我给你-1的原因.此外,通过强制用户重置密码,可以一起避免此漏洞.增加的复杂性是不必要的,并且会产生较弱的系统.
都是真的.我不会建立这样一个系统,我把这个问题作为一个抽象的挑战,给定了要求.在旁注:如果涉及键盘记录器,一切都会进行:您可以从人们那里获得密码.
@jammycakes没有明确,没有 - 至少我找不到任何说法.此外,在某些情况下,密码必须以纯文本形式提供.例如,在Twitter的早期阶段,代表用户执行大量服务而没有任何交互.我只想表明有有效的用例,@ stefanw尽力回答这个问题.我简直无法相信人们因为给出可接受的答案而投票给他.
@jammycakes肯定是不好的做法,毫无疑问.但作为第三方开发者,你别无选择,只能(咆哮)问自己这个问题:"我应该如何道德地接近用户密码存储以便以后的明文检索？" ;)
@Michael Brooks:您的第一条评论直接与CWE相矛盾:"使用强大的,不可逆的加密来保护存储的密码." 可能是一个错字？
要求私钥不会阻止内部人员解密密码.内部人士恰巧是已经拥有加密密码的人.
@Aaronaught当然可以.没有人想存储可恢复的密码.但是为了要求密码可以恢复,它可能非常适合这种情况.@Steven您可以对私钥强制执行4个或更多眼睛策略(例如,多个人按顺序加密它).
@Shane:为避免内部滥用私钥的问题,您可以使用对称密钥进一步加密密码,作为用户拥有的一些信息(出生地,宠物名称等),但不存储在系统中.要恢复密码,用户提供用于解密的密钥,然后再使用私钥重新解密以获取orignal密码.
在我工作的一家公司,我们有一个信息安全团队,如果在建议的系统中发现了重大的安全威胁,公司董事必须签署一份表格,说明他们了解风险并且对系统继续感到高兴. .
4> user207421..：
不要放弃.您可以用来说服客户的武器是不可否认的.如果您可以通过任何机制重建用户密码,您已经为其客户提供了合法的不可否认机制,他们可以拒绝任何依赖于该密码的交易,因为供应商无法证明他们没有重建密码并通过自己进行交易.如果密码被正确存储为摘要而不是密文,那么这是不可能的,因为最终客户自己执行了交易,或者违反了他的密码责任.在任何一种情况下,他都要承担责任.我曾经处理过数亿美元的案件.不是你想要出错的东西.
@Vinko Vrsalovic,网络服务器在法庭上记录SHOULDNT计数,为了这样做,你需要证明不可否认性,真实性证据,证据链等等,哪些网络服务器日志显然不是.
究竟.供应商必须证明***客户本可以执行该交易.Web服务器日志不会这样做.
网络服务器日志不计入法庭？或者在这种情况下,它们也会被假定为伪造？
5> jammycakes..：
您无法合乎道德地存储密码以便以后进行明文检索.就这么简单.甚至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实际上正在加密其用户的密码,但它使用的加密太弱而无法生效.
@jimmycakes - 这对于低安全性系统来说是一件好事,但是如果你要存储任何高价值的数据,那么你必须假设这些人的电子邮件已经被泄露,并且发送一个直接登录链接会危及你的系统.+1用可行的替代方案回答我的问题,但指出整个逻辑中的缺陷.我不希望Payppal发送直接登录链接EVER.这可能听起来很偏执,但我总是认为我的电子邮件帐户是腐败的 - 它让我诚实.;)
6> Mr. Boy..：
看完这部分后:
在下面的一个注释中,我指出,当人们被要求执行安全的密码恢复程序时,主要针对老年人,智障人士或非常年轻人的网站可能会让人感到困惑.虽然在这些情况下我们可能会发现它简单而平凡,但有些用户需要额外的帮助,要么让服务技术人员帮助他们进入系统,要么将其直接通过电子邮件发送/显示给他们.
在这样的系统中,如果用户没有获得这种级别的访问协助,那么来自这些人口统计数据的流失率可能会阻碍应用程序,因此请记住这样的设置.
我想知道这些要求中是否有任何要求可检索的密码系统.例如:梅布尔姨妈打来电话说:"你的互联网程序无效,我不知道我的密码"."OK"说客户服务无人机"让我检查一些细节,然后我会给你一个新密码.当你下次登录它会询问你是否要保留密码或将其更改为你能记住的东西更容易."
然后系统设置为知道密码重置何时发生并显示"您想保留新密码还是选择新密码"消息.
与被告知旧密码相比,对于识字能力较差的人来说,情况会更糟吗？虽然客户服务人员可以忍受恶作剧,但数据库本身在被破坏时更加安全.
评论我的建议有什么不好,我会建议一个实际上做你最初想要的解决方案.
我刚注意到这个答案.@Shane,我不明白为什么你预测会对"内部威胁"产生火焰.更改密码的能力不是一个明显的弱点; 问题是能够发现可能用于*其他*服务的密码 - 她的电子邮件,她的银行,她的存储CC信息的在线购物网站.这种弱点并没有在这里表现出来; 如果Bob重置Mabel的密码并通过电话告诉她,这不会让他访问她的任何其他帐户.但是,我会*强制*而不是"建议"在登录时重置密码.
@john - 我认为这是一个非常可行的解决方案.尽可能准备好了解内部威胁!你知道,如果我用中间密码重置(技术手动设置密码作为临时方法,并告诉Mabel键入1234作为她的密码),那么它可能在不包含重要数据的系统上运行良好.如果它是一个高安全性的环境,那么我们就会遇到一个问题,即cust服务可以将CEO的密码设置为1234并直接登录.没有完美的解决方案,但这个解决方案适用于很多实例.(1)
支持人员提供的代码不一定是新密码.它可以只是一次性代码,解锁密码重置功能.
7> Phil H..：
迈克尔·布鲁克斯对CWE-257一直非常直言不讳 - 无论你使用什么方法,你(管理员)仍然可以恢复密码.那么这些选项如何:
用其他人的公钥加密密码- 一些外部权限.这样你就无法亲自重建它,用户将不得不去那个外部机构并要求恢复他们的密码.
使用从第二个密码短语生成的密钥加密密码.执行此加密客户端,并且永远不会将其以明文形式发送到服务器.然后,要恢复,请通过从其输入重新生成密钥再次执行解密客户端.不可否认,这种方法基本上是使用第二个密码,但您可以随时告诉他们将其写下来,或使用旧的安全问题方法.
我认为1.是更好的选择,因为它使您能够指定客户公司内的某人持有私钥.确保他们自己生成密钥,并将其与指令一起存储在保险箱等中.您甚至可以通过选择仅加密并从密码中提供某些字符到内部第三方来增加安全性,这样他们就必须破解密码才能猜到它.将这些字符提供给用户,他们可能会记住它是什么!
公钥
当然,您可以使用任何秘密拆分技术来要求公司的多个人进行解密.但是,这些都不符合能够向用户发送密码的原始要求,或者让一些不受欢迎的一级手机支持者通过登录来完成这些要求.
8> Jacob..：
为回应这个问题,用户已经对安全问题进行了大量讨论,但我想补充说明一些好处.到目前为止,我还没有看到一个合法的好处,就是在系统上存储了可恢复的密码.考虑一下:
用户是否可以通过电子邮件将密码发送给用户？不会.他们从一次性密码重置链接中获得更多好处,这有望让他们选择一个他们会记住的密码.
用户是否可以在屏幕上显示密码？不,出于与上述相同的原因; 他们应该选择一个新密码.
用户是否可以让支持人员向用户说出密码？没有; 再次,如果支持人员认为用户对其密码的请求经过适当的认证,那么给予新密码和更改密码的机会更有利于用户的利益.此外,电话支持比自动密码重置更昂贵,因此该公司也没有受益.
似乎唯一可以从可恢复密码中受益的是具有恶意意图的人或者需要第三方密码交换的不良API的支持者(请不要使用所述API!).也许你可以通过如实地向你的客户说明公司通过存储可恢复的密码而不会获得任何好处和负债来赢得你的论证.
在这些类型的请求之间进行读取,您会发现您的客户可能根本不了解或甚至根本不关心如何管理密码.他们真正想要的是一种对用户来说不那么难的认证系统.因此,除了告诉他们他们实际上不想要可恢复的密码之外,您应该为他们提供一些方法来减少身份验证过程,特别是如果您不需要银行的严重安全级别:
允许用户使用其电子邮件地址作为其用户名.我见过无数用户忘记用户名的情况,但很少忘记他们的电子邮件地址.
提供OpenID并让第三方支付用户健忘的费用.
减轻密码限制.我确定当一些网站不允许您的首选密码时,我们都非常恼火,因为无用的要求,例如"您不能使用特殊字符"或"您的密码太长"或"您的密码必须启动带着一封信." 此外,如果易用性比密码强度更大,您可以通过允许更短的密码或不需要混合字符类来放松非愚蠢的要求.随着限制的放松,用户将更有可能使用他们不会忘记的密码.
不要使密码过期.
允许用户重用旧密码.
允许用户选择自己的密码重置问题.
但是,如果您出于某种原因(并且请告诉我们原因)真的,真的,确实需要能够获得可恢复的密码,您可以通过向用户提供非密码来保护用户免受其他在线帐户的侵害 -基于认证系统.因为人们已经熟悉用户名/密码系统并且它们是一个运行良好的解决方案,这将是最后的手段,但肯定有很多创造性的密码替代方案:
让用户选择一个数字引脚,最好不是4位数,最好只有在强力尝试受到保护的情况下.
让用户选择一个简短回答的问题,只有他们知道答案,永远不会改变,他们会永远记住,他们不介意其他人发现.
让用户输入一个用户名,然后绘制一个易于记忆的形状,并有足够的排列以防止猜测(请参阅这张 G1如何解锁手机的漂亮照片).
对于儿童网站,您可以根据用户名(类似于同一个用户名)自动生成模糊生物,并要求用户为该生物提供一个秘密名称.然后可以提示他们输入生物的秘密名称以登录.
9> AviD..：
根据我在这个问题上所做的评论:
几乎所有人都明白了一个重要的观点...我最初的反应与@迈克尔·布鲁克斯非常相似,直到我意识到,就像@stefanw一样,这里的问题是破碎的要求,但这些都是它们.
但随后,我发现甚至可能不是这样!这里缺少的是应用程序资产的未说出的价值.简单来说,对于低价值系统,一个完全安全的认证机制,涉及所有过程,将是过度的,并且是错误的安全选择.
显然,对于银行而言,"最佳实践"是必须的,并且没有办法在道德上违反CWE-257.但是很容易想到价值不高的低价值系统(但仍然需要一个简单的密码).
重要的是要记住,真正的安全专业知识是找到适当的权衡,而不是教条地宣传任何人都可以在线阅读的"最佳实践".
因此,我建议采用另一种解决方案:
取决于系统的价值,并且只有系统具有适当的低价值且没有"昂贵"的资产(包括身份本身),并且有正确的业务要求才能实现正确的流程不可能的(或足够困难/昂贵),和客户端意识到所有的注意事项的......
然后,它可能是适当的,以简单地允许可逆加密的,没有特殊的跳火圈通过.
我完全停止说不要加密加密,因为它实现起来非常简单/便宜(甚至考虑了可通行的密钥管理),并且它提供了一些保护(超过了实现它的成本).此外,它值得看看如何为用户提供原始密码,无论是通过电子邮件,在屏幕上显示等等.
由于这里的假设是被盗密码的价值(即使在汇总)是非常低的,任何这些解决方案可以有效.
由于正在进行热烈的讨论,实际上是在几个热烈的讨论中,在不同的帖子和单独的评论帖中,我将补充一些说明,并回应在这里其他地方提出的一些非常好的观点.
首先,我认为这里的每个人都清楚,允许检索用户的原始密码,是不良做法,通常不是一个好主意.这根本不存在争议......
此外,我会强调在许多情况下,不管怎样,情况 - 这是非常错误的,甚至是犯规,讨厌和丑陋.
然而,问题的关键在于原则,是否有任何情况可能没有必要禁止这种情况,如果是的话,如何以最适合情况的正确方式这样做.
现在,正如@Thomas,@ snussegger和其他一些人提到的那样,回答这个问题的唯一正确方法是对任何给定(或假设)的情况进行彻底的风险分析,以了解利害关系,保护多少值得保护以及还有哪些其他缓解方法可以提供这种保护.
不,它不是一个流行语,这是真实安全专业人员的基本,最重要的工具之一.最佳实践达到了一定程度(通常作为缺乏经验和黑客的指导方针),在此之后进行深思熟虑的风险分析.
你知道,这很有趣 - 我一直认为自己是安全狂热分子之一,不知怎的,我正处于那些所谓的"安全专家"的对立面......好吧,事实是 - 因为我是一个狂热分子,和一个真实的现实安全专家 - 我不相信喷出"最佳实践"教条(或CWE)而没有那么重要的风险分析.
"要小心安全狂热者,他们很快就能在他们的工具带上应用所有东西而不知道他们正在防范的实际问题.更多的安全性并不一定等同于良好的安全性."
风险分析和真正的安全狂热分子将指出基于风险,潜在损失,可能的威胁,补充缓解等基于价值/风险的更明智的权衡.任何"安全专家"都不能指出健全的风险分析.他们的建议的基础,或支持逻辑权衡,但更愿意劝说教条和CWE,甚至没有理解如何进行风险分析,没有安全黑客,他们的专业知识是不值得他们打印的卫生纸.
实际上,这就是我们如何得到机场安全的荒谬.
但在我们讨论在这种情况下做出的适当权衡之前,让我们看看明显的风险(显而易见,因为我们没有关于这种情况的所有背景信息,我们都假设 - 因为这个问题是假设的情况可能有...)
让我们假设一个低价值的系统,但不是那么琐事,它是公共访问 - 系统所有者想要防止随意冒充,但"高"安全性并不像易用性那样至关重要.(是的,接受任何熟练的脚本小子可以破解网站的风险是合法的权衡......等等,现在不是APT流行......？)
例如,假设我正在安排一个这是一个简单的大型家庭聚会场所,让每个人都可以在今年的野营旅行中集思广益.我不太担心一些匿名黑客,或者甚至是Cousin Fred反复建议回到Lake Wantanamanabikiliki湖,因为我是关于Erma姨妈在她需要的时候无法登录.现在,作为核物理学家的艾玛姨妈不太擅长记住密码,甚至根本不使用计算机......所以我想删除所有可能的摩擦力.再说一次,我并不担心黑客,我只是不想要错误登录的愚蠢错误 - 我想知道谁来了,他们想要什么.
无论如何.
那么,如果我们对密码进行对称加密,而不是使用单向哈希,那么我们的主要风险是什么呢？
冒充用户？不,我已经接受了这种风险,而不是有趣.
邪恶的管理员？嗯,也许......但同样,我不关心,如果有人可以模拟其他用户,内部或没有......反正恶意管理员是会得到你的密码,不管是什么 -如果你的管理员的坏了,它的游戏呢.
另一个问题是,身份实际上是在多个系统之间共享的.啊! 这是一个非常有趣的风险,需要仔细观察.
让我首先断言,它不是共享的实际身份,而是证据或身份验证凭据.好的,因为共享密码将有效地允许我进入另一个系统(例如,我的银行帐户或gmail),这实际上是相同的身份,所以它只是语义...除非它不是.在这种情况下,身份由每个系统单独管理(尽管可能存在第三方ID系统,例如OAuth - 仍然,它与该系统中的身份分开 - 稍后将详细介绍).
因此,这里的核心风险点是,用户愿意将他的(相同)密码输入到几个不同的系统中 - 现在,我(管理员)或我网站的任何其他黑客都可以访问阿姨阿玛的密码核导弹基地.
嗯.
这里有什么似乎不适合你吗？
这应该.
让我们从保护核导弹系统不是我的责任这一事实开始,我只是建立一个frakkin家庭郊游网站(为我的家人).那么它的责任是什么呢？嗯......核导弹系统怎么样？咄.
第二,如果我想窃取某人的密码(知道在安全网站之间重复使用相同密码的人,而不是那么安全的密码) - 为什么我会打扰你的网站呢？或者与对称加密斗争？Goshdarnitall,我可以建立自己的简单网站,让用户注册接收任何他们想要的非常重要的新闻... Puffo Presto,我"偷"了他们的密码.
是的,用户教育总是回来咬我们的hienie,不是吗？
你无能为力......即使你想在你的网站上散列他们的密码,并做其他TSA可以想到的其他事情,你还要保护他们的密码而不是一个白人,如果他们要保留将他们的密码粘贴到他们碰到的每个网站.不要打扰尝试.
换句话说,你没有自己的密码,所以不要试图像你那样行事.
所以,亲爱的安全专家,作为一位曾经问温迪的老太太,"哪里有风险？"
另外几点,回答上面提出的一些问题:
CWE不是法律,法规,甚至是标准.它是常见弱点的集合,即"最佳实践"的倒数.
共享身份问题是一个实际问题,但被反对者误解(或歪曲)在这里.这是一个共享身份本身的问题(!),而不是在低价值系统上破解密码.如果您在低价值系统和高价值系统之间共享密码,问题就已存在!
顺便提一下,之前的观点实际上将指向AGAINST使用OAuth等这些低价值系统和高价值银行系统.
我知道这只是一个例子,但(遗憾的是)FBI系统并不是最安全的.不太像你的猫的博客服务器,但它们也没有超过一些更安全的银行.
加密密钥的分裂知识或双重控制不仅仅发生在军队中,事实上PCI-DSS现在基本上要求所有商家使用它,所以它不再那么远(如果价值合理的话).
对于所有那些抱怨这些问题的人来说,开发人员行业看起来如此糟糕:这些都是安全行业看起来更糟糕的答案.同样,以业务为中心的风险分析是必需的,否则你会使自己无用.除了错误.
我想这就是为什么仅仅聘请一名普通的开发人员并在他身上放下更多的安全责任,而不进行不同的思考训练,并寻找正确的权衡,这不是一个好主意.没有冒犯,对你们这些人来说,我都是为了它 - 但是需要更多的训练.
呼.多长的帖子......
但是要回答你原来的问题,@Shane:
向客户解释做事的正确方法.
如果他仍然坚持,那么解释一下,坚持,争辩.如果需要的话,发脾气.
向他解释商业风险.细节很好,数字更好,现场演示通常是最好的.
如果他仍然坚持,并提出有效的商业理由 - 是时候给你做一个判断电话:
这个网站是否低至无价值？这真的是一个有效的商业案例吗？这对你好吗？是否没有其他风险可以考虑,这会超过有效的商业原因？(当然,客户端不是恶意网站,但多数民众赞成).
如果是这样,那就去吧.使用必要的流程并不值得努力,摩擦和失去使用(在这种假设的情况下).任何其他决定(再次,在这种情况下)是一个不好的权衡.
因此,底线和实际答案 - 使用简单的对称算法对其进行加密,使用强ACL保护加密密钥,最好使用DPAPI等保存加密密钥,对其进行记录并让客户(足够高级的人做出决定)签字它.
对不起,但身份本身**是一个高价值资产,期间.没有例外,没有任何借口.无论您认为您的网站有多么小而且无关紧要.如果共享密码**允许黑客进入用户的Facebook帐户,Gmail帐户,银行帐户等,那么共享密码**就是身份.这与语义无关,但它与后果无关.只要问一个受黑客攻击影响的人,比如这个:http://www.theregister.co.uk/2009/08/24/4chan_pwns_christians/
您的低价值网站与"无"昂贵的资产和Facebook/GMail /您的银行**之间共享的密码**是一种昂贵的资产,即使在低价值网站上也是如此.
@Jacob,这是非常错误的.仅仅因为密码恰好相同(这显然违反了你的ToS及其安全政策),他们没有法律地位来腐蚀这两者.多数民众议员甚至认为提供它几乎是不可能的事实.顺便说一句,我还要指出,除非特定的法规相关,否则没有法律要求随机公司没有宽松的安全措施.最重要的是,密码是加密的(!),所以松懈远远不是一个放弃的结论.
我认为这里的问题是上述用户群倾向于对来自许多不同安全级别(从银行业务到配方博客)的所有应用程序使用相同的密码.所以问题是,如果开发人员有责任保护用户甚至自己.我肯定会说,是的!
@Jacob,因为Erma在其他系统上的账户受到了损害,你的客户会被起诉到什么世界？即使你的客户犯了很大的疏忽(这不是一个给定的,正如我所阐述的那样),并且BESIDES事实上没有办法证明其他系统因你的而被违反,所以没有可能的合法地位.从另一个系统的一个系统索赔任何形式的损害赔偿.它会在偏见的情况下抛出法庭,并蔑视原告.但是,Erma可能因违反众多服务条款而有过错......
如果帐户遭到入侵,因为贵公司的某人收回了Emma的密码,并且事实证明它已经发生了,那么您的公司可能会因为安全措施松懈而被起诉.法院是否会对她有利并不重要; 贵公司仍然需要投入资源来解决诉讼问题,并且因为案件而面临失去客户的后果.为什么让公司通过这个？公司仍然没有理由想要一个可恢复的密码.
除了上面讨论的业务需求之外,还有可逆加密密码的合法(但不是很好)技术原因.这是PCI-DSS要求用户密码对称加密的原因之一!
仍然没有听说过那些合法的理由,除非在我没有看到的讨论中增加了一些新的理由.而且你错过了我的观点,即法律是否会在公司一边并不重要.即使法院没有发现错误,也没有公司会因为对客户密码的责任而声名鹊起.是的,可以证明,如果有人通过正确的记录和审核窃取密码,而不是证明不法行为的难度无论如何都证明了错误行为.
10> Oded..：
中途的房子怎么样？
使用强加密存储密码,不要启用重置.
允许发送一次性密码(必须在第一次登录后立即更改),而不是重置密码.然后让用户更改为他们想要的任何密码(前一个,如果他们选择).
您可以将其"出售"为重置密码的安全机制.
@Michael Brooks:没有必要一遍又一遍地对同一评论进行downvote和copy-paste; 我们都知道这是不好的做法.Shane说,他在这个问题上缺乏影响力,所以提出了下一个最好的事情.
要求他们签署"设计",并附加一条条款,如果你警告他们确实发生了什么,他们就不能起诉你......至少你会掩饰自己.
-1密码永远不应"加密"违反CWE-257 http://cwe.mitre.org/data/definitions/257.html
11> Nicholas Sha..：
允许用户检索其原始密码的唯一方法是使用用户自己的公钥对其进行加密.只有该用户才能解密他们的密码.
所以步骤是:
用户在您的站点上注册(当然是通过SSL)而无需设置密码.自动登录或提供临时密码.
您提供存储其公共PGP密钥以供将来密码检索.
他们上传他们的公共PGP密钥.
您要求他们设置新密码.
他们提交密码.
您使用可用的最佳密码哈希算法(例如bcrypt)对密码进行哈希处理.验证下次登录时使用此选项.
您使用公钥加密密码,并单独存储.
如果用户随后要求输入密码,则使用加密(非散列)密码进行响应.如果用户以后不希望能够检索他们的密码(他们只能将其重置为服务生成的密码),则可以跳过步骤3和7.
大多数用户没有PGP密钥(我仍然没有PGP密钥;在业内20年后,我从未感觉到需要),并且它不是一个无摩擦的过程.此外,私钥实际上只是实际密码的代理.换句话说,它是密码的密码; 它一直都是乌龟.
12> z-boss..：
我认为你应该问自己的真正问题是:'我怎样才能更好地说服人？'
@ z-boss - 显然你还没有和我一起工作的一些硬头一起工作过.有时候,如果你的舌头镀金并且你可以在一天内重新编程谷歌浏览器(这可能实际上可能使它有用),它们仍然不会让步.
@sneg - 嗯,我是一个非常有说服力的人,但有时候它是老板,有时候是客户,所以我并不总是有能力让我们用这种或那种方式说服他们.我会更多地在镜子里练习..;)
13> Daniel Loure..：
我有同样的问题.同样地,我总是认为有人破解了我的系统,这不是"如果"而是"何时"的问题.
所以,当我必须建立一个需要存储可恢复的机密信息的网站时,比如信用卡或密码,我做的是:
加密:openssl_encrypt(string $ data,string $ method,string $ password)
PHP手册.
数据arg:
敏感信息(例如用户密码)
必要时序列化,例如,如果信息是多个敏感信息的数据数组
密码arg:使用只有用户知道的信息:
用户牌照
社会安全号码
用户电话号码
用户母亲的名字
在注册时通过电子邮件和/或短信发送的随机字符串
方法arg:
选择一种密码方法,如"aes-256-cbc"
切勿将"password"参数中使用的信息存储在数据库(或系统中的任何位置)
必要时,只需使用"openssl_decrypt()"函数来检索此数据并询问用户答案.例如:"接收密码回答问题:你的手机号码是什么？"
PS 1:永远不要将数据存储在数据库中用作密码.如果您需要存储用户手机号码,请不要使用此信息对数据进行编码.始终使用只有用户知道的信息或者非亲属知道的信息.
PS 2:对于信用卡信息,如"一键购买",我所做的就是使用登录密码.此密码在数据库(sha1,md5等)中进行哈希处理,但在登录时,我将明文密码存储在会话中或非持久性(即内存中)安全cookie中.这个普通的密码永远不会留在数据库中,实际上它始终保留在内存中,在部分末尾被销毁.当用户点击"一键购买"按钮时,系统使用此密码.如果用户使用facebook,twitter等服务登录,那么我会在购买时再次提示输入密码(好吧,这不是完全"点击")或者然后使用用户用来登录的服务的一些数据(比如facebook id).
14> Thomas..：
保护凭证不是二进制操作:安全/不安全.安全是关于风险评估的,并且是连续的.安全狂热分子讨厌这样思考,但丑陋的事实是没有什么是完全安全的.具有严格密码要求的哈希密码,DNA样本和视网膜扫描更安全,但代价是开发和用户体验.明文密码的安全性要差得多,但实施起来要便宜(但应该避免).在一天结束时,它归结为对违规行为的成本/收益分析.您可以根据受保护数据的值及其时间值来实现安全性.
某人的密码进入野外的成本是多少？在给定系统中冒充的成本是多少？对FBI计算机来说,成本可能是巨大的.对Bob的一次性五页网站来说,成本可以忽略不计.专业人员为其客户提供选择,并且在安全性方面,列出了任何实施的优势和风险.如果客户要求可能因为未能注意行业标准而将其置于风险之中,那么情况就更是如此.如果客户专门请求双向加密,我会确保您记录您的异议,但这不应该阻止您以您知道的最佳方式实施.在一天结束时,这是客户的钱.是的,你应该推动使用单向哈希,但要说这绝对是唯一的选择,其他任何不道德的行为都是完全无稽之谈.
如果您使用双向加密存储密码,则安全性都归结为密钥管理.Windows提供了一些机制来限制对管理帐户和密码的证书私钥的访问.如果您在其他平台上托管,则需要查看可用的选项.正如其他人所建议的那样,您可以使用非对称加密.
我没有法律(英国的数据保护法案),我知道具体说明密码必须使用单向哈希存储.任何这些法律的唯一要求就是采取合理的安全措施.如果限制访问数据库,即使是明文密码也可以在这种限制下合法地获得资格.
然而,这确实揭示了另一个方面:法律优先权.如果法律优先权暗示您必须使用单向哈希给定您的系统正在构建的行业,那么这是完全不同的.这是你用来说服你的顾客的弹药.除此之外,最好的建议是提供合理的风险评估,记录您的异议并以最安全的方式实施系统,以满足客户的要求.
您的回答完全忽略了密码在多个站点/服务中重复使用,这是本主题的核心,也是可恢复密码被认为是严重弱点的原因.安全专业人员不会将安全决策委托给非技术客户; 专业人士知道他的责任超出了付费客户的范围,并且不提供高风险和**零**奖励的选项.-1对于言辞沉重的谴责和极其轻松的事实 - 甚至没有真正回答这个问题.
再次重复一下,这对于低价值系统来说都不重要!**用户密码的值与系统上用户帐户的值无关.**这是*秘密*,是您必须始终保留的密码.我希望我能给另一个-1评论,表明你仍然**不理解这里的问题.
这里唯一清楚的是,你的整个论点只不过是一个滑坡倾向的谬论,你试图用"风险评估"等流行语来吸引读者,以掩盖这一事实.请放心,"FBI"使用的任何系统都比bcrypt哈希和最小密码长度安全得多.如果要求行业标准认证系统让我成为"安全狂热者",那么我想我是一个狂热者; 就个人而言,我很难知道有人愿意为了钱而牺牲****安全.那是**不道德的**.
风险评估是核心问题.密码重用只是一大堆问题中的一个潜在问题.为什么不要求表链？为什么不要求该人开车到您的办公室登录？如果没有合理的风险评估,就无法回答这些问题.在您的世界中,一切都是风险,因此每个系统都需要FBI级别的登录安全性.这根本不是现实世界的运作方式.
同样,您完全忽略了风险评估.要使用你的论点,你不能只停留在单向哈希.您还必须包括复杂性要求,密码长度,密码重用限制等.如果系统无关紧要,坦白说,用户将使用愚蠢的密码或重用密码并不足以作为商业理由,我确实回答了这个问题.简短的回答:推动使用标准实施,如果您被否决,请记录您的反对意见并继续前进.
""FBI"使用比bcrypt哈希和最小密码长度更安全"为什么你认为FBI系统比大多数系统有更严格的安全要求,或者更具体地说,为什么大多数系统都没有这些安全要求？回答这个问题,你就能够回答为什么合理的安全措施的概念与"你必须在所有情况下做x"之间存在巨大差异.
@Thomas:你在这里争论说,腌制和散列密码是一种昂贵且复杂的负担.事实并非如此.它非常简单(对于一个称职的开发人员来说,这是一天左右的工作)如果正确实施它会产生*无可用性影响.现在,数据保护法案.同意,它没有*明确*授权盐渍哈希,但强烈暗示你坚持要考虑(a)可用的技术措施和(b)实施它们的成本.如果您实际*进行风险分析,您会发现未能在密码上实施单向盐渍哈希是不计其数的.
我承认在立法中没有任何关于盐渍哈希的明确**,但它是**暗示**.此外,对于使用用户密码的可逆加密,没有任何**商业案例**(除了无知之外).Salting和hashing密码并不困难,并且向用户发送一次性密码重置页面链接(而不是新密码或现有密码)不仅更安全,而且更加用户友好,因为它们不必须复制和粘贴任何内容或导航回登录表单,只需单击一下即可直接进入.
@jammycakes - *您需要存储公钥和私钥,以便Web服务器访问它们*.每天都有成千上万的人的个人信息通过双向传输和存储.示例:信用卡.当Amazon保存您的cc信息时,他们使用双向加密.他们怎么能道德地做到这一点？简短的回答是关键管理.可以这样做,使得只有Web服务器和受信任的个人可以访问密钥并记录对密钥的访问.它比单向更简单,更安全吗？不是由一个长镜头.但显然它可以在道德上完成.
哦,我明白了,所以基本上你说安全是"全有或全无",如果你不能拥有所有其他东西,那么你也不应该打扰单向哈希？我假设您从未真正进行风险评估,因为可恢复的密码通常是您首先要查找的内容之一.
另外,我不买军队的比较.如果您希望在网站上进行双向可逆加密,则需要将公钥和私钥存储在Web服务器可以访问的位置.最重要的是:如果您的用户可以以纯文本形式请求他们的密码,那么如果您在系统中的某个地方有安全漏洞,那么黑客也有可能 - 这完全否定了首先进行双向加密的重点.为什么只要很少或不需要额外费用就可以实现**坚固的替代品,那么实施**可能会变得不稳定的东西？
@jammycakes - 没有"隐含的"法律义务.有一些将在法庭中持有而不会在法庭中持有.到目前为止,关于pwd管理的法律要求*合理的*安全步骤,其中双向加密将符合条件.您可能会发现围绕明文密码的诉讼,但没有使用双向密码.同样,手头的问题绝对没有任何**与实施的难易程度有关.没有.尽管有OP的抗议,但所有这些都是关于客户提出可逆密码的具体要求.
@jammycakes - *为什么要在很少或没有额外费用的情况下实现坚如磐石的替代方案时实施可能会出现问题的东西？*因为尽管有这样的论点,客户否决了你.我同意接受的答案,因为重置时生成的丑陋自动密码很可能*.没有人质疑单向哈希绝对是最好的做法.我会反对其他任何事情,并且会记录我的反对意见.然而,在一天结束时,客户是付账单的人,最终他们的选择除非有法律限制.
我之所以提到"数据保护法",是因为它为开发人员提供了一个法律论据来反驳客户的反对意见,并质疑其在这种情况下的有效性会破坏这一论点.如果你有这样的客户并且在这个上获得法律顾问,那么如果你能向他们展示原型,他们很可能会接受一个可行的替代方案.另一方面,如果你向他们展示了一个工作原型替代品,**和**他们仍然推翻你,尽管被告知有法律含义,你可能有一个问题客户手.
@jammycakes - 使用加密而不是哈希,与使用加密存储任何其他类型的个人或私人信息一样道德.这不是对安全的妥协.相反,你只是打开另一个*潜在*攻击向量.按照你的逻辑,可以说允许密码少于五个字符是不道德的.加密确实需要对管理系统的人比对哈希更加信任.我永远不会建议加密密码,但声称任何形式的密码加密都是*不道德*只是极端主义.
(1)它不是极端主义者,它是负责任的.(2)我不知道你是否意识到这一点,但是通过说"这不是对安全的妥协,而是你只是留下另一个潜在的攻击向量",你刚才自相矛盾.(3)丢失数据库不是"不太可能的事件".索尼上周失去了七千万Playstation用户的登录和信用卡详细信息,尽管他们认为这是严格的安全措施.我们正在讨论**一次又一次发生的**真实世界**情况.
@Thomas:(1)你显然明白我使用"妥协"一词是"违反"的同义词.我一直在使用"妥协"这个词作为"权衡"的同义词.换句话说,你使用**比单向哈希更不安全的替代方案** - 这使得它不道德的原因是**对于这个决定没有任何有效的技术理由**.当然,如果他们被**建议**使用更强大的加密形式并且**故意拒绝它**他们肯定会处于法律上.
@Thomas:期望用户不要重复使用密码是完全不现实的**.首先,非技术用户根本不了解风险.另一方面,避免重复使用密码很困难.记住数百种不同的登录根本不是一种选择,而像KeePass这样的密码管理器虽然对像我们这样的技术娴熟的人有用,却远远不如简单地记住全面的密码.
@Thomas:期望用户不要重复使用密码是完全不现实的**.即使是拥有密码管理器的技术用户,也不会重复使用密码.最大的困难是跨多个设备同步它们.你的iPhone.你的PlayStation.你的网络电视.你朋友的电脑.网吧.企业网络上的锁定工作站.不重复使用密码涉及纪律,努力和牺牲.对于那些不了解风险并且在谈论这些事情时眼睛茫然的非技术用户,这几乎是一个失败的原因.
@Thomas:归结为此.对于大多数敏感信息,双向加密是最好的.**使用密码,情况并非如此.密码的双向加密涉及削弱您向用户提供的保护,没有任何正当的好处,无论从法律角度(它可能不是)实际上是否确实存在CYA,它仍然是不道德的.
@Thomas:选择一个你知道**的选项比其他选择更具风险,其他人委托给你的敏感数据,当没有正当理由这样做时,是不道德的,期间.
@Thomas:是的,我确实关心敏感的个人信息.但密码完全不同.由于密码数据库受到攻击,攻击者可以轻易地**冒充**大部分用户群.**他们可以**接管**他们的电子邮件帐户,从那里,他们可以很容易地接管他们的一生.正如我所说,密码可能是你在整个网站上存储的最敏感的**信息.
15> Rob Fonseca-..：
将用户安全问题的答案作为加密密钥的一部分,并且不要将安全问题答案存储为纯文本(而是替代哈希)
安全问题是一个坏主意.一旦信息被破坏,你如何让你的妈妈改变她的婚前姓名？另见Peter Gutmann的[工程安全](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).
@jww你的链接坏了https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
16> Monoman..：
我实现多因素身份验证系统,所以对我来说,很自然地认为你可以重置或重建密码,而暂时使用一个较少的因素来验证用户只是重置/重新创建工作流程.特别是使用OTP(一次性密码)作为一些附加因素,如果建议的工作流程的时间窗口很短,则可以减轻大部分风险.我们已经为智能手机实现了软件OTP生成器(大多数用户已经整天携带)并取得了巨大的成功.在抱怨商业插件出现之前,我所说的是,当它们不是用于验证用户的唯一因素时,我们可以降低保持密码易于检索或重置的固有风险.
17> Steven Sudit..：
对不起,但只要你有办法解密他们的密码,就没有办法确保它的安全.很痛苦,如果你输了,CYA.
18> Dmitri Zaits..：
刚刚遇到了这个有趣而激烈的讨论.最令我惊讶的是,对以下基本问题的关注很少:
Q1.用户坚持访问纯文本存储密码的实际原因是什么？为什么这么有价值？
用户年龄较大或年轻的信息并不能真正回答这个问题.但是,如果没有正确理解客户的关注,如何做出商业决策呢？
现在为什么重要？因为如果客户要求的真正原因是难以使用的系统,那么解决确切原因可能会解决实际问题吗？
由于我没有这些信息而无法与这些客户交谈,我只能猜测:这是关于可用性,见上文.
我见过的另一个问题是:
Q2.如果用户首先忘记密码,为什么旧密码很重要？
这是可能的答案.如果你有一个名为"miaumiau"的猫,并且使用她的名字作为密码但忘了你做了,你是否愿意提醒它是什么或者更确切地说是发送了类似"#zy*RW(ew"？
另一个可能的原因是用户认为提出新密码是一项艰苦的工作!因此,将旧密码发送回去会产生一种错觉,即将她从那次痛苦的工作中拯救出来.
我只是想了解原因.但无论原因是什么,这都是不能解决原因的原因.
作为用户,我希望事情简单!我不想努力!
如果我登录新闻网站阅读报纸,我想输入1111作为密码并通过!
我知道这是不安全的,但我关心有人访问我的"帐户"？是的,他也可以阅读新闻!
该网站是否存储我的"私人"信息？我今天读的新闻？然后这是网站的问题,而不是我的!该网站是否向经过身份验证的用户显示私人信息？然后不要在第一时间显示它!
这只是为了证明用户对问题的态度.
总而言之,我不认为如何"安全地"存储纯文本密码(我们知道这是不可能的),而是如何解决客户的实际问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 