Honeyword可以用于提升口令存储的安全性,并能够及时检测口令数据集的泄漏。然而,当前的honeyword生成机制依然存在安全性较弱、占用存储空间过大等问题。为此,本文提出了基于特殊字符间距的虚拟honeyword生成机制。分析结果显示该方案可以显著地减少存储空间开销,并提升安全性和口令集泄漏被检测的概率。 Honeyword can be used to improve password storage security, and timely detect password data set disclosure. Nevertheless, existing honeyword generation schemes are of low security, and require large storage overhead. In this paper, we propose a virtual honeyword generation method based on special character distance. Additionally, our analysis shows that the proposed scheme can dramatically reduce the storage cost, and improve the security and detection probability of password.
荆巍巍1,崔进库2,朱友文2
1南京电子技术研究所,江苏 南京
2南京航空航天大学,江苏 南京
收稿日期:2019年9月18日;录用日期:2019年10月3日;发布日期:2019年10月10日
Honeyword可以用于提升口令存储的安全性,并能够及时检测口令数据集的泄漏。然而,当前的honeyword生成机制依然存在安全性较弱、占用存储空间过大等问题。为此,本文提出了基于特殊字符间距的虚拟honeyword生成机制。分析结果显示该方案可以显著地减少存储空间开销,并提升安全性和口令集泄漏被检测的概率。
关键词 :身份认证,口令,泄漏检测,存储安全
Copyright © 2019 by author(s) and Hans Publishers Inc.
This work is licensed under the Creative Commons Attribution International License (CC BY).
http://creativecommons.org/licenses/by/4.0/
口令文件的泄露是非常严重的安全问题,其影响已经波及到百万用户和相关的公司,比如Yahoo [
更严重的是,探测到这些泄露事件常常是在口令刚被盗取后的几个月,有的甚至是数年。在此期间,攻击者已经挖掘、利用完数据中的信息、把口令文件发布在网上之后,或者是转手卖给了其他人。例如,最近在2017年10月报道的灾难性口令泄露事件,涉及到Yahoo所有30亿用户,然而泄密实际上是在4年前发生的 [
鉴于上述问题,本文提出了一种基于伪造口令或者帐户的方式来实现一种简单可行、经济有效的口令安全存储和泄露预警方案。蜜罐(Honeypot)技术是众多确认口令数据库泄露中的一种。在蜜罐方案中,系统管理员蓄意的创建一些虚假帐户来诱惑攻击者,如果任一虚假帐户被使用了,就可以探测到口令的泄露 [
概括地说,本文提出了一种新的技术——特殊字符间距机制(Special Character Distance Mechanism, SCDM)——来生成honeyword。SCDM不需要对系统的用户接口进行更改,也不需要用户记忆额外的字符。SCDM的部署对用户来说是透明的,因此保证了系统的用户友好性和适用性。SCDM运用少量特殊字符生成honeyword,能够规避口令与用户名的关联问题(例如:bond007)、口令与用户名的关联问题(例如:用户名为James,口令为bond007)。采用我们提出的方案,系统只需要额外存储少量的信息,就可以生成虚拟的honeyword列表,因此极大程度上降低了存储开销。
论文其余部分安排如下。第2部分介绍了honeyword相关的基础知识和背景信息;第3部分详细地展示了我们所提方案的步骤;第4部分对本文所提方案进行了深入分析;第5部分总结了本文。
这里,我们对基于honeyword的认证技术进行简短的介绍,以及一些与此技术相关的问题,这有助于理解我们的方案。
在表1中,我们给出了一些本文使用的相关名词及其注解。
从本质上来说,honeyword技术背后的思想是:生成虚假口令——被称为honeyword——使这些口令与每个帐户都关联起来。当攻击者得到口令列表后,即便她将口令列表中的大部分或者全部哈希值逆转为明文,她依然无法确定列表当中的哪个口令才是用户真正的口令。因此,当攻击者贸然用honeyword尝试访问系统时,系统管理员就可以探测到这种恶意行为。
符号 | 含义 |
---|---|
H( ) | 用来计算口令哈希值的密码学哈希函数 |
ui | 第i个用户的用户名 |
pi | 第i个用户的口令 |
Wi | 第i个用户的口令列表 |
k | Wi中元素的个数 |
ci | 第i个用户的真正口令在列表Wi中的索引 |
Gen(k) | 用来生成含有k个元素的列表Wi的方法 |
sweetword | Wi中的每个元素 |
sugarword | Wi中的正确口令 |
honeyword | Wi中的每个虚假口令 |
表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 ) 〉 存在主服务器上,而
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),那么真正的口令与剩下的虚假口令相比就很显眼,攻击者就可以轻易的发现哪个是用户的原始口令。
基于honeyword的认证技术可以认为是对基于口令的认证技术的一种扩展。因此,人们对于基于honeyword的认证技术的接受程度主要取决于它如何在安全性和适用性上取得平衡。基于honeyword的认证技术需要额外的大量空间用于维护honeywords,所以空间开销也对其接受程度产生了影响。下面,我们讨论了主要问题当中和存储空间、安全以及适用性相关的某些问题。
1) 存储开销:现有的honeyword生成方法中,大多数需要在系统中为每个用户的帐户存储 k − 1 ( k ≥ 2 ) 个honeyword。因此,一个拥有N个用户的系统需要额外存储 N × ( k − 1 ) 大小的信息。假设 h 是口令哈希值的字节数目。如果系统采用流行的哈希技术,譬如:SHA-1,那么h的值就是20字节。考虑到Juels和Rivest在 [
2) 相互关联风险:在用户名和口令之间可能存在着关联。例如,如果用户选择“姚明”作为用户名,用“basketball”作为口令,那么着两者之间就存在着关联。在此种情境下,honeyword起不到掩盖原始口令的作用。
3) 易辨识的知名口令模式:如果用户选择的口令是和一些众所周知的事物、事实相关的,也非常容易从sweetword列表中被辨认出来。属于此类的口令像bond007,james007,007bond,007007等。这些例子是从10,000个最常用的口令 [
4) 拒绝服务式攻击抗性相关问题:在没有得到口令文件 F p 的前提下,攻击者如果能够猜中任何honeyword,那么这种基于honeyword的认证方案就是一种拒绝服务式攻击抗性较弱的方案。为了猜测用户 u i 的honeyword,攻击者必须要事先知道用户 u i 的真正口令。在已知正确口令信息的前提下,攻击者若能成功猜中honeyword,那么攻击者就可以蓄意使用honeyword进行登录,让系统错误的以为口令文件 F p 已经被盗取了,而事实并非如此。一旦系统感应到某个用户用honeyword尝试访问系统了,它可能会按照既定的预警策略对每个用户进行封锁,这样十分影响用户体验。为了发起拒绝服务式攻击,攻击者可能会先进行观察攻击 [
5) 多系统薄弱性相关问题:大部分人在不同的系统帐户中使用相同的口令,近来的关于口令泄漏事件的报道几乎都支持这一事实 [
6) 更改系统用户界面:现有的基于honeyword的认证方案中,为了取得更好的flatness,需要对系统原本的用户界面进行更改。比如:加尾巴、密码圆盘、基于问卷调查的方案等。若是现有的系统想要部署这些方案,就必须对系统界面进行更改,可能需要用户额外花费一些时间才能弄明白如何注册系统,以及应该记住哪些改动,以便下次能够成功登录。所以这些方案大大降低了方案的适用性,没能较好的平衡适用性和安全性。
7) 系统对用户的干扰和用户的记忆压力:这是两个和适用性相关的互补标准。在Juels和Rivest的工作中 [
我们提出的方案名为“特殊字符间距机制(Special Character Distance Mechanism, SCDM)”。该方案无需对用户界面做出任何更改,唯一的要求就是用户的口令当中需要含有两个不同的特殊的字符。所以,我们的方案既不会干涉用户对口令的自主选择,也不会对用户施加额外的记忆压力——我们的方案具有极好的适用性。此外,SCDM中与honeyword相关的仅有特殊字符,而在绝大多数口令中,特殊字符与口令的其他部分、与用户名不存在语义上的关联,所以SCDM能够规避口令–用户名关联问题。SCDM理应归属到传统UI类honeyword生成方法中,所以也具有传统UI类共同的有点,即由于不需要更改系统的用户接口,攻击者不会轻易的从系统界面上判断出是否采用了基于honeyword的认证方案。
随着Unicode的引入和广泛使用,系统能够接受和处理的特殊字符越来越多,我们的方案并不局限于某种特定的字符集合。不过为了分析之便,我们仅在美国信息交换标准代码(ASCII [
图1. 特殊字符链
利用用户口令当中的两个不同的特殊字符,根据特殊字符链,SCDM就可以计算出两个特殊字符的距离。在系统初始化时,一旦生成特殊字符链,就不再改变。除生成特殊字符链外,部署SCDM不需要进行用公开的口令文件建立概率模型等工作。即,SCDM初始化非常简单便捷。
定义:特殊字符间距(Special Character Distance)为特殊字符 e 1 和 e 2 的间距 S C D ( e 1 , e 2 ) 为从 e 1 沿特殊字符链的顺时针方向到 e 2 经过的节点的数目,其中 e 1 ≠ e 2 。
由上述定义可知,口令当中必须含有两个不同的特殊字符,而且特殊字符间距的值是大于0的。
在主服务器上,SCDM需要保存用于用户认证的信息,除了用户名、去掉两个特殊字符的口令外,还需要保存特殊字符的距离。在honeychecker上,SCDM则需要保存用户的用户名和口令中的第一个特殊字符。
假设某个用户 的用户名是“Ironman”,口令是“Revenge~2018!”。根据图1,可以得到两特殊字符“~”、“!”的间距为1。则用户 u i 在口令文件 F p 和honeychecker上的信息如表2和表3所示。
考虑到用户 u i 的口令可能含有相同的特殊字符,系统管理员在部署SCDM时,可以自由选择使用某重复特殊字符第一次出现、或者最后一次出现的位置用来生成Honeyword。譬如:对于口令“!Revenge~2018!”,若选取第一个“!”,则SCDM在 F p 中存储的口令为“Revenge2018!”;若选取最后一个“!”,则SCDM在 F p 中存储的口令为“!Revenge2018”。
Username | Password | FirstIndex | SecondIndex | Distance |
---|---|---|---|---|
Ironman | H(Revenge2018) | 7 | 12 | 1 |
表2. 文件 F p 中用户 u i 的信息
Username | FirstChar |
---|---|
Ironman | ~ |
表3. Honeychecker上用户 u i 的信息
接下来我们阐述特殊字符间距是如何在生成honeywords中发挥作用的。对于既定的字符间距,以任一特殊字符链中的字符作为开头,SCDM可以产生 | SCC | 个特殊字符对。其中, | SCC | 表示特殊字符链中的字符个数。
假设攻击者已经得到了文件Fp,她可以看到的信息有用户名、去除了两特殊字符的口令,但是特殊字符间距会产生 | SCC | (此处为33)个可能的口令,供攻击者挑选。因此,只需要额外存储特殊字符间距,SCDM就能构造出含有33个sweetwords的虚拟列表,从而使攻击者感到迷惑。
用户登录时输入用户名 u i 和口令 p i ,系统首先在文件Fp中查看用户 u i 是否存在;若存在,系统从文件 F p 中得到与 u i 对应的口令哈希值, H ( p ′ i ) 。接下来,系统按照SCDM的具体实现,从 p i 中选取两特殊字符,去除后得到 g i ,然后比对 H ( g i ) 是否和 H ( p ′ i ) 一致。如果不一致,则提示口令错误,拒绝登录;如果一致,则对两个特殊字符进行验证。首先,根据存储的特殊字符链,生成两特殊字符距离。只有生成的距离和 F p 中存储的距离一致时,系统才和honeychecker进行交互;否则,拒绝登录,并记录该用户的登录行为——因为可能是攻击者仅仅得到文件 F p 后,在不了解系统已经采用了SCDM,而尝试进行登录。
由于攻击者可能猜到的特殊字符之间的距离和系统中存储的一致,所以系统和honeychecker进行下一步校验是有必要的。当系统和honeychecker进行校验时,系统只用将用户名和第一个特殊字符传送给honeychecker。此处需要强调的是,只有当攻击者猜测的特殊字符完全正确,她的第一个特殊字符才能和honeychecker匹配成功。如果honeychecker找到正确匹配,则返回正面的反馈;否则,触发警报通知管理员——已经探测到口令泄露。
因此,即使攻击者得到了泄露的口令文件 F p 并把所有的信息转化为明文,SCDM依然能够通过虚拟出一个含有33个sweetwords的列表来迷惑攻击者。因此,仅仅通过要求用户在口令当中含有两个不一样的特殊字符,SCDM就能以 32 / 33 (96.97%)之高的概率探测到攻击行为。
泄露的口令文件 F p 中,每个用户都有 k 个sweetwords,攻击者因此而感到迷惑。然而有些时候攻击者可以从 W i 中轻易的选出用户 u i 的原始口令(例如,用户名和口令之间存在着关联)。一个完全flat的、基于honeyword的认证方案中,攻击者在从 W i 中甄选用户 u i 的口令时不应有任何优势。因此,一个完全flat的honeyword生成算法,从 W i 中选出原始口令概率应该是 1 / k 。
SCDM中特殊字符链是随机排列而成的,SCDM在生成虚拟的sweetword列表时,每个sweetword出现的概率都是相等的;此外,在前面的例子中,用户名Ironman和口令Revenge~2018!存在着关联,但是由于每个honeyword只是特殊字符不同,所以每个honeyword和用户名也存在这种关联,攻击者从sweetwords中选择时不具有任何优势。因此,SCDM是可以生成完全flat的sweetwords的。
本文分析了现有的honeyword生成机制依然存在安全性较弱、占用存储空间过大等问题。然后,提出了基于特殊字符间距的虚拟honeyword生成机制,并对所提方案进行了深入分析。分析结果显示本文所提方案可以显著地减少存储空间开销,并提升安全性和口令集泄漏被检测的概率。
本文工作受到国家重点研发计划(项目号:2017YFB0802300)的资助。
荆巍巍,崔进库,朱友文. 基于特殊字符间距的Honeyword生成机制A Honeyword Generation Method Based on Special Character Distance[J]. 软件工程与应用, 2019, 08(05): 207-214. https://doi.org/10.12677/SEA.2019.85025