一些关于安全的话题

CSDN这次做的实在让人恶心,作为国内最大的技术宣传网站,对安全方面的无作为让人汗颜,更悲剧的是密码竟是明文。看到自己的邮箱印在那个名单上,不得已又得一次大规模更换密码和面对无法垃圾邮件骚扰。

http://t.cn/zOGBLjB

####密码如何保存

一般来说,密码都会被单向加密算法计算过保存到数据库中,之前的算法是MD5和SHA1,随着MD5的被中国女博士的破解,现在普遍的做法是使用SHA,Rails默认的应该是SHA512吧。但这种单向加密还有另一个问题,如果你足够有耐心,完全是可以把这个密码反向编译出来的。事实在上有确实有站点提供密码的查询,也就是输入一个计算过的密码,就能得出原始密码。

所以大家都会为用户再生成一个随机的salt,用密码加上这个随机值参于加密运算,这样用法拿到密码反编译的机会就小的几乎不存在了。

同时我开始便向于使用OpenID,最起码,我对Google更信任一点。算是对于网络上的自我保护知识上了一课!

####金山产品经理的职业道德

据传这数据库的大规模泄露是从一个金山的产品经理的迅雷上开始的,而该用户也强调只是转发,但从法理层面上来说,对违法的任何支持都是违法的一种。更别说还是金山安全部门的员工,让人恶心的职业道德。

####给FCity带来的警示

这件事没法不让FCity紧张,因为…你懂的。但这之后科学家们会怎么行动,也正是验证这家公司的未来的机会。

####信用卡信息保存

从密码明文讨论到信用卡信息的存储,一般来说我们需要用户的信用卡信息,而该信息应该怎么来保存。

当然首先想到的是双向加密,采用DS1这类的技术,将信用卡信息计算后,储存在数据库时,以后取时再经过解密算法。当然slat在这里也适用。

####真的是这样吗?

可能一般情况下认为加密的方式已经能解决问题了,但从软件工程学的角度来看,这真的是个好的方案吗。当然不是。

在信用卡上,谁是消费方和服务方,当然是App和银行,一个好的模式不是说App在请求中带着用户的信用卡信息提交给Bank,而应该是银行给该应用一个token,信用卡信息存储在银行单方。

流程如下:

用户在第三方APP需要输入信用卡进行支付(这里不是一般流程的网银支付),支付时App将用户引导至他所在的银行登陆,完成后再发一个请求到银行进行应用授权(也就是说,App问银行,我要从你这取钱,你愿意吗),用户会看到银行给出的确认窗口,点击“确定后”,应用就能按时从银行这里为信用卡扣账。

熟悉吧,微博的第三方应用授权就是这么一个流程,也就是OAuth的标谁流程。

这样一来,用户在银行一方可对每个应用授权进行统一管理,而不是到每个应用中去进行操作,方便。

安全,绝对的安全,谁知道第三方便会不会干什么龌龊的事情出来,就像CSDN一样,泄露了就麻烦了。

—–

####密码分析趣闻

有人专门分析了这600万用户密码,出其的是那些相同的密码规则,还有那些背后的段子,像以ilove开头的名中,燕排第一,梅列第二,静则位居第三。

而最常用的密码还是一些键盘上的相近组合。。。不过CSDN不是一个重要网站,所以大家密码比较随意也是情理之中。

####附上几个密码体微小说:

暗恋了她好几年,一直不敢表白。后来,他下载到一份CSDN泄漏的用户名密码名单,习惯性的查找她的邮箱,发现她使用的是ilove加自己名字的拼音作为密码,正感动得无以复加时电话响起,只听她电话那头颤抖着说:傻瓜,我看到了你的密码 。

【CSDN杯我最喜爱的CSDN密码评选】 纵使你用了ppnn13%dkstFeb.1st这样的密码又怎样,碰到傻逼网站照样泄露。 (密码的意思是“娉娉袅袅十三余,豆蔻梢头二月初”,来自唐代杜牧的诗,后两句是“春风十里扬州路,卷上珠帘总不如。”)