浅谈IM软件怎样建立安全socket连接、登录

----------------------------------------------------欢迎查看IM软件业务知识《专栏》-------------------------------------------------------------------
使用状态机来保持在线状态 【点击】                      拼图算法，将零碎小图，整理到一张大图上【点击】
登录导航 【点击】                                                   会话session的概念【点击】       
“假在线’ 【点击】                                                    非对称加密，RSA算法【点击】
怎样建立安全socket连接、登录 【点击】               浅谈断线重连、心跳和长在线 【点击】
iOS client创建网络连接。常见错误汇总 【点击】 protocolBuf 在iOS上的使用入门、解说、指南 【点击】
实现富文本解析【点击】                                          UITableview Deceleration 加速滑动（惯性滑动）、弹性回归原理【点击】
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

一、概述

今年3月份。在QQ公布带有“支付功能和设备锁”的版本号的时候。当时就想写一下IM软件安全登录相关的博客。现在IM软件已经逐步称为一个平台，他的安全性不可马虎！今天有时间，写一段IM登录的文章吧

登录承接者建立安全连接的重任。

提到登录。作为IM软件第一步可谓首当其冲，用户password在此处输入，安全意义不言而喻。登录信是最复杂信令之中的一个，能够肯定的说，登录信令的应答码是最多的，不唯独200错误码，400错误码，500的应答码，甚至达到20种应答，不同错误码代码不同结果。每一个都须要处理。

二、怎样建立安全socket连接

首先是网络连接，我们跳过去。本博文前提网络已经连上，client准备发起身份认证，我把安全策略形容成是一层层的。最主要的一层就是对明文password的保护。

第一层、保护password

对password进行，sha1或者MD5，进行信息摘要。避免传递明文。这样的称为“摘要认证”。下图是MD5加密前后对照，MD5的特点是，不管多长的输入，输出固定长度且唯一的字符串。

“信息摘要”做到了以下几点：

● 永远不会以明文方式在网络上发送password。（假设本地有存储，也是摘要信息，不要存储明文）

● 能够防止恶意用户捕获并重放认证的握手过程。

● 能够有选择地防止对报文内容的篡改。

第二层、防止重放

使用摘要就无需用明文发送password了，只隐藏password不能避免危急，即便不知道password，黑客也能够截获摘要。再次发给Server。伪装登录。可是使用【时间戳+随机数】来防止反复。

这样的方法简单。不须要服务器向client发送随机数，而是依赖时间戳。

Server能够控制时间窗体，防止重放。

为什么还要用“时间戳”？
     由于：Server不可能记住全部的随机数，比方说一年前的，所以须要一个时间来限制，server只记录这段时间内的随机数。不在这个时间范围内的，就觉得是曾经的重放
     缺点：通信各方的计算机时钟保持同步，假设client和Server时间不同步。

那么client可能须要使用Servertime进行认证了。
下图展示了一次。重放的过程

（上面图片来自百度百科）

第三层、数字签名

这里举例：选择明文攻击。简单的说就是假设Server也被假冒了怎么办？

摘要认证的client会用服务器提供的随机数来生成response。

可是。假设中间被恶意代理拦截。代理伪装Server给client发送随机数。这个是可怕的，假如代理有一个经常使用摘要字典，能够将client生成的摘要，反解出来password。这样的攻击叫“选择明文攻击chosen plaintext attack”，我觉得名字起的不好，不能顾名思义。

防止此类攻击的办法能够通过“随机数”+“非对称加密”来实现，比方RSA非对称加密算法。例如以下图时序图：

从我项目经验来看。client对signature的验证使用的publickey。并非服务器应答中的public-key，而是一个内置的hexString（能够转换成内置公钥）。其实server也有一个内置的私钥，server第一步应答是用的内置私钥加密。

然后client验证。

至于public-key每次登陆都不同（server有一个素数池子，能够高速生成私钥和公钥）。
其实，sNoce、cNonce和password这个搭配。跟https的三个随机数【点击】相似
更具体见 http://blog.csdn.net/hherima/article/details/31356575

三、怎样建立安全socket连接，其它措施

● 机器指纹，指的是手机的IMEI。model，IMSI等等信息。尽管依照隐私法，IM软件提供商。不能这么做。可是。为了安全都这么做。

● 图形验证码

1.山寨client 、恶意client会频繁发送登录信令，造成Server阻塞，须要图验拦截。

2.有些IM软件能够用手机号登录，可能要给手机发短信password，这样的情况，就会出现短信炸弹的问题。一个人用IMclient输入别人的号码，使劲儿下发短信password。

● IP地址收集。

● 更安全的做法。

比如：QQ设备锁。应该是基于机器指纹，在Server端存储。限制登录。

查阅了一些资料后发现：要像建立安全连接，防止重放是必须要做的。防止重放能够通过随机数来解决。

还有就是中间代理的一些漏洞，这些比較不优点理，能够添加两方验证来解决！

就像刚刚将到的“选择明文攻击”。

四、趣事、bug

问题描写叙述：

1. 用户输入错误password过多。client弹出图形验证码。

2. 用户输入正确的password，结果仍弹出图验，

3. 用户再次输入正确password，还是提示图形验证码。死循环了。一直图验。

把bug告知Server了。

Server的解释是这样的：“登录信令中。假设'时间错误'(402)和'图验错'(421)一起出现，Server只会应答421，图验最优先”，client正是由于“时间错误和图验”一并出现，导致死循环。

● client的逻辑：收到421应答，去下载图验。

用户点击登录（仍携带本地错误时间）；Server应答402，同一时候包含Server时间值。

● client马上使用Server时间，再登录（此次不会带图验），Server仍会返回421须要图验，

● 最后，死循环了。

解决的方法：

● client这么改动：client收到402的时候。再去请求图验。

client开发不太允许，原因有两个：

1. 首先要记录上次的登录状态，假设是图验。还要再次下载图验，逻辑复杂。

2. client体验也不好，会弹出两次图验。第一次是正常的图验。第二次是client收到402后。再次下载图验。

● Server这么改动：Server在421的时候将Server时间一并下发，client使用正确的Server时间和图验实现登录。

client改动小。

终于是Server做出了改动。

● 2013年，我在用百度音乐登录的时候，也曾遇到相似的问题。总是提示我图形验证码。预计是相似的问题。