北京
功能上线，测试通过，部署顺利，团队一片欢欣。与此同时，代码库某个角落里，密码正用MD5存着。此时此刻，有人在不到一秒内就能把它们破解出来。加密缺陷就是这种问题——它不报错，不让持续集成流水线变红，只安静地躺在生产环境里，直到再也藏不住的那一天。
OWASP把它放在最严重的Web应用漏洞Top 10第二位，不是第七，也不是第五，是第二。定义听起来简单得离谱：敏感数据没有经过加密保护，或者保护得很差。“保护得很差”这部分，才是绝大多数开发者踩坑的地方。不是完全跳过了加密环节，而是用了错误的算法、搞砸了密钥管理，或者信任了一个自2004年起就不再安全的默认配置。结果都一样：本该锁死的数据，被人未经授权地访问了。
这类问题反复出现，根因集中在三个方面。第一是使用弱算法或已废弃的算法。不是所有加密都等效，十年前被视为安全的算法，放到现代硬件面前可能脆弱不堪。最常见的罪魁祸首：用MD5做密码哈希。MD5生来就不是为密码设计的，它专为快速校验而存在。快，正好是凭据哈希时最不想要的特性。快意味着攻击者能对着泄露的哈希数据库每秒跑上亿次尝试。
一个典型的Python反面案例是：用hashlib.md5(password.encode()).hexdigest()直接把“mypassword123”哈希存储。Freecycle数据泄露事件就是这种做法的后果——攻击者获取用户凭据，正是由于平台用了MD5。一旦拿到哈希数据库，破解密码就不是什么挑战，而是走个过场。正确做法是用bcrypt、argon2或scrypt这类刻意设计得缓慢的算法。bcrypt.hashpw配合gensalt才是Python里的安全姿势。同样的原则也适用于传输协议：SSL 2.0、SSL 3.0、TLS 1.0和1.1都已废弃，服务器如果还支持这些版本，等于主动给攻击者铺了一条降级通道。TLS 1.3是当前应该运行的最低版本。
第二个根因是糟糕的密钥管理。数据加密了，加密密钥却存放在同一个代码仓库里——这意味着什么都没保护住。把密钥硬编码进源码、提交到GitHub，甚至公开仓库，然后直接发到生产环境，这种情况出奇普遍。代码里写一行“const SECRET_KEY = 'my_super_secret_key_123'”不是机密管理，正确的思路是从环境变量或专门的机密管理器拉取密钥。不复杂，但需要刻意为之。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
