密码在网络上裸奔，密码明文这事儿比你想的传输普遍得多。随便抓个老牌论坛或者内部管理系统，解决用开发者工具看一眼登录请求，办法password字段后面跟着的密码明文往往就是明文——你输入的每个字符，都原封不动地送到了服务器。传输这不是解决段子，是办法2010年代之前大量网站的真实写照，甚至现在仍有不少老旧系统这么干。密码明文

明文传输的传输后果有多严重？抓包工具一开，WiFi环境下的解决HTTP请求就像明信片，谁路过都能瞟一眼。办法更别提那些喜欢把密码存在浏览器里、密码明文又同步到云端的传输用户，一旦某个环节泄露，解决撞库攻击能让你在各个平台的账号连环沦陷。我见过某公司内网系统，登录页连HTTPS都没上，运维小哥的密码直接在办公网里裸奔了半年，直到被安全审计揪出来。

解决办法其实不复杂，第一道防线就是HTTPS。别小看这个“S”，它把HTTP报文整个塞进TLS加密隧道里，中间人就算截获了数据包，看到的也只是一堆乱码。部署证书现在便宜得很，Let's Encrypt甚至免费，唯一麻烦的是有些老系统改配置要动架构，但这是绕不过去的坎。我见过最顽固的案例是某银行内部系统，因为对接的旧设备不支持TLS 1.2，硬是拖到监管部门下通牒才升级。

但光靠HTTPS还不够。就算加密传输，服务器端存储的如果是明文密码，数据库一泄露照样全完。所以第二道防线是哈希加盐。SHA-256这类算法算得快，但扛不住彩虹表，得加随机盐值再迭代个几千次，比如用bcrypt或PBKDF2。有个细节很多人忽略：盐值必须每个用户独立随机生成，要是全站共用一把盐，攻击者直接算一个表就能批量破解。

还有个更激进但有效的办法——干脆不让密码经过服务器。前端用JavaScript做哈希，把原始密码在浏览器里就转换成摘要，服务器只存摘要。这样即使传输层被扒了，攻击者拿到的也不是明文。不过这种做法有争议，有人觉得前端哈希等于把算法暴露给攻击者，反而给了离线爆破的靶子。我自己试过几次，觉得适合对兼容性要求不高的内部工具，对外服务还是老实走HTTPS加后端哈希更稳妥。

最后说个容易踩的坑：别以为加了密就能一劳永逸。有次我审计某系统，发现他们HTTPS和哈希都做了，但登录接口居然支持重放攻击——攻击者把抓到的密文原样再发一遍，服务器照样认账。解决办法是加时间戳和随机nonce，服务器验证请求是否新鲜。这细节看着小，但漏了它，前面所有努力都白费。

密码这事儿，本质上是个信任链问题。从你键盘到服务器，每一跳都得有防护，链条上最弱的一环决定安全等级。别嫌麻烦，也别迷信某个单一技术，把HTTPS、加盐哈希、防重放这几层都叠上，才算真的把密码从裸奔状态救回来。