创意安天

 找回密码
 注册创意安天

安天实验室:Web应用开发中的安全算法使用策略

[复制链接]
发表于 2012-2-28 10:22 | 显示全部楼层 |阅读模式
2月25下午,CSDN在北京丽亭华苑酒店举行了TUP第二十期活动——互联网安全。本次活动邀请了众多安全界专家,安天实验室反病毒引擎研发中心经理童志明,安恒信息安全服务部门经理刘志乐,C/C++/ASM程序员,xsign成员张亚一和pr0zel windows安全研究员李敏怡。他们将在本次演讲中以大量实例演示,阐明互联网安全的安全防御与漏洞补杀、分析用户身份认证等亟需解决的问题所在。

89_120225144046_1.JPG

安天实验室反病毒引擎研发中心经理 童志明

安天实验室反病毒引擎研发中心经理童志明在活动中发表《Web应用开发中的安全算法使用策略》主题演讲。

童志明演讲中表示,在当前0day横行,几乎没有网站和应用可以绝对保证自己数据库系统的安全的情况下,如何合理的利用现有的安全算法,可以获得更多安全的保障,是我们需要讨论的问题。

通过对APM实现的展开进行深入的讨论,让目前还在明文保存密码的网站和使用相关算法策略并不合理(比如那些联合使用HASH或者加入单一SALT的情况)的网站,能够了解如何科学使用这些数学方法,降低安全应用的门槛;我们也希望打消那些中小网站试图自己研究一个算法的努力。放弃这些已经被经过理论和实践检验过的算法实现,而徒耗心力和人月,是不值得的。

以下是演讲实录:

在过去十余年间,我们中国的外部应用开发飞速的发展,开发者凭借自身的勤奋和冲击力,奠定了现有的格局。因为我们快速的奔跑过程当中,也可能遗落了一些东西,比如说安全。

我们站在安全工程师这个角度来讲,在泄密门事件发生以后,我们迅速推出了一个开源的项目叫APM。实际上来讲,我们是利用了现有的流行开源包并没有开发自己的算法,当然完成了对RSA一个外围封装。通过这个的实现,给网站开发者一些应用算法相对合理的一个范例。当然可能大家也希望自己去实现更精彩的代码,我们只是希望让更多的开发者了解安全实际上来讲并不是神秘的,一样有大量的资源可以借鉴。

今天演讲的内容有几个方面,一方面是背景介绍,就是关于我演讲内容的一些名词解释。另一方面,就是关于去年大家都知道的泄密门事件。另外就是我们所面临的威胁都有哪些,在这里我粗略地给出了一些我们现在面临哪些威胁这么一个说明,包括在泄密门事件以后有很多的开发者或者是已经在实现、应用的算法,然后还有一些各种各样的声音。另外就是关于安全算法的使用策略问题。

首先是背景介绍。我们看一下几个名词,第一个名词就是HASH。HASH我们也有人叫散列,简单的说就是将一种任意长度的消息压缩到某一个固定长度的信息摘要。另外就是加密、密文,就是把口令变换的过程称为加密,以及把口令变换后的结果称为密文并不科学,但是公众所理解的。经常来讲我们加密对应一个解密,很多人在泄密门事件说你这个信息为什么不加密啊?你怎么不做散列,散列是没有过程的。最后一个是计算速度,关于本次演讲中我们写到的计算速度所指的是单位时间内计算的次数。

面临的安全威胁都有哪些?

在这里大家看到我在上面写了一个题目,在当前Oday横行的时代,几乎没有网站和应用可以绝对保证自己数据库系统的安全。我分了几类:

第一类就是在系统方面——漏洞,这个是最容易出现问题的一个大类。由于我们外围应用的开放性,我们外部的应用程序越来越多,带来的安全的漏洞也会随之增加。另外就是在服务方面,还有数据库系统,这一系列的服务,很多都是有默认的口令或者是默认的配置,很多人把这个东西拿过来就用了,有可能默认的口令、帐号没有更改,它带来的结果就是这些密码或者是这个配置就会被攻击者利用发动攻击。

第二类是远程运维的风险,比如说我需要一个远程运维,有的运维是在公司,有的是在家里,在这个过程当中很有可能就会带来风险。比如说家里的PC不会像在公司的这种相对来讲有一些安全的防范情况下,有可能比如说你的设备被入侵了,比如说中了一个木马,很容易拿到你的口令,拿到口令以后,攻击者就会用你的帐号、口令登陆服务器。

第三类是备份的风险,因为运维的时候我们要备份,有可能权限分配不当,或者是备份的人员没有安全意识,可能把明文数据放到服务器上了,这种情况也会导致我们数据的泄密发生。在这个信息被盗以后,攻击者往往会对信息进行二次的利用,比如说他拿到口令以后,他会去做一些其他的尝试,登陆一些其他的网站,当然登陆过程不是人一个一个去敲的,有可能是控制了这个自动登陆,或者是有这个验证码,很多验证者会写验证码解析的。往往这些信息被攻击者进行二次进攻,我们可能面临的是信息泄露,密码丢了以后或者是手机丢了以后有人给你打电话,这就是信息泄露。

第四类是口令危害,口令的危害相对来讲是比较严重的。在泄密事件发生以后,我们经常听到各种各样的声音,包括我们APM发布以后有一些有意思的事,在这里面有一些错误的实现,包括一些错误的声音。我们看一下有哪些呢?网上有人说为什么不做一个HASH,在这里我给出了一句话是不合理,但是比较靠谱的一个实现。最起码他们是知道HASH是具有单向性的。实际上HASH我们做了一个变换。还有人称用MD5就好了,50年不能被破解。但是实际上来讲,HASH对数据信息做一个信息摘要了。那么这个数据来讲这个长度是有很长的。比如说我们对《红楼梦》做一个HASH算法,但是相对于口令来讲,口令的空间范围是有限的,我们可能就是一个人用十六个字节的密码已经相当不错了。那么对应的情况就是当攻击者拿到密码以后,他们会做一个统计攻击,比如说统计一下看你数据库当中散列有多少,我们知道HASH相同数据算出来散列值都是一样的,包括对明文一些统计。

用户口令过于简单 被盗用几率提高

比如说我们上面写的是TOP100口令的用户,这部分用户占到总人数的口令达到20%以上,这是非常令人震惊的一个数据。另一个就是使用纯数字口令的用户,纯数字口令用手机号、用生日,这个达到了50%,这个数据相对来讲是相当恐怖的。攻击者为什么要统计数据,统计以后他能够拿到TOP的口令,需要做的事情——高频碰撞。

还有一些声音讲,为了防止别人攻击我是不是做一个联合HASH,联合HASH是什么呢?就是我算一个MD5,再算一个SHA1,但是这个对于攻击者来讲是相当简单的,比如说我把MD5再做一次MD5怎么样呢?这个MD5包括一些彩虹表,这些我们怎么办?下面就是我列出一个列表,里面对口令做一次散列,还有做两次,包括SHA1。

彩虹表可以快速的破解密码,越是复杂的密码彩虹表越大,彩虹表的体积一般来讲以百G以上来论的。拥有彩虹表以后,破解对他们来讲是难度非常小的,包括GPO的加速,对MD5的次数可能接近千亿次的情况。

下面我列出了彩虹表的一个生成器大家可以看到这样一个东西。

还有一些错误的实现。这个当然是声音了,刚才我讲的都是实现,有人做散列的,有人做两次散列的。错误的实现有哪些呢?

有人提出说我是不是自己设一个算法?我觉得这个事情是非常悲催的事情,第一个事情就是我们怎么保证HASH的均匀性,右边就是安天对各种HASH做了一个评估。再一个通过HASH碰撞进行拒绝式服务攻击,这个事情大家应该听说过。在去年泄密门事件以后也把这个事件掩盖了,HASH碰撞攻击几乎涵盖了所有的脚本语言。什么是HASH碰撞呢?就是攻击者通过裁判HASH算法,我们如果自己设计算法,如何保证均匀性这是一个问题。

还有一些声音说实现慢速HASH,有人说这个HASH太快了,我自己实现一个慢速HASH怎么样呢?我们后面可能给出一些例子,我们看到,实际上来讲,所有的HASH没有慢的,当他面临几个问题,一个问题就是他的HASH算法不合理。另外一种就是用户的体验问题,我们想象一下你在网站提示说用户登陆可能需要三分钟,这个用户非常悲催,实际上这个慢速HASH应用非常不适合外部的应用场景一下。

在这里,我想说很难设计出一种慢速的HASH,在XP系统构架下,对CPU是负载的,实现基地是不容易漫过的。慢速HASH一定会负载的,所以这个实现是非常不合理的。

还有一些网站声称自己特别安全,为什么安全呢?因为可以识别你的指纹。比如,我们获取一个指纹和获取一个口令,实际上没有任何太大区别。指纹算一个散列,但是指纹识别意味着几个事情,不可再生指。还有一个面部识别,以上是其他人提出的自己想法和观点。接下来我们下面要讲的就是安全算法的一个使用策略。

一用户一盐

这个就是在泄密门事件以后我们推出一个APM(http://code.google.com/p/password-mixer),实际上来讲,我们基本上是基于现有的开源包,然后也不是算法实现,也不是新的算法。在这里提到了几个概念就是一用户一盐,包括个性化的料,盐表。还有就是APM发了以后,有人跟我们交流,有的用UID,还有用注册时间的情况。另外还提供了还原模式,当然有站点有需求,比如说我需要原始密码,我们这里也提供了一个功能。当然这里面最无奈的一个事情是什么呢?就是一号通。在这里画了一个图,就是RSA的算面,一个是交流的问题,再一个就是在现在这种情况下,很难保证我们安全可言。

什么样是安全的呢?一是算法不公开,另外是密要不公开。在这个0Day横行的时代,我们很难保证这种情况。在这里列出了开源项目的一个UL抵制。

这里面所提到的第一个事情就是为什么要使用标准的算法?第一点来讲,标准算法是公开的,我在这里列出了APM当中一个代码。这个APM就是我们实现了几种语言,大家可以上去看一下,这里列出的是PHP的。这里直接调用了一个APM,完成了一个加密。

标准的算法的合理性是经过时间、经过数学家大家验证的,是经过理论和实践检验过的算法。还有一些问题就是事实上来讲不是算法的问题,是如何合理使用的问题,我们看到刚才我们做一次HASH等等这种情况。事实上来讲,不是算法本身的问题,是如何合理使用的问题,下面我会讲到。

我们先看一点,攻击者所能掌握的资源。第一个就是计算速度,这个是非常恐怖的一个事情。在这里我贴了一个图。我们看一下在虚拟机的情况下,我们算十六个字节的散列,2.99秒算了170多万次,意味着一之内可以计算50万次的口令。如果你的密文口令被攻击者拿到以后,他做一个统计,做一个TOP,我对TOP20做一个计算,一秒钟50万次。另外一个就是云计算,还有GPO加速计算,再一个就是攻击者所掌握的大量的网络,都会被他们所利用。

三种手段:一个是统计攻击,高频碰撞。第二个是反向查询,第三个是暴力破解。

盐为何物?

盐的概念是什么呢?盐实际上来讲就是一组随机数据,把这个随机数据与用户的口令相结合,然后运算散列,这个就是盐的概念。

这里就是盐如何使用,当用户首次提供密码的时候,由系统自动往这个密码里加入一注盐,然后再进行散列,用户登录的时候,系统就是盐加散列,再比较散列值,确定密码是否正确。为什么要有用户名呢?有了用户名,比如说有了一个站点,用户的名称是唯一的,它就起到了一个盐的作用,我们为什么还要加盐,比如说攻击者拿到了两个网站的数据,那一个是什么呢?比如说一个用户是123,另外一个用户也是123,实际上来讲我们算的散列值依然是一样的,他依然可以直接通过散列一查就知道你使用了什么密码。所以说我们这里还是要加盐。

下面这里就是一个APM的示意图。我们看到用户注册,注册通过外部服务器,然后用户名、密码、盐三个联合生成一个验证的密码。这是我们画的一个示意图。

我们看到有开发者给我们发过来一些算法,其中有一部分就是使用单一的盐,在这里面有三个图。一个就是直接计算MD5的,密码123456,所有的散列都是一般的。还有一个加一个盐,加一个盐攻击者有可能说不知道你的密码是什么?在他拥有大量的计算资源的情况下,他很容易还会搞定你的口令,他对所有的散列也在做一次统计,依然能拿到TOP10、TOP20的口令。

下面就是一用户一盐的情况。我们看到一个用户一个盐,那我们算完了HASH时,每一个都是不一样的,攻击者拿到密文的口令列表以后,他所看到的每一个散列都是不一样的,他没法统计了,他如果希望拿到每一个用户的口令办呢?只能是一个一个去尝试,加盐,然后算密码、算口令。

在这里还有一些其他的策略,就是大家如果看到KC代码以后,比如说我这里没有使用SQL,随着互联网的发展,非关系型的数据成为了一个热门领域,但是我使用KC的目的,不是因为它效率比较好,所有网站面临重要的攻击就是输入,各种各样的尝试。

还有一些其他的策略,比如说我们常见口令的规避。我在这里给了一个图,这个是口令在线检查的这么一个。常见的口令规避是非常重要的,比如说我们现在的一些高频的密码,还有已经泄露的一些密码,在这里APM做了一个简答提示,比如说高频密码,还有陈述口令。我们看到这上面出现大量的问题就是用户用他的用户名做密码,这里我们也做了一个检测。

还有一些其他的策略,比如说动态均衡,微软的Hotmail做了一个动态均衡,原理就是对你口令做一个基数,当你的口令达到用户的1%,我就不允许你再使用这个密码了。但是这个实际上来讲也是有一些弊端的。这个弊端是什么呢?第一点你要对这个口令做计数,当你计数的表被泄露以后,用户就会知道这个超过一万次了,这个一万次了搞定这些。

我在这里画了一个图可能也不太合理,我希望不要把鸡蛋放在一个篮子里。这个什么意思呢?第一个就是信息的分级,这也是很重要的,就是我们不能把所有的数据放在一个表里,用户拿到以后相对来说是非常悲惨的事情。另外不要指望你的算法安全保证就能保证一切了。这里还有一些运维的策略。比如说我们安天这个提到的一个,就是用记录保护记录。什么概念呢?就是我们可以在我们表里构造海量的假用户放在里面,在里面有十万个用户,我再掺一百万个,另外一个就是算法上的误导,比如说我用的是APM的代码,你够到假用户我用其他的密码,攻击者一尝试算出来了,登录一下看看,他用假用户登陆意味着你的站点已经泄密了。


Antiy Password Mixer(APM)
http://code.google.com/p/password-mixer
发表于 2012-2-28 10:35 | 显示全部楼层
WEB应用开发中的安全算法使用策略.rar (2.79 MB, 下载次数: 576)
发表于 2012-2-28 10:36 | 显示全部楼层
引擎出品,必属精品
发表于 2012-2-28 10:39 | 显示全部楼层
顶!
发表于 2012-2-28 17:25 | 显示全部楼层
支持!!
您需要登录后才可以回帖 登录 | 注册创意安天

本版积分规则

小黑屋|手机版|Archiver|创意安天 ( 京ICP备09068574,ICP证100468号。 )

GMT+8, 2024-3-29 17:46

Powered by Discuz! X3.4

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表