建立安全通道遇到的问题

• 钓鱼、木马（神都救不了你，赶紧改密码吧）
• 脱裤、撞库（祈祷别人不是存明文密码吧）
• 暴力**（如彩虹表、简单密码暴力**）
• 重放、伪造登录
• 窃听（伪造服务器、伪造客户端、中间人攻击）
• 前向安全

 

如何设计一个安全的登录过程

 

第一阶段（裸奔）

数据库直接存储密码、请求包、回包均为明文且带上了密码和key。解决不了上面的任务问题，登录设计的所有大忌均犯了。

 

第二阶段（简单加密）

请求包和回包使用密码加密（通道加密√），但数据库依旧存储明文密码，容易被脱裤、暴力**。

 

 

第三阶段

客户端生成随机**，服务器使用随机**加密回包包体，每次登录均不一样的随机**。

 

第四阶段（存非明文密码）

加***为密码的md5，数据库不存明文密码（不存明文密码√）。但没有加盐，仍然不能防止暴力**。

 

 

第五阶段（加盐）

加***加验（加盐√、防撞库√），防止了暴力**和脱裤后对其他同行的数据库进行撞库。但脱裤后容易被坏人伪造服务器。

 

 

第六阶段

客户端密文包体带上密码的md5。即使被脱裤，坏人也无法得知md5（psw），服务器使用md5（psw）跟uin再算一次H即可验证用户的合法身份，无法伪造客户端登录（防伪客户端√）

 

第七阶段（时间戳+kerberos）

加上时间戳，防止一段时间后坏人重放（防止重放√）。返回票据后端校验票据（遵循kerberos鉴权√），其中票据使用vaskey加解密，只有服务器知道**（防篡改√）。

 

第八阶段（ECDH）

加上ECDH**协商，其中客户端hardcode了非对称**（B、b，其中B为公钥，b为私钥，**hardcode是为了防止**在公网上传播，并生成随机**对A、a），防止中间人攻击（防中间人√），但前向不安全（A必须在公网上传播），一旦非对称**泄漏（B、b），坏人就可以解出历史上抓到的所有包。

 

第九阶段（前向安全）

在第八阶段的前提下，后台在随机生成一对随机对称**（C、c），回包加密时再通过ECDH套多一层（A跟c协商**，因坏人最多只知道A跟C，且C/c是服务器一段时间更换一次，无法对历史包解密）（前向安全√）

 

设计原则

备注

• 接入层跟客户端之间所有加密均使用对称加解密算法TEA
• 大大票（TAG_ID_TGTGT_SIG）：由密码组装的包含自身信息的票据（A1）。
• H=md5(md5(pwd)+uin)。
• A1= TEA(H, uin + time + md5(pwd) + randkey[16]+ …)//用H作为**加密包体。
• TGTGT_KEY：客户端生成的随机Key，由登录后台服务器解密后获取返回给接入层的。
• 大票（TGT）：通过TGTGT登录后，由登录后台派发的高权限登录凭证。登录后台加密生成的TGT中包含随机**GTK_TGT。
• GTK_TGT：由登录后台生成的随机**。
• ST：业务小票，是通过TGT换取的一种业务票据，用于访问业务鉴权，权限较低。