如何实现安全密码历史记录

柔情只为你懂 2023-09-25 12:59 133阅读 0赞

出于明显的安全原因，密码不应以纯文本形式存储：您必须存储哈希，并且还应仔细生成哈希以避免彩虹表攻击。

但是，通常您需要存储最后 n 个密码，并在不同密码之间强制实施最小的复杂性和最小更改（以防止用户使用 Password\_1、Password\_2、...、Password\_*n*） 等序列。这对于纯文本密码来说是微不足道的，但是如何通过仅存储哈希来做到这一点呢？

换句话说：如何实现安全的密码历史记录机制？

*  [安全][Link 1]
 *  [密码][Link 2]

[共享][Link 3]

[改进此问题][Link 4]

跟随

提问Nov 27， 2012 在 15：19

[正在上传…重新上传取消][Link 5]

[向导79][Link 5]

**7,307**22枚金牌4040枚银牌7676枚铜牌

*  2
    
    相关：[security.stackexchange.com/questions/4704/...][security.stackexchange.com_questions_4704_...]（顺便说一句，该网站可能是这个问题的更好位置）。就“最小变化”而言，我想不出任何替代方案来生成所有符合“最小变化”条件的选项（根据您的定义，这可能是很多！）并比较哈希值。“最小变化”的定义是什么？ 
    
    – [凯文·维米尔][Link 6]
    
     十一月 27， 2012 在 15：25 
 *  7
    
    存储最新的*n*个密码仅意味着用户将选择从 1 到*n+1* 的序列。 
    
    – [约阿希姆·绍尔][Link 7]
    
     十一月 27， 2012 在 15：38
 *  11
    
    我非常怀疑这样的密码策略是否可以提高安全性;恕我直言，它增加了人们诉诸于将密码保存在便笺上的机会。凯文的链接是一个很好的讨论。@KevinVermeer - 您实际上可以将变化量测量为 Levenshtein 距离 （[en.wikipedia.org/wiki/Levenshtein\_distance][en.wikipedia.org_wiki_Levenshtein_distance]），也称为“编辑距离”。 
    
    – [内森·朗][Link 8]
    
     十一月 27， 2012 在 17：03
 *  5
    
    如果您的安全性如此严格，那么您也可以为用户生成一个随机密码，强制他们使用它，并定期更改它。这样您就可以完全控制他们的密码。 
    
    – [反应古拉尔][Link 9]
    
     十一月 27， 2012 在 17：59
 *  2
    
    @nathan：将密码存储在便笺上实际上是安全的。除非您可以物理访问便笺，否则无法攻击密码 - 消除了大约 99% 的威胁。把那张纸条放在钱包或钱包里，你基本上需要把这个人抢走才能得到它——这意味着安全漏洞被识别出来并且可以得到缓解。 
    
    – [马特茨][Link 10]
    
     十一月 27， 2012 在 20：34

[显示7更多评论][7]

### 5 答案 ###

排序方式：

最高分（默认） 修改日期（最新的在前） 创建日期（最早的在前）

存储哈希并根据这些存储的哈希验证输入的密码，就像登录时验证密码一样。您必须根据数字模式从给定的密码中生成“替代”密码，以检测您的“最小”更改。

登录时，您已经根据哈希验证输入的密码，无需以明文形式存储密码。在更改密码时，同样的技巧也有效，只需根据历史哈希检查输入和“最小更改”生成的密码即可。如果新密码令人满意，请将当前密码哈希移动到历史集，并将其替换为新密码的新哈希。

[共享][Link 11]

[改进此答案][Link 12]

跟随

[编辑于2012年11月27日 15：29][2012_11_27_ 15_29]

回答日期十一月 27， 2012 在 15：20

[正在上传…重新上传取消][Link 13]

[马丁·皮特斯][Link 13]

**14.1千米**1010枚金牌5656枚银牌5757枚铜牌

*  因此，如果用户输入密码6，我应该检测数字部分，并尝试例如密码4，密码*5，**密码7*等。这是对的吗？ 
    
    – [向导79][Link 5]
    
     十一月 27， 2012 在 15：47
 *  4
    
    @Lorenzo：正确。生成替代方案可以像您想要的那样复杂，只要确保您在复杂性和风险之间找到正确的权衡（不要让您的用户等待 5 分钟，同时检查所有可能性，并消失风险的可能性）。 
    
    – [马丁·皮特斯][Link 13]
    
     十一月 27， 2012 在 15：49 
 *  我不确定建议在末尾指控数字是否对用户提出一个好建议 - 这只是一点点可预测的。如果您告诉用户这样做，则会成倍增加。 
    
    – [怀亚特·巴内特][Link 14]
    
     十一月 27， 2012 在 16：01
 *  2
    
    @WyattBarnett：没有人告诉用户这样做。关键是*检测*用户这样做并防止使用“递增”密码。 
    
    – [马丁·皮特斯][Link 13]
    
     十一月 27， 2012 在 16：11
 *  啊，这里完全看错了什么。不好意思。 
    
    – [怀亚特·巴内特][Link 14]
    
     十一月 27， 2012 在 16：28

[添加评论][7]

当用户更改其密码时，要求他们输入以前的密码。您现在可以访问*两个*纯文本密码，即使您没有在数据库中存储纯文本密码也是如此。

对这两个密码执行您想要的任何验证。这不会阻止用户在两个密码之间交替（带有后缀 - 您可以根据其他答案中的建议防止直接交替），但它会防止更明显的情况。

[共享][Link 15]

[改进此答案][Link 16]

跟随

回答日期十一月 27， 2012 在 15：47

[正在上传…重新上传取消][Link 17]

[布莱恩][Link 17]

**4,470**11枚金牌2020枚银牌3737枚铜牌

*  好吧，如果您不需要针对以前的*n*个密码进行测试，这当然是一个聪明的解决方法，但是及时生成替代方案的建议更好。但是生成两个密码的替代方案甚至更好！ 
    
    – [向导79][Link 5]
    
     十一月 27， 2012 在 16：03
 *  2
    
    @Lorenzo：这个想法是，你对前面的n个密码进行直接测试，对最后一个密码进行更强的测试。这是一种妥协。 
    
    – [布莱恩][Link 17]
    
     十一月 27， 2012 在 16：06
 *  是的。如果他们当前的密码是`potatoSalad1`，并且他们想要更新到`potatoSalad2`，那么您会告诉更改太小，因为此时您同时拥有纯文本密码。但再往前追溯，你只有哈希，哈希的本质是你无法判断两个哈希是有相似还是完全不同的纯文本作为输入。 
    
    – [内森·朗][Link 8]
    
     十一月 27， 2012 在 16：56

[添加评论][7]

为了补充@martijnPieter的答案，可以通过基于新密码和旧密码（你们都有可用的密码）进行短暂的暴力破解来实现最小的更改

例如，您可以遍历与新密码相距为1 或 2 的所有密码，并查看它是否与旧密码匹配

但您可能要注意，这会降低用户对您正在散列密码的信心（因为您实际上是在说您可以取回以前的密码以拒绝新密码）

[共享][Link 18]

[改进此答案][Link 19]

跟随

回答日期十一月 27， 2012 在 15：40

[正在上传…重新上传取消][Link 20]

[棘轮怪胎][Link 20]

**25.5千米**22枚金牌6161枚银牌9797枚铜牌

*  但是有许多序列具有较大的汉明距离，例如2012年2月-2012年3月>日或星期五-09-28-12->周二-11-27-12（日期），Password\_Alpha-> Password\_Beta，Pass\_1111-> Pass\_2222，Pass\_qwer，Pass\_tyui，传球，\_op\[\]或十一->十二（交替计数系统），或弗兰克史密斯 ->弗雷德琼斯 ->修士塔克或愤怒 ->动物 ->苹果（公司目录中的名称或字典中的单词），具有先前密码的攻击者可以轻松猜到，但是您的算法将很难生成。 
    
    – [凯文·维米尔][Link 6]
    
     十一月 27， 2012 在 16：00 
 *  然后@KevinVermeer考虑变体生成器中的那些，并接受你永远不会得到一切 
    
    – [棘轮怪胎][Link 20]
    
     十一月 27， 2012 在 16：07
 *  \+1 降低置信度。当我看到有人告诉我我的密码太像我三个月前使用的密码时，我立即想知道他们是否正在可逆地存储它们......或者如果他们有一个很棒的程序员。怀疑主义通常会获胜。 
    
    – [蒂姆·波斯特][Link 21]
    
     十一月 28， 2012 在 1：58

[添加评论][7]

这实际上更像是对@Brian聪明答案的补充。还要向@Martijn Pieters致敬，因为他们添加了有关如何根据当前密码暴力破解旧密码的详细信息，并@ratchet“汉明距离”的怪胎。我不删除我的答案，因为我认为它提供了有趣的背景来支持它们。

最先进的密码存储需要为每个用户使用多轮强大的单向加密哈希 （SHA-512+） 和唯一的盐 （128 位+）。但不要试图存储有关每个密码的其他信息。您存储的有关每个密码的信息越多，对哈希算法安全性的破坏就越大。

## 例 ##

如果您知道以下情况，请考虑暴力破解密码变得多么容易：

*  它有 7 个字符长
 *  字符 3-5 为大写（4 为小写）
 *  1 和 7 是数字
 *  6是一个符号

美式键盘有 95 个可打印字符，因此知道密码长度为 7 个字符会产生 95^7 = 69，833，729，610，000 = 7x10^13 排列。如果它真的是随机的，可能需要一年的时间才能在单个3Ghz处理器上破解它。但：

*  只有 26 个大写字符和 26 个小写字符
 *  只有 10 位数字为这两个数字产生 100 种可能性
 *  只有 32 个符号

所以（由于@Hellion而更正）：

26^4 (charcters 2-5 are known upper or lower-case)
            x 100 (characters 1 & 7 are digits)
            x  32 (character 6 is a symbol)
             ====
    1,462,323,200 possible passwords.

破解起来要容易5万倍！在这种情况下，存储良好的信息以防止类似的密码，已经将7个字符的密码的破解时间从一年缩短到几个小时。在功能强大的多处理器台式机上使用良好的视频卡和一点耐心解码所有密码现在非常可行。我希望这个简单的例子表明，您比较类似密码越有意义，您的哈希就越不安全。

## 强哈希的重要性 ##

带有密码的数据库经常被盗，每个月都有巨大的闯入新闻。哎呀，就在上个月，[南卡罗来纳州失去了每个人的社会安全号码][Link 22]——哎呀！这些违规行为还有多少被掩盖？

## 结语 ##

对我来说最可怕的事情是当人们为多个站点选择相同或相似的密码时，因此闯入一个站点可以让攻击者访问所有站点。我很想看到一种行之有效的方法来防止这种情况，尽管我认为防止最常见的错误密码比防止单个用户在同一站点中重复使用他们的错误密码更有帮助。我能建议的最好的是公司范围内的策略，使用安全的密码管理器，为每个用户生成高度随机的密码并安全地存储它们。

[共享][Link 23]

[改进此答案][Link 24]

跟随

[编辑于Jun 16， 2020 在 10：01][Jun 16_ 2020 _ 10_01]

社区维基

[12 转格][Jun 16_ 2020 _ 10_01]  
[伦彼得森][Link 25]

*  1
    
    次要 nit：密码可能性仍然是乘法的，所以它是 （26^4） \* 100 \* 32 = 1，462，323，200。如果我们假设破解（95^7）可能性需要一年时间，那么破解这种较少的可能性大约需要11分钟。 
    
    – [坏人][Link 26]
    
     十一月 27， 2012 在 22：01
 *  @Hellion - 哎呀！感谢您指出这一点。我已经纠正了它。 
    
    – [格伦彼得森][Link 27]
    
     十一月 28， 2012 在 19：40

[添加评论][7]

首先，您可以存储最后“n”个先前密码的哈希值，以便检查其新密码是否与以前的密码重复。您还拥有其当前密码的纯文本（因为他们已登录或向您提供密码以验证其密码更改请求）及其新密码，因此您可以检查这两个密码之间的最小更改。

如果（对您来说）直接将这两个密码与“n”以前的密码进行比较非常重要，那么您必须存储这些密码（加密）以便以后能够检索它们。

虽然这样做可能被视为安全漏洞，但可以实施加密方法来提供足够的安全性。

1.  存储每个密码（加密），用于最后的“n”个密码。
2.  存储创建最新密码的日期和时间。
3.  存储最新密码的哈希值。
4.  使用当前密码的哈希（加盐）和密码创建时间戳（可能还有帐号或电子邮件地址之类的东西）加密所有密码。
5.  每次创建新密码时，取消加密并重新加密所有密码。

然后，无论何时更改密码，您都可以取消加密所有旧密码，并进行所有最小更改测试。

现在，如果有人拥有此人的密码，并且知道所有其他必要的详细信息，他们可以为这个人解密此信息。但是，如果他们已经拥有此人的密码，则他们已经可以以此人的身份登录并访问此人的帐户。

此外，对于旧密码，它们可能不必以严格的纯文本形式存储。它们可以以某种混淆的方式存储。或存储为按字母顺序排列的密码字符列表。

我并不是说在一般情况下这是建议做的事情，但是假设您描述的任务在您的情况下是必需的，那么这是通过一些安全措施完成它的一种方法。

[共享][Link 28]

[改进此答案][Link 29]

跟随

回答日期十一月 27， 2012 在 21：06

[正在上传…重新上传取消][Link 30]

[凯文·费根][Link 30]

**119**33枚铜牌

*  这个答案在安全性方面提出了几个可怕的建议。我们不应该能够轻松解密密码，也不应该以“某种混淆的方式”存储它们，而不是对它们进行强加密。 
    
    – [用户45623][45623]
    
     十月 9， 2015 在 1：39

[Link 1]: https://softwareengineering.stackexchange.com/questions/tagged/security
[Link 2]: https://softwareengineering.stackexchange.com/questions/tagged/passwords
[Link 3]: https://softwareengineering.stackexchange.com/q/177342
[Link 4]: https://softwareengineering.stackexchange.com/posts/177342/edit
[Link 5]: https://softwareengineering.stackexchange.com/users/11/wizard79
[security.stackexchange.com_questions_4704_...]: http://security.stackexchange.com/questions/4704/how-does-changing-your-password-every-90-days-increase-security
[Link 6]: https://softwareengineering.stackexchange.com/users/3781/kevin-vermeer
[Link 7]: https://softwareengineering.stackexchange.com/users/2234/joachim-sauer
[en.wikipedia.org_wiki_Levenshtein_distance]: http://en.wikipedia.org/wiki/Levenshtein_distance
[Link 8]: https://softwareengineering.stackexchange.com/users/7217/nathan-long
[Link 9]: https://softwareengineering.stackexchange.com/users/52871/reactgular
[Link 10]: https://softwareengineering.stackexchange.com/users/24028/mattnz
[7]: https://softwareengineering.stackexchange.com/questions/177342/how-to-implement-a-safe-password-history#
[Link 11]: https://softwareengineering.stackexchange.com/a/177343
[Link 12]: https://softwareengineering.stackexchange.com/posts/177343/edit
[2012_11_27_ 15_29]: https://softwareengineering.stackexchange.com/posts/177343/revisions
[Link 13]: https://softwareengineering.stackexchange.com/users/55400/martijn-pieters
[Link 14]: https://softwareengineering.stackexchange.com/users/3762/wyatt-barnett
[Link 15]: https://softwareengineering.stackexchange.com/a/177349
[Link 16]: https://softwareengineering.stackexchange.com/posts/177349/edit
[Link 17]: https://softwareengineering.stackexchange.com/users/15162/brian
[Link 18]: https://softwareengineering.stackexchange.com/a/177348
[Link 19]: https://softwareengineering.stackexchange.com/posts/177348/edit
[Link 20]: https://softwareengineering.stackexchange.com/users/25768/ratchet-freak
[Link 21]: https://softwareengineering.stackexchange.com/users/131/tim-post
[Link 22]: http://news.blogs.cnn.com/2012/10/26/south-carolina-taxpayer-server-hacked-3-6-million-social-security-numbers-compromised/
[Link 23]: https://softwareengineering.stackexchange.com/a/177360
[Link 24]: https://softwareengineering.stackexchange.com/posts/177360/edit
[Jun 16_ 2020 _ 10_01]: https://softwareengineering.stackexchange.com/posts/177360/revisions
[Link 25]: https://softwareengineering.stackexchange.com/users/62323
[Link 26]: https://softwareengineering.stackexchange.com/users/17326/hellion
[Link 27]: https://softwareengineering.stackexchange.com/users/62323/glenpeterson
[Link 28]: https://softwareengineering.stackexchange.com/a/177408
[Link 29]: https://softwareengineering.stackexchange.com/posts/177408/edit
[Link 30]: https://softwareengineering.stackexchange.com/users/73790/kevin-fegan
[45623]: https://softwareengineering.stackexchange.com/users/167489/user45623