system: [SYSTEM]

user: 2. 背景知识 这里，我们对基于honeyword的认证技术进行简短的介绍，以及一些与此技术相关的问题，这有助于理解我们的方案。 2.1. 基于Honeyword的认证技术 在表1中，我们给出了一些本文使用的相关名词及其注解。 从本质上来说，honeyword技术背后的思想是：生成虚假口令——被称为honeyword——使这些口令与每个帐户都关联起来。当攻击者得到口令列表后，即便她将口令列表中的大部分或者全部哈希值逆转为明文，她依然无法确定列表当中的哪个口令才是用户真正的口令。因此，当攻击者贸然用honeyword尝试访问系统时，系统管理员就可以探测到这种恶意行为。 Table 1 Annotatio 符号 含义 H( ) 用来计算口令哈希值的密码学哈希函数 u i 第i个用户的用户名 p i 第i个用户的口令 W i 第i个用户的口令列表 k W i 中元素的个数 c i 第i个用户的真正口令在列表W i 中的索引 Gen(k) 用来生成含有k个元素的列表W i 的方法 sweetword W i 中的每个元素 sugarword W i 中的正确口令 honeyword W i 中的每个虚假口令 表1. 注释表 Honeyword的工作机制简述如下：对于每个用户 u i ，系统调用honeyword生成算法 G e n ( k ) 生成一个sweetword列表， W i 。方法 G e n ( k ) 输入参数为 k ，即想要生成的sweetword的个数；输出结果为sweetword列表 W i = ( w i ， 1 ， w i ， 2 ， ⋯ ， w i ， k ) 和 c i ，其中 c i 为第 i 个用户的真正口令(sugarword)在列表 W i 中的索引。其中，用户名 u i 和sweetwords的哈希值组成一个元组 〈 u i ， ( v i ， 1 ， v i ， 2 ， ⋯ ， v i ， k ) 〉 存在主服务器上，而 存在另一个被称为“honeychecker”服务器上。通过将系统中的私密信息多元化——将口令的哈希值存在一个服务器上，将 c i 存在honeychecker上，攻击者就难以将整个系统作为一个整体攻破。换句话说，就是提供了基本形式上的分布式安全。需要强调的一点时，传统的口令认证方案中，每个帐户存储的是用户名 u i 和口令 p i 的哈希值 H ( p i ) 的键值对，即 〈 u i ， H ( p i ) 〉 ，而基于honeyword的认证方案中，数据库中存储的是用户名 u i 和sweetwords的哈希值列表 V i 构成的元组，即 〈 u i ， V i 〉 ，其中 V i = ( v i ， 1 ， v i ， 2 ， ⋯ ， v i ， k ) 。honeyword方案中用户的登录过程如下： 1) 用户 u i 输入口令 g 登陆系统。 2) 服务器首先检查 H ( g ) 是否在列表 V i 中，如果不在，则拒绝访问。 3) 如果 H ( g ) 在列表 V i 中，系统则进一步检查 g 到底是honeyword还是sugarword。 4) 假设 v i ， j = H ( g ) ，即 H ( g ) 在列表 V i 中，且是 V i 中第 j 个元素。 j 的值通过确保安全的信道传送给honeychecker。 5) honeychecker检验 j 是否和 c i 相等。如果相等，则返回TRUE；如果不想等，则返回FALSE并根据系统既定的安全策略触发警报。 在进一步讨论honeyword生成方法之前，我们需要先对honeyword的生成算法 G e n ( ) 进行说明。需要注意的是，honeyword的优点、有效性和 G e n ( ) 是如何构造的息息相关。因此，honeyword的作者引入了一个新的定义—— G e n ( ) 的flatness——来度量攻击者从sweetwords中选中正确口令的可能性大小。换句话说，如果honeyword生成方法是 ϵ − f l a t ，那么攻击者就有至少 1 − ϵ 的可能选中honeyword。例如，若 ϵ = 1 / 4 ，那么攻击者从 W i 中选中正确口令 p i 的可能性至多为25%。简而言之，如果算法不够平滑(flat)，那么真正的口令与剩下的虚假口令相比就很显眼，攻击者就可以轻易的发现哪个是用户的原始口令。 2.2. 引入Honeyword的主要问题 基于honeyword的认证技术可以认为是对基于口令的认证技术的一种扩展。因此，人们对于基于honeyword的认证技术的接受程度主要取决于它如何在安全性和适用性上取得平衡。基于honeyword的认证技术需要额外的大量空间用于维护honeywords，所以空间开销也对其接受程度产生了影响。下面，我们讨论了主要问题当中和存储空间、安全以及适用性相关的某些问题。 1) 存储开销：现有的honeyword生成方法中，大多数需要在系统中为每个用户的帐户存储 k − 1   ( k ≥ 2 ) 个honeyword。因此，一个拥有N个用户的系统需要额外存储 N × ( k − 1 ) 大小的信息。假设 h 是口令哈希值的字节数目。如果系统采用流行的哈希技术，譬如：SHA-1，那么h的值就是20字节。考虑到Juels和Rivest在 [ 15 ] 推荐的k大小为20，那么每个用户的存储开销就要增加380个字节。近来的研究工作也都证实了存储开销是基于honeyword的认证技术的一大缺点 [ 15 ] [ 16 ] 。 2) 相互关联风险：在用户名和口令之间可能存在着关联。例如，如果用户选择“姚明”作为用户名，用“basketball”作为口令，那么着两者之间就存在着关联。在此种情境下，honeyword起不到掩盖原始口令的作用。 3) 易辨识的知名口令模式：如果用户选择的口令是和一些众所周知的事物、事实相关的，也非常容易从sweetword列表中被辨认出来。属于此类的口令像bond007，james007，007bond，007007等。这些例子是从10，000个最常用的口令 [ 17 ] 中挑选出来的。 4) 拒绝服务式攻击抗性相关问题：在没有得到口令文件 F p 的前提下，攻击者如果能够猜中任何honeyword，那么这种基于honeyword的认证方案就是一种拒绝服务式攻击抗性较弱的方案。为了猜测用户 u i 的honeyword，攻击者必须要事先知道用户 u i 的真正口令。在已知正确口令信息的前提下，攻击者若能成功猜中honeyword，那么攻击者就可以蓄意使用honeyword进行登录，让系统错误的以为口令文件 F p 已经被盗取了，而事实并非如此。一旦系统感应到某个用户用honeyword尝试访问系统了，它可能会按照既定的预警策略对每个用户进行封锁，这样十分影响用户体验。为了发起拒绝服务式攻击，攻击者可能会先进行观察攻击 [ 18 ] 或者自己去注册一个帐户，从而得到原始的口令信息。 5) 多系统薄弱性相关问题：大部分人在不同的系统帐户中使用相同的口令，近来的关于口令泄漏事件的报道几乎都支持这一事实 [ 19 ] 。用户 u i 提交了口令 p i 用于注册之后，系统根据原始口令 p i 生成列表 W i ，其中包含honeywords和用户的真正口令 p i 。即使用户在两个系统提交的口令 p i 相同，但是任何honeyword生成算法的基本特性之一就是每次运行生成的honeywords是不能完全相同的。因此，即使使用相同的口令 p i ，不同系统上的 W i 列表也是不同的。假设攻击者成功的获取了这两个系统的口令文件 F p 对同一用户的两个 W i 列表进行集合的交集运算，得到该用户真正口令的概率就非常大。这就是所说的基于honeyword的认证技术中的多系统薄弱性问题。 6) 更改系统用户界面：现有的基于honeyword的认证方案中，为了取得更好的flatness，需要对系统原本的用户界面进行更改。比如：加尾巴、密码圆盘、基于问卷调查的方案等。若是现有的系统想要部署这些方案，就必须对系统界面进行更改，可能需要用户额外花费一些时间才能弄明白如何注册系统，以及应该记住哪些改动，以便下次能够成功登录。所以这些方案大大降低了方案的适用性，没能较好的平衡适用性和安全性。 7) 系统对用户的干扰和用户的记忆压力：这是两个和适用性相关的互补标准。在Juels和Rivest的工作中 [ 15 ] ，作者阐明为了满足honeyword方案的安全性要求，某些基于honeyword的方案会干扰用户对于口令的选择(例如，让用户选择距离满足距离测量函数的尾巴)，强制用户记忆系统产生的信息(额外记忆尾巴，记忆问卷的答案等)。这些额外的信息是被系统用来生成honeywords的。因此，一个基于honeyword的认证方案，一旦有系统扰动，就意味着要对用户增加额外的记忆压力。总的来说，此类系统已经明示了它们采用了honeyword技术，而且需要和用户进行额外的交互、影响用户对口令的选择。