换一种思路说登录验证.

泡不烂的凉粉 发布于 2013/12/28 18:07
阅读 2K+
收藏 17

登录验证, 就是用户端发送用户标识, 用户密码串给服务端, 之后服务端经过查找比较,确定身份是否被允许,反馈给客户端.

今天突然想到,可以换种方式来验证.

说一下需求,为什么要换一种方式.  传统的方式进行验证的时候,如果网络被监听, 捕捉成功登陆的对话很容易窃取用户登录密码, 哪怕用户密码被md5过, 仍然可以用冒充的办法再次冒充登录, 就算用户密码被加点调料md5,仍然可以被不经过服务端验证情况下,暴力破解. 并且根据目前的计算当量. md5密码加密的暴力破解已经相当的容易.

新思路, 假设服务端有用户密码. 登录时候, 客户端发送用户名给服务端, 服务端返回一个用户密码外加调料经过md5编码后的字符串给客户端, 调料当中,有以下随机量, 和一些新的混杂串.同时返回给用户随机量.

客户端接收到反馈后. 用自己的密码加接收到的随机量内容, 另外根据特定算法,混入混杂串来计算, 看结果是否与服务端返回的串匹配. 如果都无匹配, 表示肯定登录出错了. 如果存在匹配,  获取混杂传作为新的加密钥匙,与服务端通讯,获取登录标识.

混杂串的生成,  可以简单的是0-9, 这样客户端需要计算10次结果来匹配是否与服务器返回结果相同. 也可以采用更为复杂的方式,让客户端来计算.

这样的好处. 首先, 由服务端发送的混杂串以及随机串是客户端无法伪造的. 只能被动获取. 并且验证主要的计算量在客户端, 如果网络通信被监听, 要想仿制登录, 必须有用户密码才可能根据混杂串计算, 密码被泄漏概率小得多.  适当增加混杂串计算强度, 可以有效缓解暴力破解难度, 暴力尝试登录会被服务端获取到,很容易被锁定账号, 至少可以限制帐号登录. 伪装登录服务器, 由于随机量是服务端生成,且有固定算法保证随机量在很大范围内不可能重复, 所以可保证再次伪装登录绝对不可能成功.


说了有点罗嗦,  举个简单例子.

用户标识 test, 用户密码经过md5后是 321, 服务端保存的是密码经过md5后的值,也就是321

客户端登录, 提交test给服务端, 服务端从数据库中搜索到密码md5值是321, 用当前时间毫秒,假设是,456,外加一个混杂串, 假设是89,组成的新串, 32145689经过md5后发送给客户端.同时发送456给客户端.

客户端接收到这个md5, 开始尝试用 md5(32145600),md5(32145601),md5(32145602),与服务端反馈内容匹配.

当匹配到 32145689的时候, 认为服务端发送的新要是是89, 可以发送 md5(32189) 和用户名给服务端. 获取真正的登录认证.

89就是混杂串, 根据需求增加混杂串的构成增大客户端计算强度, 哪怕网络被监听,也无法获取用户密码 321. 也无法用旧的登录串重复上述过程. 更没办法暴力猜测登录.

加载中
1
终曲
终曲
注册填密码、修改密码时候怎么办,始终无法避免的问题就是客户端提交密码(即使是加密过的),如果一个办法不能解决全部的问题,何必徒增复杂程度
0
深圳小兵
深圳小兵
嗯,挺好...
0
L5_Railgun
L5_Railgun

只要你能做到不被key-log,密码一般很安全。

你这种认证方法,可以说毫无实际应用意义

1:我不关心你的认证流程是什么,直接拿到你的access token就够了

2:你的思路,唯一的保证就是那个混淆串,太短,容易被搞定,太长,你的客户端就算死吧

3:你这种本质上也是对称加密,你的算法代码可以说毫无秘密可言,你加壳,加花,甚至VM又如何?

4:对称加密无法防范中间人攻击


所以说,使用非对称加密算法的认证体系才有一定的安全强度

如果你对安全强度要求不高, 那大可使用TEA这类高效加密算法即可,也不是你这种低效的加密

0
泡不烂的凉粉
泡不烂的凉粉

 只要不是信息加密, 所有认证拿到 access token 都可以伪造.
这段只是对于认证部分的验证过程. 你说的缺陷是所有方法中都存在的缺陷,
我提到的方法只是作为身份验证的一个新的思路.

0
实迷途其未远觉今是而昨非
实迷途其未远觉今是而昨非
长连接才能防止中间被篡改吧
0
二进制宇宙
二进制宇宙
密码学里的书通篇都是这种算法的讨论,简单问题搞得那么复杂,还是留给专家教授去研究吧
0
jarly
jarly
写个浏览器插件,实现一个类似VPN的基于TCP/IP的独立密匙传输通道
0
Andy
Andy
任何算法只能解决端对端的传输安全
0
泡不烂的凉粉
泡不烂的凉粉

楼上的已经说过了. 这就是对称加密. 只不过作为验证,并没有做还原, 也不可能被还原.

说到复杂度. 以上步骤根本算不上复杂, 是很简单的流程, 客户端发起请求, 服务端回应, 客户端回应, 服务端验证. 4个步骤而已, 第一个步骤是任何验证方式都必须有的. 差别只是多了服务端回应和客户端回应的,  多了这两个中间步骤可以有效的防止网络监听中 被第三方暴力猜测密码.  算法是透明的,并且钥匙是不经由网络直接传输的, 并且传输验证部分是一次性的, 不可逆. 比如, 第三方要想通过客户端认证的最后一次回应中破解密码, 需要知道混杂串89,才能暴力猜测用户密码321,  但是要想猜测89, 就必须知道用户密码321才能猜测89. 因为不知道321,无法猜测89.同理,因为不知道89,无法猜测321是一个道理.  另外,哪怕现在已经出现了好的算法, 能快速生成 md5冲突. 也无法复制这个过程, 应为混杂串89是服务器生成的, 客户无法控制, 并且服务器端生成的随机数456是一次性的, 更无法重复利用.

0
梅州_罗文强
梅州_罗文强
为何不使用https和密钥对加密链路来进行验证用户的请求呢?你把密码比较的规则放到浏览器端,直接就可以绕过验证,根本和没有密码效果一样。因为那个浏览器可能直接给你加上一段:无论如何让你的验证都通过……
返回顶部
顶部