多个骰子商品列表来制作令人难忘的密码?

信息安全 加密 密码
2021-08-26 22:49:14

我了解为什么 diceware 能够产生良好的安全性以及为什么现在七字密码是一个好主意的基础知识。

EFF 已帮助生成更新的 diceware 列表,消除了记忆 diceware 密码短语的许多麻烦。(见https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases

但是,即使使用 EFF 新的长 diceware 列表,七字密码仍然很难记住。当然,随着时间的推移,大多数人会记住它,但我想知道是否没有更简单的方法来实现安全性和记忆性。

(如果这是对更聪明的人已经想到的事情的重述,请提前道歉。)

由于 diceware 列表的知识是无关紧要的,因为只有唯一单词列表的长度对熵有贡献,所以从多个列表中进行选择与从一个列表中反复选择一样安全。

那么为什么不创建四个单独的列表,每个列表有 7,776 个单词,但每个列表都严格限制为 a) 形容词、b) 名词、c) 动词和 d) 副词?

通常会创建一个 diceware 密码,每个单词掷 5 个骰子。

但是,假设我们的目标是七字密码,我们会选择:

列表 a 中的单词 1(形容词)列表 b 中的单词 2(名词)列表 c 中的单词 3(动词)列表 b 中的单词 4(名词)列表 d 中的单词 5(副词)

这将产生如下形式的英语句子:

形容词 名词 动词 名词 副词(例如蓝色壁炉轻快地吃狗)

对于大多数人来说,这可能很奇怪,但也很容易记住(熵不亚于从标准 diceware 列表或 EFF 改进的长 diceware 列表中选择的五个字密码)。

不过,这对于安全性来说还不够长,所以我们可以继续选择:

列表 b 中的单词 6(名词)列表 d 中的单词 7(副词)

产生一个 7 字的密码短语,形式如下:

形容词 名词 动词 名词 副词 名词 副词

在第 5 个和第 6 个单词之间加上一个“and”,这句话可能很容易记住。大概“and”不会降低安全性,因为即使知道它,我们在句子中仍然有 7776^7 个单词组合。

我认为这个方案的最大问题是英语中可能没有 7,776 个副词(或者可能有?)。

在这种情况下,我们仍然可以使用类似的方案,使用仅由形容词(在英语中可能比必要的数量级多一个数量级)、名词和动词列表构成的两个句子,如下所示:

列表 a(形容词)中的单词 1 列表 b(名词)中的单词 2 列表 c(动词)中的单词 3 列表 b(名词)中的单词 4 列表 b(名词)中的单词 6 列表 c(动词)中的单词 7来自列表 b(名词)

如果你愿意,可以在单词 4 和 5 之间加上一个分号或句号,你会得到这样的结果:

形容词 名词 动词 名词 名词 动词 名词 (例如蓝色壁炉吃狗;电视飞披萨)

我推测这些类型的句子对大多数人来说更容易记住,因为它们创造了人们容易记住的动作图像。在上面的例子中,它会是一个蓝色的壁炉吃一只狗,而一台电视机在披萨上飞。

显然,也可以通过在第二句中包含形容词来制作 8 个单词的密码。

这是一个已经探索过的策略吗?

它有已知的弱点吗?

是否有已发布的名词、动词和形容词的 diceware 列表?(还有副词?)

4个回答

虽然他们没有直接回答您的问题,但我认为阅读本网站上的其他一些与密码相关的问题将有助于您思考这个过程。我会很简单地从这个问题开始,这也是这个网站上最受欢迎的问题。总之,这些答案真正打破了相关的安全性和可用性问题:

XKCD #936: 短复杂密码,还是长字典密码?

简而言之(正如您似乎理解的那样),任何密码生成策略最终都归结为熵,可以粗略地理解为“随机性”。从包含 7,776 个单词的单词列表中选择 7 次将给您总共大约 1.719e27 个可能的密码,或大约 90 位熵。您在给定词序的列表之间切换这一事实并没有真正改变图片(从技术上讲,您有更多的词可供选择,但您以可预测的方式在选择列表之间切换)。因此,从严格熵的角度来看,这并不比更标准的 diceware 生成模式更强或更弱。另一方面,如果它更容易记住密码,它至少会是一个可用性改进,

话虽如此,在可预见的未来,两者肯定都“足够安全”。相关的是这个线程谈论具有 80 位熵的密码:

80 位密码是否足以满足所有实际用途?

这着眼于破解密码哈希的实际限制:

https://security.stackexchange.com/a/13016/149676

所有这些都归结为同一件事:用 90 位熵破解密码的成本可能会超过美国的整个经济产出,但您仍然容易受到网络钓鱼、社会工程攻击等的攻击。

你的分析是正确的。唯一的“弱点”是从单个组合列表中选择相同数量的单词(所有不同的词性列表组合成一个大列表),熵在技术上会更高,但假设适当数量的单词额外安全性大多是多余的。

KeePass 有一个“可读密码生成器”插件,我认为它可以做类似的事情。我已经使用带有自定义列表的“单词排序器”插件来完全按照您的建议进行操作,尽管我没有为每个列表找到 7776 个单词。我从 Moby 项目中提取了我的单词列表,该项目有一个可用的“词性”列表。

正如你所说,例如,我认为你无法想出一个精心策划的 7776 个副词列表。

另一种选择是使用较小的单词列表,例如每个单词 1296 个(掷 4 个骰子而不是 5 个)。这将为您提供每个字约 10.34 位的熵,而不是每个常规 diceware 字约 12.92 位。

对于等效输入,您必须记住更长的密码,但由于密码的语法结构,这可能更容易。

一个更复杂的解决方案是通过附加其他字符或大写来实际获得 7776 个精选副词,而不是仅仅

briskly

你会有

briskly
briskly!
briskly?    
Briskly
Briskly!
Briskly?
BRISKLY
BRISKLY!
BRISKLY?

但是,您再次需要权衡复杂性,这与“易于记忆”密码短语的目标背道而驰。

您最好将自己的“填充”词插入常规的 diceware 密码短语中,以便更容易记住。

这是一个已经探索过的策略吗?

是的,语法密码生成器就是基于这个想法。我对那个特定的实现有一些问题,特别是:1)它选择的随机数生成器(Math.random())在密码学上不是安全的,2)它的词表选择是相当随意的,3)它的强度计算可能错了,所以语法骰子的想法并不是全新的。

事实上,我一直在考虑自己的语法 diceware 实现已经有一段时间了,尽管这里最大的障碍是生成一个像 EFF 的词表这样的好的词表。我没有 EFF 必须生成他们的词表的资源和知识。虽然词表的选择并不会真正影响安全性,但一个好的词表会使密码更容易输入和记住。

它有已知的弱点吗?

像 diceware 这样的基于熵的密码生成方法的核心思想是为给定的强度创建一个大数字,然后使用一个词表对该数字进行编码。遵循这种模式的任何方案的安全性主要依赖于随机数的生成,而编码系统非常简单,并且几乎没有警告,并不会真正影响系统的安全性。

† 例如,原始的 diceware 单词表不是无前缀的,因此如果单词之间没有分隔符,它会产生强度降低的密码,这已在 EFF 的单词表中得到修复