Password may not contain: select, insert, update, delete, drop

Original Article ↗ Hacker News Discussion ↗

A university password-reset page that bans passwords containing SQL keywords like “select”, “insert”, and “drop” has triggered debate over what this reveals about its security practices. Commenters argue that such keyword filters are classic “security theater” that hint at unsafe handling of plaintext passwords and a lack of parameterized queries, though some see them as a crude form of harm reduction in environments with legacy systems or overzealous web application firewalls. The exchange broadens into a critique of weak industry standards for password storage, client-side hashing, and regulatory accountability for data breaches.

Implications of the Password Keyword Ban

  • Many see the “no select/insert/update/delete/drop in password” rule as a red flag for poor security practices, suggesting:
    • Possible string‑concatenated SQL queries instead of parameterized queries.
    • Possible handling of plaintext passwords inside SQL rather than only hashes.
  • Others argue it might just reflect a misconfigured WAF or legacy system, not necessarily the current backend, but still indicates something is poorly implemented.
  • One commenter from the site clarifies this particular page is just an interface to external account management and that the text was added by request, with no clear technical reason.

Proper Handling of SQL and Passwords

  • Strong consensus: correct defense against SQL injection is parameterized queries, not keyword blacklists or manual escaping.
  • Blacklist/“sanitization” approaches are criticized as fragile, bypassable, and hard to maintain.
  • Multiple comments stress that passwords should:
    • Be hashed (with salt, slow KDF) server‑side as early as possible.
    • Never be stored or logged in plaintext.
    • Ideally never reach the database in plaintext; only hashed values should.

Client‑Side Hashing, WAFs, and Protocols

  • Client‑side hashing is generally criticized:
    • Whatever is sent (hash or password) becomes the credential; enables “pass‑the‑hash” attacks and doesn’t protect against MITM or database leaks in a meaningful way.
  • Some mention PAKE/SRP‑style protocols that avoid sending the password at all, but note they’re rare in web apps.
  • Several speculate that overzealous WAF rules are blocking SQL‑like substrings (including in passwords and form text), causing user‑visible failures and prompting these “don’t use SQL words” notices.

Password Policy and Usability Problems

  • Banning common words like select conflicts with passphrase guidance and xkcd‑style multi‑word passwords.
  • Examples are given of:
    • Arbitrary length and character limits (e.g., 6‑digit PINs, 9‑character max, ASCII‑only).
    • Mismatched limits between “create” and “login” forms.
    • Filters mangling user input or silently dropping content that “looks like SQL” or HTML/JS.

Security Theater vs. Harm Reduction

  • One camp: these measures are harmful security theater; they:
    • Mask underlying incompetence.
    • Give false confidence.
    • Are trivial for attackers to bypass while frustrating users.
  • Another camp: in a world full of badly built systems that we can’t easily fix, even crude mitigations that block obvious injection patterns might reduce harm, especially if auditors or regulations can easily test them.
  • Counter‑argument: such half‑measures entrench low standards and delay real fixes; stronger legal and professional accountability is advocated instead.