没有绣花针,不揽瓷器活

周末,看到一堆泥腿子来CSDN上谈论铁路订票系统瘫痪的问题分析。换位思考一下,觉得真的很难,换成谁估计都无解。

从项目本身来看。
一、太极公司作为系统一级资质的系统集成大公司拿到这验收个项目,关系是铁定的,利润未必有多少是自己的,现在的甲方铁道部层层验收,拿项目费用是非常非常大的。这一点在我上次给国家税务总局南海数据中心做容灾项目的时候就领教过了。
而作为乙方,项目经理没有足够的人员支配权力和外包单位否决权,领导一个副总要把WEB层包给张三,数据库设计包给李四,不是技术总监等技术人员能拍板的。

二、如上所述,一个大项目,可支配的用于项目技术方面的配额是有限的。怎么办?只有拿出自己公司最牛B的技术大拿来设计并总包了,可惜做SI的人经验再丰富缺2点这个系统最要命的经验:1,内部系统和互联网系统的架构设计是不一样的。2,接口部分的设计没有关系和大佬打招呼,人家甲方的其他接口人员是不吊你的。

三、接着,赶工期让手持PMP证书的一线项目经理明知进度和风险控制是这个项目的悬头三尺剑,也不顾了——老板验收了才有年终奖是王道

四、接着,Loadrunner资深背景的工程师在一线也不顾负载压力的风险控制了,模块写完是王道——已经几天几夜没有睡觉了——谁他妈的让你测试了,分包当中没给钱,要测试就得耽误进度。

五、当初投标技术方案中有IBM,思科,EMC,oracle众多好手给出了在许多项目中得到论证检验的架构设计,充分考虑了安全性、网银接口(查询、同步、异步)、负载均衡集群、故障切换、容灾设计、session同步、会话转移、更有甚者Oraacle把Exedata都拿去做PoC测试了。可惜乙方中标后由于种种原因都一一砍掉。厂家有良无良的工程师都爱莫能助了——老板说了,这个单子Q末没有进来,OO没有拿到,乙方又没有人压货。所以我们不能suport了,对不起。

六、接着,写模块的程序员到了项目中期才发现,坑爹的票务综合数据有好几个重要接口在项目开始就要了,人家种种刁难不给你。最后产生了坑爹的银行接口不全、票务状态信息接口不全等设计客观原因。

七、好不容易开了N个会议后,项目经理去一个接口的专责科室一个个去敲门,解决了一半,还有一半的专责出差的出差,培训的培训,见了的也摆谱,你的级别和我不对等,让你的老板来,碰了一鼻子灰。回来了后老板不在——年底了,集成公司都在收款,年终答谢,饭局、KTV,答谢会,谋划明年的Quota,密谋明年坐哪把交椅——都忙,缺都没有上心接口的事

八、最后,无法规避坑爹的发生,时间和成本让你无法重构session同步和证书网银的代码,最后只有坑爹的让你延时时间到1个小时。为什么?因为代码不能动了,只有让SI的管理员在中间件上改参数了。你重改的代码即使build了也不能发布到集群节点上了,为啥?你没有权限,甲方没有审查签字,甲方在干嘛?甲方在忙着年终决算,忙着XX忙着YY。

九、硬件扩容?分包给了别人,利润蛋糕都切完了,没有人会管你

十、架构设计?SI没有足够的利润请淘宝、京东、携程、微博这样的有分布式架构、互联网web设计经验的外包。腾讯的马化腾也没有理由干这么个水深的场子,利润率还不如卖几个Q币来的扎实。

十一、再外包救火?你傻啊,再外包意味着事干完了干得好不是你的功劳,还影响你的位置,干得不好够你喝一壶的。就算你的私下找到了支付宝的牛B架构师程序员出来友情出演一把,个婊子,你还得自己先垫钱给人家解决差旅,自己已经有好几个月的铁道部驻场三陪吃喝玩乐费用没有报销了,老子的白金信用卡额度也要刷爆了。还得抽空回公司一趟贴发票签字拿钱。

十二、这个项目面对春运,面对年关,团队的兄弟们都指望着年底发多少钱呢,这个通胀压力大的年代,谁能有持久性的专业态度来两耳不闻窗外事,一心只写好负责的代码呢?因此这个时候,什么RUP,什么XP,什么敏捷,都扯淡吧,军心难易啊,没给你消极怠工算给你面子了。更何况这个项目抽调了SI公司几个事业部的人,对于SI这样的占山头气氛普遍的公司来说,没有一个牛B的政委,开发计划是无法落实的,甘特图成了摆设。日报周报成了负担。

十三、项目到了后期了,才知道为啥人家甲方数据科的王姐不配合我,原来不是我长的丑,是我公司档了人家的财路。唉,咋办咧?项目经理开个小会,这样,人盯人吧,三陪卖身反正兄弟们不亏,想尽办法逐个击破,小张啊,我们这些兄弟就数你最懂女人,最帅了,这个事你就多担待点了。我会在刘总那儿美言几句,明年调你做行业二部副理。——诺——须知一将功成万骨枯。每天都在上演很傻很天真的事。

十四、总算上线了,被投诉了,被落井下石了,被白搞了——结果,答应的承诺的,都没法兑现了——老板,您看,这年终奖是不是可以。。。——还好意思要钱?妈的,你们这个水平都被全国人民骂了,都上新闻联播了,老子的年终奖张总都扣了,你还好意思要。。。

十五、悲催的加班、陌生的嘴脸。结论:又是一帮没有拿从业许可证的IT民工的责任,铁道部已经责成。。。要求。。。2012年订票系统将会重新招标。。。新的故事又开始了,刘处,去年他们中了标,今年要不给李处个面子,让山东那公司来做,赚钱轮流做嘛。“好说,好说”

原文URL: http://blog.csdn.net/jaminwm/article/details/7183773

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

本文作者肖新光,网络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