登录请求发出去的密码明文那一刻，你的传输账号和密码正在以明文形式穿过三层路由器、两个交换机，漏洞最后到达服务器。密码明文中间任何一个节点，传输只要有人架一台抓包设备，漏洞就能完整看到那串字符。密码明文这不是传输什么高深攻击，就是漏洞最基础的网络嗅探。

2019年我帮一个朋友看他公司内网。密码明文他用的传输是某款开源OA系统，登录页面走HTTP，漏洞没有任何加密。密码明文我在他办公室的传输交换机上插了一台笔记本，开了Wireshark，漏洞让他随便登录一次。不到三秒，POST请求里的username=admin&password=Admin123就躺在抓包结果里，干干净净，连编码都没做。他愣了半天，说这系统用了三年了。

问题的根源在于HTTP协议本身不加密。浏览器把表单数据拼成请求体，TCP负责传输，整个过程就是裸奔。你以为密码框里显示的是圆点就安全了？那只是UI层面的遮挡，跟传输安全毫无关系。开发者如果不在前端做加密、不在传输层加TLS，密码就是一张明信片。

有人会说，那就上HTTPS呗。对，HTTPS确实能解决传输加密的问题。但现实里我看到的情况是，很多内部系统、测试环境、甚至部分生产环境仍然跑着HTTP。原因五花八门：证书要钱、配置嫌麻烦、内网觉得没必要。尤其是内网系统，开发者总觉得“外面进不来就没事”。

这个逻辑有个致命漏洞。内网不等于可信网络。ARP欺骗、DNS劫持、恶意交换机镜像端口，随便一个手段就能让攻击者在内网里截获流量。更别提员工连了不安全的WiFi，或者VPN配置有问题导致流量走了公网。攻击面比想象中大得多。

还有一种情况更隐蔽：前端确实加密了，但用的是可逆算法，密钥硬编码在JavaScript里。我见过一个系统，前端用AES加密密码，看着挺正规。结果密钥就写在encrypt.js第12行，var key = "1234567890abcdef"。任何人打开开发者工具都能看到。这种加密跟没加密的区别，只是多了一层自欺欺人的心理安慰。

正确的做法其实不复杂。第一选择永远是全站HTTPS，用TLS 1.2以上版本，禁用弱加密套件。这是传输层的事，不该让应用层去补。如果确实有特殊场景没法上TLS，那至少在前端用非对称加密，公钥加密、私钥解密，而且私钥必须留在服务端。但说实话，这种做法只是权宜之计，维护成本高，还容易出错。

另外，别忽略日志。我排查过一次数据泄露，最后发现是Nginx的access log把POST请求体完整记录了下来，包括密码。日志文件权限没控好，运维人员随便就能翻到。传输加密做了，落地没做，照样白搭。

密码明文传输这个问题，技术上早就有了标准答案。它之所以还频繁出现，不是技术难，是意识问题。开发者觉得“没人会盯着我的流量”，运维觉得“内网能出什么事”，产品觉得“先上线再说”。每一环都在赌，赌输了就是用户数据裸奔。

抓一次包就知道了。真的，就一次。