密码不得包含：select、insert、update、delete、drop

原文 ↗ Hacker News 讨论 ↗

一个大学密码重置页面禁止密码包含“select”“insert”“drop”等 SQL 关键字，引发了人们对其安全实践的讨论。评论者认为，这类关键字过滤是典型的“安全表演”，暗示其对明文密码的处理方式不安全且缺乏参数化查询；不过也有人将其视为在遗留系统或过度激进的 Web 应用防火墙环境中的一种粗糙减害手段。这场讨论进一步延伸到对密码存储、客户端哈希以及数据泄露监管问责等薄弱行业标准的批评。

密码关键字禁用的影响

  • 许多人将密码中“不能包含 select/insert/update/delete/drop”的规则视为安全实践不佳的危险信号，这暗示：
    • 可能使用字符串拼接的 SQL 查询，而不是参数化查询。
    • 可能在 SQL 中直接处理明文密码，而不仅仅是哈希值。
  • 也有人认为，这也许只是误配置的 WAF 或遗留系统的表现，不一定反映当前后端，但仍说明某处实现得很糟糕。
  • 来自该站点的一位评论者澄清，这个页面只是外部账户管理的一个界面，且这段文字是按要求加上的，并没有明确的技术原因。

SQL 和密码的正确处理方式

  • 广泛共识：防止 SQL 注入的正确方式是参数化查询，而不是关键字黑名单或手动转义。
  • 黑名单/“清洗”式方法被批评为脆弱、可绕过且难以维护。
  • 多条评论强调，密码应该：
    • 尽早在服务端进行哈希处理（加盐、使用慢速 KDF）。
    • 绝不以明文存储或记录日志。
    • 理想情况下不应以明文进入数据库；只应保存哈希值。

客户端哈希、WAF 和协议

  • 客户端哈希通常受到批评：
    • 无论发送的是哈希还是密码，它都会成为凭证；这会使“pass-the-hash”攻击成为可能，并且并不能有意义地防止 MITM 或数据库泄露。
  • 有人提到 PAKE/SRP 之类的协议可以避免直接发送密码，但也指出它们在 Web 应用中很少见。
  • 多人推测，过于激进的 WAF 规则正在阻止类似 SQL 的子串（包括密码和表单文本中的内容），导致用户可见的失败，并促使出现这些“不要使用 SQL 词语”的提示。

密码策略与可用性问题

  • 禁止像 select 这样的常见单词，与口令短语指导原则以及 xkcd 风格的多词密码相冲突。
  • 文中举例包括：
    • 任意的长度和字符限制（例如 6 位 PIN、最多 9 个字符、仅限 ASCII）。
    • “创建”和“登录”表单之间的限制不一致。
    • 过滤器篡改用户输入，或静默丢弃看起来像 SQL 或 HTML/JS 的内容。

安全表演与减害

  • 一派观点认为：这些措施是有害的安全表演；它们：
    • 掩盖了底层的无能。
    • 给予虚假的安全感。
    • 对攻击者来说很容易绕过，却让用户感到困扰。
  • 另一派则认为：在充斥着糟糕系统、而我们又难以轻易修复的世界里，即使是阻止明显注入模式的粗糙缓解措施，也可能减少危害，尤其是如果审计人员或监管机构可以轻松测试它们。
  • 反驳意见是：这种半吊子措施会固化低标准并延缓真正的修复；应当转而主张更强的法律和职业问责。