----------------------------------------------------欢迎查看IM软件业务知识《专栏》-------------------------------------------------------------------
使用状态机来保持在线状态 【点击】 拼图算法,将零碎小图,整理到一张大图上【点击】
登录导航 【点击】 会话session的概念【点击】
“假在线’ 【点击】 非对称加密,RSA算法【点击】
如何建立安全socket连接、登录 【点击】 浅谈断线重连、心跳和长在线 【点击】
iOS 客户端创建网络连接,常见错误汇总 【点击】 protocolBuf 在iOS上的使用入门、讲解、指南 【点击】
实现富文本解析【点击】 UITableview Deceleration 加速滑动(惯性滑动)、弹性回归原理【点击】
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
一、概述
今年3月份,在QQ发布带有“支付功能和设备锁”的版本的时候,当时就想写一下IM软件安全登录相关的博客。如今IM软件已经逐步称为一个平台,他的安全性不可马虎!今天有时间,写一段IM登录的文章吧
登录承接者建立安全连接的重任。提到登录,作为IM软件第一步可谓首当其冲,用户密码在此处输入,安全意义不言而喻。登录信是最复杂信令之一,可以肯定的说,登录信令的应答码是最多的,不仅仅有200错误码,400错误码,500的应答码,甚至达到20种应答,不同错误码代码不同结果,每个都需要处理。
二、如何建立安全socket连接
首先是网络连接,我们跳过去。本博文前提网络已经连上,客户端准备发起身份认证,我把安全策略形容成是一层层的,最基本的一层就是对明文密码的保护。
第一层、保护密码
对密码进行,sha1或者MD5,进行信息摘要,避免传递明文。这种称为“摘要认证”!下图是MD5加密前后对比,MD5的特点是,无论多长的输入,输出固定长度且唯一的字符串。
第二层、防止重放
使用摘要就无需用明文发送密码了,仅仅隐藏密码不能避免危险,即便不知道密码,黑客也可以截获摘要,再次发给Server,伪装登录。可是使用【时间戳+随机数】来防止重复。
这种方法简单,不需要服务器向客户端发送随机数,而是依赖时间戳。Server可以控制时间窗口,防止重放。
为什么还要用“时间戳”?
因为:Server不可能记住所有的随机数,比如说一年前的,所以需要一个时间来限制,server只记录这段时间内的随机数。不在这个时间范围内的,就认为是以前的重放
缺点:通信各方的计算机时钟保持同步,如果客户端和Server时间不同步。那么客户端可能需要使用Servertime进行认证了。
下图展示了一次,重放的过程
(上面图片来自百度百科)
第三层、数字签名
这里举例:选择明文攻击。简单的说就是如果Server也被假冒了怎么办?
摘要认证的客户端会用服务器提供的随机数来生成response。但是,如果中间被恶意代理拦截,代理伪装Server给客户端发送随机数。这个是可怕的,假如代理有一个常用摘要字典,可以将客户端生成的摘要,反解出来密码。这种攻击叫“选择明文攻击chosen plaintext attack”,我觉得名字起的不好,不能顾名思义。
防止此类攻击的办法可以通过“随机数”+“非对称加密”来实现,比如RSA非对称加密算法。如下图时序图:
从我项目经验来看,客户端对signature的验证使用的publickey,并不是服务器应答中的public-key,而是一个内置的hexString(可以转换成内置公钥)。事实上server也有一个内置的私钥,server第一步应答是用的内置私钥加密。然后客户端验证。至于public-key每次登陆都不同(server有一个素数池子,可以快速生成私钥和公钥)。
其实,sNoce、cNonce和密码这个搭配,跟https的三个随机数【点击】类似
更详细见 http://blog.csdn.net/hherima/article/details/31356575
三、如何建立安全socket连接,其他措施
● 机器指纹,指的是手机的IMEI,model,IMSI等等信息。虽然按照隐私法,IM软件提供商,不能这么做。但是,为了安全都这么做。
● 图形验证码
1.山寨客户端 、恶意客户端会频繁发送登录信令,造成Server堵塞,需要图验拦截。
2.有些IM软件可以用手机号登录,可能要给手机发短信密码,这种情况,就会出现短信炸弹的问题。一个人用IM客户端输入别人的号码,使劲儿下发短信密码。
● IP地址收集。
● 更安全的做法。
例如:QQ设备锁,应该是基于机器指纹,在Server端存储,限制登录。
查阅了一些资料后发现:要像建立安全连接,防止重放是必须要做的,防止重放可以通过随机数来解决。
还有就是中间代理的一些漏洞,这些比较不好处理,可以增加双方验证来解决!就像刚刚将到的“选择明文攻击”。
四、趣事、bug
问题描述:
1. 用户输入错误密码过多,客户端弹出图形验证码。
2. 用户输入正确的密码,结果仍弹出图验,
3. 用户再次输入正确密码,还是提示图形验证码,死循环了,一直图验。
把bug告知Server了。
Server的解释是这样的:“登录信令中,如果'时间错误'(402)和'图验错'(421)一起出现,Server只会应答421,图验最优先”,客户端正是因为“时间错误和图验”一并出现,导致死循环。
● 客户端的逻辑:收到421应答,去下载图验。用户点击登录(仍携带本地错误时间);Server应答402,同时包括Server时间值。
● 客户端立即使用Server时间,再登录(此次不会带图验),Server仍会返回421需要图验,
● 最后,死循环了。
解决办法:
● 客户端这么修改:客户端收到402的时候,再去请求图验。客户端开发不太同意,原因有两个:
1. 首先要记录上次的登录状态,如果是图验,还要再次下载图验,逻辑复杂。
2. 客户端体验也不好,会弹出两次图验。第一次是正常的图验,第二次是客户端收到402后,再次下载图验。
● Server这么修改:Server在421的时候将Server时间一并下发,客户端使用正确的Server时间和图验实现登录。客户端改动小!
最终是Server做出了修改。
● 2013年,我在用百度音乐登录的时候,也曾遇到类似的问题,总是提示我图形验证码。估计是类似的问题。