密码明文传输

登录页面上那个小小的密码明文“http”前缀，很多人根本不会多看一眼。传输浏览器地址栏左侧的密码明文锁头图标一旦消失，意味着你输入的传输账号和密码正在以明文形式穿越路由器、交换机、密码明文运营商骨干网，传输任何一个中间节点都能直接读取。密码明文这不是传输理论上的风险，是密码明文每天发生的事实。

2019年，传输某国内知名论坛被曝出用户登录请求走的密码明文是纯HTTP协议。安全研究者抓包后发现，传输用户名和密码字段在POST请求体里赤裸裸地躺着，密码明文连Base64编码都没做。传输Base64不是密码明文加密，它只是换了件衣服，谁都能解开。攻击者只需要在公共WiFi热点上跑一个ARP欺骗，把流量引到自己机器上，再用Wireshark过滤一下http.request.method == "POST"，密码就到手了。整个过程不需要任何高深技术，一个刚学网络安全的大学生都能完成。

有人觉得“我用的网站没什么价值，谁会盯着我”。这种想法忽略了一个关键点：撞库。攻击者拿到你在A站明文传输的密码，会立刻去试你的邮箱、网银、社交账号。因为大多数人所有平台共用同一套密码。一个低价值论坛的明文密码泄露，连锁反应可能让你损失真金白银。我见过一个案例，某小型电商网站明文存密码，数据库被拖库后，攻击者用这批密码成功登录了其中三千多个用户的支付宝账户。原因很简单——密码完全一样。

那为什么还有网站用HTTP？成本。HTTPS证书要钱，虽然Let's Encrypt提供了免费方案，但配置和维护需要技术人力。老旧系统改造麻烦，有些代码是十多年前写的，动一处可能崩一片。运维人员抱着“内网环境安全”的侥幸心理，觉得用户量小、攻击者看不上。可内网早就不等于安全区了，一台中招的办公电脑就能让攻击者在内网横向移动，嗅探所有未加密流量。

更隐蔽的问题是混合内容。网站主页面上了HTTPS，但登录表单的action属性指向http://。浏览器会显示“不安全”警告，可很多用户直接忽略。这种半吊子加密比纯HTTP更危险，因为它给了用户虚假的安全感。你看到地址栏有锁头，以为万事大吉，实际上密码正从锁头后面溜出去。

检测方法很简单。打开浏览器开发者工具，切到Network标签，勾选Preserve log，然后正常登录。找到那个POST请求，看它的Scheme列。如果是http，你的密码就在裸奔。或者用Fiddler、Charles这类抓包工具，手机连上代理，登录一次就能看到明文。我习惯在公共网络下先做这个检查，几秒钟的事，能避免很多麻烦。

个人能做的防护有限，但有几条实用建议。浏览器装HTTPS Everywhere扩展，它会把支持的网站强制跳转到加密版本。密码管理器生成随机密码，每个站点不同，这样即使某个站明文泄露，其他账户不受影响。看到登录页面没有锁头图标，直接关掉，换用官方App或者打电话确认。别嫌麻烦，你的密码比你想的值钱。

网站运营者该做什么？全站HTTPS，没有例外。HSTS响应头加上，让浏览器强制使用加密连接。登录表单提交前用JS做一次前端哈希？没用，中间人可以直接改JS代码。唯一可靠的是TLS层加密。证书配置用Mozilla的SSL配置生成器，选现代兼容模式。混合内容扫描工具跑一遍，把漏网的http资源全揪出来。这些工作半天就能完成，比出事后的公关危机便宜得多。

密码明文传输这件事，技术上的解决方案早就成熟了。剩下的纯粹是态度问题——你愿不愿意为用户的每一串字符负责。