建立安全通道遇到的问题

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

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

第一阶段（裸奔）

数据库直接存储密码、请求包、回包均为明文且带上了密码和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换取的一种业务票据，用于访问业务鉴权，权限较低。

如果文章对您有帮助，欢迎扫描下方二维码赞助(一分也是爱噢)，谢谢