密码管理的几个建议


image

最近的密码泄露风波让大家对密码安全有了更深一层的认识。不仅如此,密码安全更是全世界人们都必须重视的东西。根据英国卫报消息,美国战略预测公司网站遭到黑客攻击,85万注册用户信息遭泄密。其中221名英国国防部军官和242名北约官员邮件地址遭泄露,密码均可轻易破解。更多美国军方人士个人信息也遭泄密。美国前副总统丹-奎尔以及前国务卿基辛格的个人信息竟然也在其中。密码安全好似相处已久的恋人,平时虽无特别的感受,但等到不得不分手时才感到追悔莫及。

通常来说,密码安全性受个人技术能力,社会工程学知识,管理习惯等因素影响。不过好的密码管理习惯可以有效的增强密码安全性强度,甚至在密码发生泄露之后最大程度的减少损失。这里我们就来谈谈如何养成好的密码管理习惯。

密码创建

密码的创建非常重要,他是有效保护账户安全的第一步。强密码应该使用由数字和大小写英文字符组成,长度应该至少在 8 位以上,如此一来,该密码的可能组合至少为 10^6×24^2×7×8 种,使用暴力破解的方式代价极大。除此之外,密码字符应该尽可能多,甚至参杂标点符号。同时密码中不能出现有意义的单词,与个人生日、姓名有关的字符或者各类电话号码,总之不能是其他人能够轻易获取到的任何个人信息,密码应该只对你自己有意义。遗憾的是,通过分析 CSDN 泄露出的密码数据库,使用 123456789 作为密码的用户居然有 23 万之多,可见的密码安全在很多人心中的地位并不重要。

创建了强密码之后是否就意味着一劳永逸呢?当然不是的,你密码不应该是唯一的,理想情况下,每个账户都应该使用不同的密码。不过遗憾的是人类的大脑并不如电子记忆体一般,能够一次保存,永久读写,因此建议采取分级密码管理的方式为重要程度不同的账户创建不同的密码。比如,普通论坛账户对于安全性的需求较低,对于黑客来说也不会有特别大的价值,因此可以采用较为简单密码。而银行账户、电子支付账户和重要联系工具,比如电子邮箱、即时通讯账户则应该使用强度非常高的密码进行保护。在最近的 CSDN 密码泄露事件中,有不少用户的在注册邮箱中使用的密码和 CSDN 密码完全相同,导致了不可估量的后果。由于邮箱和大量 ID 绑定,各种 ID 都可以通过邮箱找回,因此一旦邮箱丢失,相当于丢失了所有采用此邮箱注册的 ID 。

密码使用

临时使用了旅馆的计算机之后,我朋友的 QQ 遭到盗窃,并向所有好友借钱。这是现在仍然流行的一种诈骗方式。由此可见,哪怕你有长达 18 位的标点,数字与字母混合密码,正确的使用方式仍然十分重要。密码使用时的第一个要点就是不要在不熟悉的计算机上输入密码。这些计算机可能安装有特殊的键盘记录程序,可以记录每一次击键输入。即便不得不使用密码,也可以采取以下措施:

  • 使用屏幕键盘
  • 不要记住登录状态且使用完毕后完全退出
  • 回到自己的计算机上修改密码

密码在使用时还需要考虑到一些其他因素。除了老生常谈的“不要将密码泄露给他人”之外,有些用户的密码泄露居然是因为遭到了旁窥。在实际操作中,也应该使用额外的安全措施降低密码在使用中泄露的机会。除了为自己的计算机安装安全软件,用户还应该谨慎分辨要求输入密码的场合是否有异常,以免被钓鱼网站利用。有些网站提供了密码输入控件和额外的验证服务,比如短信验证码等,都是不错的安全加强手段,我们稍后会仔细谈一谈。

密码维护

除了日常使用以外,密码也需要定期的维护。维护密码最常见的一个目的就是防止遗忘。这个 ID 我已经多久没有使用了?我还记得他的密码吗?这个 ID 是在哪个网站注册的?他还有效吗?这些都是密码维护过程中需要注意的问题。除此之外,密码维护也包含了对密码的定期更换。谁都无法保证在密码使用过程中的绝对安全,因此定期对关键密码进行更换也是十分重要的。通常来说,新更换的密码应该从未在任何地方被使用过,且无法从已有的密码中被类推出来。密码维护还包含一个非常重要的步骤,就是检查已有的密码是否已经发生泄露。常见的检查方式就是通过网站的账户记录检查工具查看账户是否有异常的登录信息或者操作记录,依此确认密码是否发生了泄露。

密码维护能够使得密码安全性得到显著加强,是必不可少却常被人们忽视的一个步骤。

特殊密码(身份凭据)

QQ 令牌,淘宝手机密令, Google 身份验证工具,以及魔兽秘宝卡/安全令牌和各大银行的短信登录验证码/ USB Key 都是强度很高的额外身份验证工具,通常来说,他们的安全性强度排列如下:

令牌(动态密码,安全性最强)=短信验证码> USB Key > 秘宝卡

image

各类手机令牌/实体电子令牌是目前安全性最佳的身份验证工具,强烈建议每位用户使用,尤其是手机令牌并不会给智能手机用户带来额外的费用,却能够显著增强安全性,非常值得推荐。这类令牌在绑定后,会给用户提供一个额外验证码。网站会在用户进行登录操作时要求用户输入这个验证码,否则便无法登陆。验证码每几分钟就会改变一次,且每个验证码只能使用一次,因此即便有人获取了其中一个,也无法登陆用户的账户。使用令牌几乎不会降低安全性,除非网站服务器中的根证书被盗,导致所有令牌被破解。此外,即便实体电子令牌/手机被盗,账户仍有密码保护,黑客无法仅凭借令牌登录。目前也没有任何已知的黑客技术能够从用户的智能手机上直接获取动态密码。

短信验证码是手机服务运营商和网银常见的的一种验证手段,但由于智能手机的普及,已经有很多已知的黑客技术能够从用户的手机上取得短信,因此其安全性不如手机令牌要高。不过作为一种额外的身份验证手段,它并不会因此降低密码安全性。如果黑客没有同时取得用户的密码,也无法凭借短信验证码登录。在两台不同的计算机上申请所取得的验证码也完全不同。因此短信验证码仍是一种不错的额外身份验证服务。

image

各类银行的 USB Key 实际上是一个内置了加密证书的只读存储器,用户在安装了特殊的应用软件之后,能够通过该证书进行身份验证并进行加密通讯。 USB Key 通常由银行颁发,作为用户在登录网银时的身份验证。 USB Key 的强度取决于网银配套软件的安全性强度,如果黑客能够破解网银应用软件的安全防护,当然也就能够伪造各种交易指令了。因此, USB Key 最好也仅在自己信任的计算机上使用,且在不使用时从计算机上拔出。

image

秘宝卡是动态密码的一种原始版本,通常动态密码是一张 10 × 10 的表格,每个格子里填写有一位数字或字母,登录网站时,用户会被要求依次输入几个格子内的字符,这些格子的位置都是随机选出的,因此即便黑客能够取得其中几个格子中的字符,也无法获取整张秘宝卡的内容,从而登录用户帐户。不过,许多用户为了方便,将秘宝卡扫描到计算机中,给了黑客可乘之机。此外,黑客如果持续监视某一账户,在用户多次执行登录操作之后,就能够大致得到整张秘宝卡的内容,因此秘宝卡是一种不完美的动态密码,其动态的范围是有限的,并不能够真正实现一次一秘。

其他密码管理

移动设备,诸如运行 iOS 和 Android 系统的智能手机已经承载了太多功能,大到各类金融交易,小到各类私人事务的处理都可以在上面完成。因此,智能手机上的密码安全性也应该予以重视。智能手机除了应该和个人计算机一样,不要安装来路不明的软件之外,还有一些值得注意的安全性漏洞:

手机锁屏界面通常是一个四位数字的 PIN 码或者九宫格的图案锁,由于手机屏幕表面常常覆盖着一层污垢,因此经常点击的位置会变得十分明显。如果不怀好意的人盗取了你的智能手机,他们能够通过观察屏幕表面得到作为密码的图案或者数字,这是十分危险的,为了避免这种情况的产生,建议用户在设置 PIN 码时重复一位数字,使得黑客无法确认哪一位是被重复的数字,以提高安全性。在设置九宫格图案锁时重复一个路径点,也能够混淆图案的真实画法。此外,在 iOS 和 Android 设备上都有一些提供远程锁定,资料清除和设备追踪的服务,用户也可以启用它们来给设备提供额外的安全性加强。

总结

密码安全性是一种理念和行为,而非一个口号,从另一个角度上来说,你无需保证自己的密码绝对安全,这也是不可能做到的,你需要保证的只是密码安全性与其账户价值相符,或者说,比其他人的密码更为安全就可以了。

【转】安全崩盘的年代:由拖库攻击谈口令字段的加密策略

本文作者肖新光,网络ID江海客,安天实验室首席技术架构师,研究方向为反病毒和计算机犯罪取证等。如果有读者想要就安全问题和作者探讨,可以在微博@江海客

 

我不得不惨痛地写在前面的是,这是一个安全崩盘的时代。过去一年,已经证实的遭遇入侵、并导致关键数据被窃或者被泄露的公司,包括索尼、世嘉这样的大型游戏设备厂商;包括花旗银行这样的金融机构,也包括了RSA这样的安全厂商。

这些事件中最令业界瞠目的是RSA被入侵,这直接导致多家工业巨头遭遇连锁的攻击,很多安全企业本身也使用RSA的令牌。比RSA弱小很多的荷兰电子认证公司DigiNotar已经在被入侵后,宣告破产。

就在2011年上半年,我们还是站在旁观者的立场讨论这些事情。但随即我们就遭遇了CSDN、多玩和天涯等等的数据泄露,其中最为敏感的,一方面是用户信息,另一个当然就是用户口令。由于身份实名、口令通用等情况影响,一时间人人自危。各个站点也陷在口水当中。

但实际上根据推断,这些入侵都是一些过去时,也就是说这些库早就在地下流传。同时流出,也许就是一个集体性的心理效应。

这种针对数据库记录的窃取,被一些攻击者称为“拖库“,于是有了一个自然而谐音的戏称“脱裤”。只是攻击者日趋不厚道,从前只是偷了人家的裤子,现在还要晾在大街上,并贴上布告说,“看,丫裤子上还有补丁呢”。

如果拖库是很难避免的,那么采用合理的加密策略,让攻击者拿到库后的影响降低到更小就是必要的。

明文存放口令的时代肯定是要结束了,但加密就安全么?

那些错误的加密策略

明文的密码固然是不能接受的,但错误的加密策略同样很糟糕。让我们看看下列情况。

简单使用标准HASH

我想起了一个90年代黑客笑话,有人进入一台UNIX主机,抓到了一个shadow文档,但破解不了。于是,他用自己的机器做了一个假的现场,故意留下这个shadow,最后看看别人用什么口令来试,最后再用这些口令与渗透原来的主机。遗憾的是,那时我们都把这个当成一个Joke,充其量回复一句“I服了you!“,而没有反思使用标准算法的问题。

目前来看,在口令保存上,使用最为广泛的算法是标准MD5 HASH。但实际上,很长时间,我们都忽略了HASH设计的初衷并不是用来加密,而是用来验证。系统设计者是因为HASH算法具有不可逆的特点所以“借”用其保存密码的。但其不可逆的前提假设,是明文集合是无限大的。但放到口令并不一样,口令的长度是受限的,同时其可使用的字符也是受限的。我们可以把口令的总数看正一个事实上的有限集(很难想象有人用100个字符作为口令)。

比如一个人的密码是“123456”,那么任何采用标准MD5加密的网站数据库中,其存放的都是这样一个MD5值:E10ADC3949BA59ABBE56E057F20F883E

由于密文均相同,加之HASH算法是单向的,因此攻击者较早使用的方法就是“密文比对+高频统计“后生成密文字典来攻击,由于绝大多数网站和系统的加密实现,都是相同明文口令生成相同的密文,因此,那些有高频密文的用户就可能是使用高频明文口令的用户。攻击者一方面可以针对标准算法来制定高频明文的对应密文档来查询,另一方面,对于那些非标准算法,高频统计攻击的方法也非常常见。

但查表攻击迅速压倒高频统计的原因,正是从2000年开始陆续有网站规模性明文口令泄漏事件开始的。在过去每一次明文的密码泄漏事件,攻击者都会把使用MD5、SHA1等常见HASH算法加工成的口令与那些采用HASH值来保存的库进行应对。

随着超算资源的廉价、GPU的普及、存储能力的增长,一个不容忽视的威胁开始跃上桌面,那就是,这些巨大的HASH表已经不仅仅是基于泄漏的密码和常见字符串字典来制作,很多攻击者通过长期的分工协作,通过穷举的方式来制作一定位数以下的数字字母组合的口令串与多种算法加密结果的映射结果集,这些结果集从百GB到几十TB,这就是传说中的彩虹表。

HASH的单向性优势在此已经只有理论意义,因为HASH的单向性是靠算法设计保证的,使用一个有限集来表示一个无限集,其必然是不可逆的。但攻击者是从查表来完成从HASH到口令明文的还原的。因此其算法的单向性也就失去了意义。

联合使用HASH

一些人误以为,HASH不够安全是因为HASH算法的强度问题,因此把MD5或者SHA1联合使用,其实这是毫无价值的(只是徒耗了存储资源)。如上面所说,HASH的不安全性在于大量口令与其HASH值的对应关系早已经被制作成彩虹表。只要你联合使用HASH的算法其中之一在彩虹表中,自然就可以查到了。

同理,那种采用“MD5的头+SHA的尾“之类的,或者采用其他的混合两个值的方法,也一样是没有意义的。因为攻击者可以很容易的观察到这种组合方法的规律,经过拆解后继续按照查表法破解。

自己设计算法

我一向认为,既然我们不是一个密码学家,而是工程师、程序员,那么放着现成的好东西不用,自己开发加密算法是相当愚蠢的事情。我相信很多程序员都遇到过挖空心思想到了一个“新算法”,然后发现早在某篇20世纪80年代的数学论文里,早就提出了相关算法的情况。

况且在开源时代,很多算法不仅被实现和发布了,而且还经历了长期的使用推敲。这些都是自己设计、自己实现无法比拟的。

关于自主设计的算法的不安全性,有一个事情深达我脑海。记得我在证券系统工作时,由于刚刚接手收购来的营业部,需要把一个clipper编译的柜台系统进行迁移,但原来的开发商已经联系不到了,当时我们制定了两条路,一位高手李老师负责,进行数据破解,看看是否能还原明文,而我则负责破解算法,如果李老师那边走不通,则我需要解出算法,把000000~999999之间的数字全部加密,然后用密文做碰撞(那时证券都是柜台操作,没有网上炒股,密码都是柜台用数字键盘输入的)。

由于原来的开发者加了一点花活,我这边还没有眉目,那边旁观李老师的工程师,已经发出了惊叹之声,我跑过去,只见李老师根据构造的几个密码的加密结果,在纸上汇出了长得非常像杨辉三角的东西。不到半个小时,李老师已经连解密程序一起做好了。

上面故事的目的是说明,自己设计算法无论怎么自我感觉良好,看看美国官方遴选算法的PK过程大家就明白了,我们无法和全球数学家的智慧组合对抗。

因此自己设计实现算法,并不是一个好主意。这其中也包括,在实现上会不会有类似输入超长字符串会溢出一类的Bug。

单独使用对称算法

在标准HASH安全破灭后,又看到有人呼吁用AES,其实这不是一个好建议。AES这些对称算法,都不具备单向性。网站被攻击的情况是复杂的,有的是只有数据库被拖,有的则整个环境沦陷。而后者AES密钥一旦被拿到,密码就会被还原出来,这比被查表还要坏。

当然我们还看到一种把AES当HASH用的思想,就是只保留一部分的AES加密结果,只验证不还原。但其实这样的AES并不见得比HASH有优势。比如即使攻击者没有拿到密钥,也只拖了库,但攻击者自己在拖库之前注册了足够多的帐号,并使用大量不同的短口令。那么就拿到了一组短明文和对应密文。而此时密钥是完全有可能被分析出来的。

而使用DES、AES一类的算法,还是使用标注HASH,还是自己设计算法,如果不解决不同用户相同口令密文相同的统计性缺陷,那么攻击者即使拿不到密钥,也都可以先把一些高频口令用于帐号注册,拖库后进行密文比对。就可以锁定大量的采用常见口令的用户。

加“一粒盐”

其实很多同仁都指出了哈希加盐法(HASH+SALT),是问题的解决之道,所谓加盐(SALT)其实很简单,就是在生成HASH时给予一个扰动,使HASH值与标准的HASH结果不同,这样就可以抗彩虹查表了。

比如说,用户的密码是123456,加一个盐,也就是随机字符串“1cd73466fdc24040b5”,两者合到一起,计算MD5,得到的结果是6c9055e7cc9b1bd9b48475aaab59358e。通过这种操作,即便用户用的弱密码,也通过加盐,使实际计算哈希值的是一个长字符串,一定程度上防御了穷举攻击和彩虹表攻击。

但从我们审计过的实现来看,很多人只加了“一粒盐”。也就是说,对同一个站点,不同用户使用同一个密码,其密文还是相同的。这就又回到了会遭遇高频统计攻击,预先注册攻击等问题。

口令的安全策略

在传统密码学家眼中只有一种加密是理想的,那就是“一次一密”,当然事实上这是不可能的。但如果我们套用这种词法,我们也可以说,口令安全策略的理想境界,我们可以称为单向、一人一密、一站一密。

单向:标准HASH算法的价值尽管在这个场景下,已经被推倒,但其单向性的思想依然是正确的,口令只要是能还原的,就意味着攻击者也能做到这一点,从而失去了意义,因此使用单向算法是必须的。

一人一密:同一个站点设置同样口令的不同用户,加密生成的密文内容并不相同。这样就能有效的应对结果碰撞和统计攻击。采用字典的攻击的方法基本是不收敛的。

一站一密:仅仅保证一人一密是不够的,还要保证使用同样信息、同样口令去注册不同网站的用户,在不同站点的口令加密结果是不同的。鉴于有大量用户用同样的信息、同样的口令去注册不同网站,如果能做到这一点,流失出的库信息会进一步打折扣。而攻击者基本会放弃生成密文字典的尝试。

实现这些说起来很简单,依然是HASH+SALT,关键在于每个站点要有不同的SALT,每个用户要有不同的盐。

但如果攻击者不是只获得了库,而且也获得了相关的加密参数和密钥,我们就要看到攻击者依然可以自己通过相关参数和密钥调用算法,使用常见密码对每个用户生成一遍密文,然后是否有匹配。当然我们可以看到由于“每人一粒盐”的策略,攻击者所需要的计算代价已经变化了,如果过去只需要生成一次的话,那么假如使用100个常见的口令来做,那么只要口令没有碰撞到,对每个用户都要做100次加密操作。但这也是不容小觑的威胁。因为有太多用户喜欢使用那些常见口令。

因此,设定一个密码禁用表,让用户避免使用常见口令,可以进一步让破解者付出更大的代价,从而最终导致计算资源不收敛而放弃,也可以是一个可以考虑的策略。但也需要提醒WEB开发者的是,这样会增大你的用户忘记口令的风险。

另外,用户是否有把密码设置为123456的自由呢,我想只要不是国防、航天、涉密系统和有安全要求的企业环境,如果只是潜潜水、骂骂街,网站或许提醒用户就好,但也许并不需要做成强制策略。

具体的实现

了这么多,怎么来具体实现一站一密、一人一密的策略呢,2011年12月23号,我们想到与其空洞的说教算法原理和策略,不如提供一些非常直接的示例程序和文档。

因此同事们写了一份名为Antiy Password Mixer(安天密码混合器)的开源代码,当然这没有什么技术含量,也不是“自有知识产权的国产算法”,有的只是对实现较好的流行开源算法包的示范性使用而已,目前的Python版本,也只有三百行代码,在其中封装了RSA和HASH+SALT使用,并给出了具体的在初始化、注册和认证时如何使用的范例文档。

大家可以在这里找到这个东西:http://code.google.com/p/password-mixer/

当然,就像我们惋惜很多应用开发者缺乏对安全的重视一样,其实我们并不懂应用开发,所以这些代码和文档对于应用开发者看来可能非常丑陋。尽管可能被鄙视,我们还是要打开门,证明安全团队并不保守。

而同时,我们必须与应用走得更近,因为我们也在使用着这些自认为违反了某种安全原则的应用,却因为不是其开发者而无法改造它们。

过去的10余年,中国的Web应用甩开安全而飞速狂奔,开发者们凭借自身的勤奋和冲击力奠定了现有的格局,但也因快速地奔跑遗落了一些东西,比如安全。也许现在是拾起这些弃物的时间了。

中国的安全界则因保守、敏感和很多自身的原因,与应用的距离越拉越远,在我们还在幻想某些完美的安全图景时,发现我们已经望不到应用的脊背了。也许,在应用会回头等等我们的时候,就是我们加速前行、拾起应用所遗落的安全性,追送上去的时间了。

css.php