这是一个创建于 360 天前的主题，其中的信息可能已经有所发展或是发生改变。
其实这个疑问在现在这个时间节点上不应该成为问题，因为现在的网络协议都基本带上 ssl 了，如 https 。
但在当初不普及 https 的网络年代，抓包的方式很容易捕获传输数据，特别是像密码这样的数据。 先说一下以前乃至现在比较常规的登录方式吧。
无非就是客户端/web 输入 username 和 MD5(password) ,然后 post 的方式提交到服务器，尽管 password 使用了 MD5 函数，但是结果还是不变的，只要密码没有被修改，这个值是不会变的，别人盗取了这部分数据依旧可以模拟你的登录。 但，如果流程这个环节使用签名的方式，就不一样了。
让客户端设置一个当前时间戳 timestamp , 登录时将 username + timestamp 则为明文 P，然后用 MD5(password) 为签名秘钥 S,得出 sign = HASH(P+S)。
传输的过程中仅将 username, timestamp , sign 提交到服务器，那么即时明文状态下被抓包，对方也无法得出关键数据 password or MD5(password),而且服务端可以根据 timestamp 计算时间差，比如 5 秒内有效，使得监听者在超过时效范围内无法通过重放请求实现登录。
这个就是单纯的签名流程在现在的开放平台上(openapi)应用非常广，理论上当时就应该有，可是为什么在 http 流行的网络年代没有被应用在登录流程上。
 |
1
flyqie 360 天前 via Android
你这方案能防盗号，但是仍然可以在其他点抓包拿其他信息。。
可能是觉得成本和回报不成比例？ |
 |
2
tool2d 360 天前
其实是有的，只是你不知道。
2005 年左右 mysql 很火，远程登录并没使用 SSL 加密协议，但密码还是用服务器返回的 token 加密过了。就是为了防抓包。 |
 |
3
i8086 360 天前
楼主说得这一套，网易和腾讯是有用上的。
|
 |
5
element90 OP @tool2d 哈哈，可能是我孤陋寡闻了，因为当年我在参加工作的时候没有考虑到这么多，同时也没有任何人或者在任何团队上看到这种方式，所以完全没有看到这方面的应用，直到现在突然联想到这个问题发现当时没人这么做非常不合理。原来早就有了啊。。但是没有大规模形成实现标准，这也非常不合理啊
|
 |
7
muzuiget 360 天前
你整套加密方法被中间人都知道的话，你加密花活再多也没用，中间人一样可以推理出来，“信任链“了解一下。
|
 |
8
liuidetmks 360 天前  1
HMAC ？
|
 |
9
victimsss 360 天前
别说优化了，当时还有网站明文保存密码呢。
 |
 |
11
Seulgi 360 天前
就是一个安全性的考虑问题而已。当年还没到考虑安全的地步，就跟当年还没到考虑高并发高可用的地步一样。都是一步一步升级来的。
|
 |
12
laqow 360 天前
现在小鬼全在 VPS 练手，抓包都没出第一级路由就被抓了，5 秒能重放无数遍了吧
|
 |
14
shellus 360 天前
sign = HASH(username + timestamp + MD5(password) )。
POST Login：{ username, timestamp , sign } 服务端怎么验证 sign ？需要服务器持有 MD5(password) 是吧？ 风险点 1：服务器持有固定的 md5 风险点 2：登陆后得到的 token 或 sessionId ，仍然可以被利用。 风险点 3：后续请求没有整体签名和加密，仍然可以被监听和篡改。 最重要的，这个方法没有办法阻止中间人返回钓鱼页面或者注入恶意 JS 代码，中间人可以篡改登陆页面响应，注入一段键盘监听的 JS 脚本，或者干脆返回整个假的页面诱使用户输入密码。 |
|
15
element90 OP |
Select Language