SoK: Password-Authenticated Key Exchange – Theory, Practice, Standardization and Real-World Lessons （翻译：第一节）

Abstract：

• Recently, Juels and Rivest proposed honeywords (decoy passwords) to detect attacks against hashed password databases.

  最近，Juels和Rivest提出honeywords（仿真口令（decoy passwords））用来检测对哈希密码和数据库的攻击

• 对于每个用户的账户，正确的（legitimate）口令和集合虚假的honeywords被储存在一起，为了感知模仿（sense impersonation）

  • 如果攻击者选择了正确的honeywords部分，他仍然不能确定是否拿到的这份哈希口令到底是这个账户的真实密码还是这个账户中存在的欺骗密钥

  • 此外，使用这个honeywords登录还会引起警报，通知管理者这部分的口令存在文件泄露风险（a password file breach）

  • 这位作者以存储开销需求增加20倍为前提，介绍了一个简单而有效的检测口令文件泄露（disclosure）事件的解决方案

• 在这份研究报告中，我们将仔细审视（scrutinize）honeywords系统并且给出针对可能存在的疏漏提出一些评论

• 此外，我们还提出了一种替代方法，即从系统中现有的用户密码中选择honeywords，以提供真实的honeywords（一种完全无序（plat）的honeywords生成方法），并降低honeywords方案的存储成本

1. Introduction

• 口令文件泄露是一个会影响千百万用户以及许多像雅虎、RockYou、LinkedIn、eHarmony和Adobe这些公司的严重问题，因为泄露的（leaked）口令会导致这些用户遭到可能更多（many）攻击
  • 近来的一些事件也已经表明（demonstrated）许多网站现今仍然采取脆弱的口令存储方式（weak password storage）
    • 例如，LinkedIn口令使用不加盐的SHA-1算法（the SHA-1 algorithm without a salt）；类似的事情也发生在eHarmony身上，eHarmony也使用不加盐的（unsalted）MD5哈希来存储口令
  • 然而（Indeed），在过去我们就能通过使用的密码破解方法（cracking techniques）（像是Weir等人的算法），简单地取得（capture）大多的口令的明文
• 在这个方面（respect），要克服上述我阐述的这些安全问题有两个议题是需要考虑的：
  • 首先，口令必须通过适当的安全机制（appropriate precautions）保护起来，并且储存它们在进行加盐（salting）或者其它复杂机制（complex mechanisms）计算得到的结果
    • 之后（hence），我们必须确保对破译者（for an adversary it）来说反转哈希（invert hashes）来获得明文是困难的
  • 第二个关键是在于，一个系统应当去检测口令文件泄露事件（incident）是否发生了，否则就无法在适当时期采取相应的行动
    • 在这个研究中，我们集中探讨后一问题，通过虚假口令或账户（fake passwords or accounts）简单应对这一问题，并且给出一个在高成本效益之下仍能进行口令检测的解决方案（cost effective solutions to detect compromise of passwords）
    • "蜜罐"（honeypot）是其中一种识别（indentify）数据库泄露的方式
      • 在这种途径（approach）中，管理员能够有意识地（purposely）创建些虚假（deceit）用户账户来诱导攻击者，并且如果当某一个的“蜜罐”口令被使用了都会检测到口令泄露
      • 这个想法被Herley和Florencio修改，用于对抗口令暴力攻击（password brute-force attacks）保护线上银行业务
      • 根据这项研究，每个试图使用某些口令进行错误登录（ incorrect login attempts with some passwords）的用户都会被引入“蜜罐”账户中，这就是恶意行为识别（malicious behaviour is recognized）
      • 在这个例子中，对于一个8位的口令共有${10}^8$种可能，让系统用10000个错误口令连接到“蜜罐”账户中，如此攻击者进行10000次brute-force attack，比起真实的（genuine）账户，他们更有可能攻击到“蜜罐”账户
    • Bojinov等人在 [8] 中引入了用于建立防盗机制（theft-resistant）的诱饵，称为Kamouflage（瑞典语的“伪装”）
      • 在这个模型中，虚假的口令套件（password set）和真实的口令套件储存在一起，以此来隐藏真实的口令
      • 通过此种方式（thereby），迫使攻击者不得不在获取正确的信息前，执行（carry out）一连串必须深思熟虑的网络操作
    • 在最近，Juels和Rivest也已经呈现了一种honeyword的机制，用于检测正在尝试用破译口令（cracked passwords）登入攻击者身份
      • 其主要是，对于每个用户名设置了一组sweet words；如此，在其中就只有一个元素是正确的口令，并且其他的都是honeywords（陷阱口令）
      • 因此（hence），当一个攻击者尝试键入honeyword就会触发系统对于口令泄露的警报
      • 这种方法的细节会在下一节给出
  • 本研究中，我们分析了honeyword各种实现方法，并给出一些关于系统安全性的评价
    • 而且（furthermore），我们指出了该方法的关键是honeywords的产生算法，这种算法会使honeywords与正确口令难以区分（indistinguishable）
    • 进一步地，我们提议一种使用系统中其它用户口令作为honeywords套件的新方法，即提供真实的honeywords
      • 此外，相较 [9] 中的honeyword实现方式相比较，我们所述的技术也减少了存储空间的消耗
    • 本文的剩余部分组织如下：
      • 第二节，我们回顾honeyword的各种实现方式，并且探讨honeyword生成步骤
      • 第三节，检验honeyword的安全性
      • 第四节，给出我们所提出的模型更为详细的描述
      • 第五节，我们分析这个模型的安全属性
      • 第六节，我们会呈现我们的模型与原本方法的比较情况
      • 最后在第七节中，我们会总结整篇文章

2. Honeywords

• 在本节中，我们第一次简要地概括由Juels和Riverst在 [9] 中提出的“蜜糖口令”（honeyword）的口令模型
• 之后，我们总览（overview）产生在那项研究中给出的产生honeywords方法，并讨论其导致了安全问题的关键部分

2.1 重温Honeywords

• 主要地，隐含在这项研究背后的其实是个简单而杰出（clever）的想法，插入伪口令（false passwords）——honeywords（与每个用户都有联系的账户）

  • 当攻击者取得口令表单，他在其中找到一个账户存在多口令候选的情况，并且他不能确定哪一个是真实的
  • 因此，如果对攻击者honeyword诱导系统就绪了，泄露口令文件的情况就会被系统管理员检测到
  • 我们使用符号（notation）和定义简单描述了honeyword方案并将其以图表呈现在表1中

• 表1

符号	释义
$H()$	密码学的哈希函数
$u_i$	第$i$个用户的用户名
$W_i$	$u_i$表对应潜藏的口令
$k$	$W_i$中的数字元素
$c_i$	表$W_i$中正确口令项的游标（index）
$Gen(k)$	用来产生长度为$k$的$W_i$sweetwords的生成函数
sweetword	每个$W_i$中的元素
sugarword	$W_i$中正确的口令
honeyword	$W_i$中伪造的（fake）口令

• honeyword机制工作原理简单如下：
  • 对于每一个用户$u_i$，会使用honeyword产生算法$Gen(k)$来产生sweetword表$W_i$
    • 此步骤使用输入的$k$作为sweetwords的数量，并且输出口令表$W_i=(w_{i,1},w_{i,2},...,w_{i,k})$和$c_i$，其中的$c_i$指的是正确的口令（sugarword）
    • 由用户名和对sweetwords的哈希值组成一个元组$<u_i,(v_{i,1},v_{i,2},...,v_{i,k})>$，将其保存在主服务器（the main server）的数据库中，而（whereas）$c_i$被储存在另外的服务器中并称其为honeychecker
    • 通过在系统中传递私密信息——储存口令哈希在一个服务器且$c_i$在honeychecker中，使得整个系统更加难以被攻破（compromise），这也就是分布式安全的基本形式（procides a basic form of distributed security）
  • 另提出一种传统的口令技术，将$<u_i,H(p_i)>$（用户名和其口令的哈希）对作为一个账户进行储存，而在系统中，$<u_i,V_i>$元组被保存在数据库中，其中的$V_i=(v_{i,1},v_{i,2},...,v_{i,k})$。其方案登陆步骤如下列概括内容：
    • 用户$u_i$键入口令$g$来登录系统
    • 服务器首先检查是否$H(g)$在表单$V_i$中
      • 如果不在，那么登录失败（login is denied）
    • 否则，系统会核实$g$是honeyword还是正确的通过口令
      • 让$v(i,j)=H(g)$（寻找到符合此条件的$j$），之后$j$值会被送到honeychecker进行身份认证的安全通信（an authenticated secure communication）
      • honeychecker检查$j=c_i$
        • 如果上述等式成立，那么其会返回TRUE
        • 否则，其会回应FALSE并且可能会根据系统安全措施（security policy of the system）产生警告
• 在探讨honeyword产生方式前，我们想先讨论honeyword产生算法$Gen()$
  • 请记住，长度与有效程度确实和$Gen()$如何构造是直接相关的
    • 而（therefore）因此笔者会从此方法采取应对检测攻击者sweetword guessing措施的时机（chance）来介绍在$Gen()$函数定义中的混乱度（flatness）
    • 换句话说（in other words），如果一个honeyword产生方法是$ϵ-flat$的，那么攻击者至少是有$1-ϵ$的概率拿到其中一个honeyword
      • 比如，攻击者有最多25%的概率拿到正确口令（记为$p_i$），那么在$W_i$中$ϵ=\frac{1}{4}$
      • 简单地说，如果这个生成算法不足够朴素（混乱？flat），那结果就是真实口令在其它虚假的口令中显得格格不入，而攻击者也就能简单地让原始口令（the original）曝光

2.2 Honeyword 产生算法及探讨（Discussions）

• 笔者在 [9] 中对各类 honeyword 产生方式划分成两类

  • 第一类是由UI保留（legacy-UI（UI：用户接口））操作（procedures）组成
  • 第二类包含了修改的UI（modified-UI）操作（这类操作是可以进行口令修改（password-change）的用户接口方法），其允许生成更优质的（better）的口令/honeyword
    • 后一（take-a-tail）方法的例子将会在介绍第二部分给出
  • 根据这样的方式，可以为用户生成随机性尾部并选择添加后缀到用户键入的口令尾部，并且最后（the result）生成用户的新口令
    • 举个例子（for instance），让用户键入口令games01，并且之后系统让413作为尾部
      • 那么用户的口令现在就会变成games01413
    • 尽管这种方式增强了口令的安全性，可是在我们的观念中，这是不切实际的（impractical）——用户经常会忘记他们挑选的（determined）口令
    • 之后（therefore）在对其他部分（remaining parts）进行分析时，我们进行的仅局限于UI保留部分的操作
  • 请记住，一些我们讨论的部分其实在 [9] 中就提到过，而我们在此强调（emphasize）这些，实际上是为了表明选择生成算法是相当重要的（address paramount importance）

• Chaffing-by-tweaking 方法：

  • 在此方法中，用户口令种子（seeds）生成算法会在原口令之上对选定的字符位置稍作调整（tweak），以此生成honeywords

    • 例如（for instance），每个用户口令中先前位置的（in predetermined positions）字符会被随机选定的相同类型（the same type）字符替代
    • 相同类型：数字被数字替代，字母被字母替代，特殊字符被特殊字符替代
    • 数字的位置会根据系统提供的 $t$ 进行调整（tweak）
      • 例如：$t=3$，那么这种产生算法$Gen(k,t)$会调整至少 $t$ 个字符
    • 在此研究中，另一种方式被称为“数字调整的玩笑”（chaffing-by-tweaking-digits）通过对至少 $t$ 个包含数字的位置执行调整来实现
      • 例如：通过后一种方式对口令42hungry和$t=2$进行操作，就可以（may）生成honeywords（12hungry和58hungry）

  • 备注1：

    • 许多用户有选择与日期相关数字的偏好（propensity）

      • 例如：生日、周年庆或是发生了重大事件的日子

      • 现实中有个例子，3.6%被骇入的（hacked）Adobe口令提示就是日期

      • 鉴于这一事实（In the light of this fact），口令中可能大量存在（involve）像19xx、20xx或者xx（xx是两位日期的数字）的数字序列

      • 对于这些口令使用chaffing-by-tweaking-digits方法

        • 其中的日期数字将会被随机选中的数字替代
        • 因此拥有用户$u_i$的$W_i$的攻击者可以简单地辨识出honeywords，并且得到正确的口令

      • 当我们公开检查可能（available）被从RockYou泄露的口令时（大约进入了3千2百万个账户），我们发现许多用户使用这样的格式：

        • 像是june$xxxx$形式，此格式被1244个用户使用，这里的$xxxx$是一个日期，由19或者20开头

        • 另一种应该是口令的类似alex1992，看起来在RockYou的口令清单上出现了47次

          • 其生成的口令$t=4$和$t=9$就是honeywords（alex1270和alex9705）

          • 请记住，honeywords看起来是没有意义的，但是正确的口令在攻击者看来就不一定了（make sense）

      $$\begin{array}{ccc}alex6323& alex9058& alex1992\\ alex1270& alex0976& alex2785\\ alex5469& alex8147& alex9705\end{array}$$

    • 使用日期作为口令的只是其中一部分，许多用户还偏好将投几个连续的数字作为口令，像是‘123’、‘1234’，其原因是用户的倾向（tendency of users）总是选择容易记得的（rememberable）口令形式

    • 通过考量（considering）RockYou泄露的口令数据库，我们意识到大约0.8%的用户的口令是包含以'1000'开头、以’123‘或者’1234‘结尾并且至少有一个字母作为开头的

      • 带有上述日期模式的漏洞也适用于这些密码，这都是攻击者可以从sweetwords中只需要稍加研究下结尾数字形式就可以得到正确口令的

    • 的确，chaffing-by-tweaking方法会受到各种形式口令的影响（suffer from），因为随机替换相同类型字符会给攻击者提取（extracting）正确口令的提示

      • 用户群体中存在可以迁移（extending）的数字选择习惯
      • 从更广泛视角观察这些例子，用户大多数是不会随机数字和字母组合的
      • 所以，进行随机替换的技术（像是这个模型）会让攻击者选择一个更为可靠的（natural）（口令）目标
      • 另一方面，我们认为（believe）通过部署chaffingby-tweaking模型，是很难实行honeyword方案的，毕竟所有攻击者都可能用人的思维考虑问题