Senha não pode conter: select, insert, update, delete, drop

Artigo original ↗ Discussão no Hacker News ↗

Uma página de redefinição de senha de uma universidade que proíbe senhas contendo palavras-chave SQL como “select”, “insert” e “drop” gerou debate sobre o que isso revela sobre suas práticas de segurança. Comentadores argumentam que esses filtros por palavras-chave são clássico “teatro de segurança” e sugerem tratamento inseguro de senhas em texto simples e falta de consultas parametrizadas, embora alguns os vejam como uma forma grosseira de redução de danos em ambientes com sistemas legados ou firewalls de aplicações web excessivamente rígidos. A discussão se amplia para uma crítica aos padrões fracos do setor para armazenamento de senhas, hashing no lado do cliente e responsabilização regulatória por vazamentos de dados.

Implicações da proibição de palavras-chave na senha

  • Muitos veem a regra de “sem select/insert/update/delete/drop na senha” como um sinal de alerta de más práticas de segurança, sugerindo:
    • Possíveis consultas SQL concatenadas com strings, em vez de consultas parametrizadas.
    • Possível tratamento de senhas em texto simples dentro do SQL, e não apenas hashes.
  • Outros argumentam que isso pode apenas refletir um WAF mal configurado ou um sistema legado, não necessariamente o backend atual, mas ainda assim indica que algo está mal implementado.
  • Um comentarista do site esclarece que esta página específica é apenas uma interface para o gerenciamento externo de contas e que o texto foi adicionado a pedido, sem uma razão técnica clara.

Tratamento correto de SQL e senhas

  • Há amplo consenso: a defesa correta contra SQL injection são consultas parametrizadas, não listas negras de palavras-chave nem escaping manual.
  • Abordagens de blacklist/“sanitização” são criticadas por serem frágeis, contornáveis e difíceis de manter.
  • Vários comentários enfatizam que senhas devem:
    • Ser hashadas (com salt, KDF lenta) no lado do servidor o mais cedo possível.
    • Nunca ser armazenadas ou registradas em logs em texto simples.
    • Idealmente nunca chegar ao banco de dados em texto simples; apenas valores hash devem chegar.

Hashing no lado do cliente, WAFs e protocolos

  • Hashing no lado do cliente é, em geral, criticado:
    • Tudo o que é enviado (hash ou senha) torna-se a credencial; isso viabiliza ataques de “pass-the-hash” e não protege MITM ou vazamentos de banco de dados de forma significativa.
  • Alguns mencionam protocolos do tipo PAKE/SRP que evitam enviar a senha, mas observam que são raros em aplicações web.
  • Vários especulam que regras excessivamente rígidas de WAF estão bloqueando substrings parecidas com SQL (inclusive em senhas e texto de formulários), causando falhas visíveis para o usuário e levando a esses avisos de “não use palavras SQL”.

Problemas de política de senha e usabilidade

  • Proibir palavras comuns como select entra em conflito com orientações de passphrase e com senhas multi-palavra no estilo xkcd.
  • São dados exemplos de:
    • Limites arbitrários de comprimento e caracteres (por exemplo, PINs de 6 dígitos, máximo de 9 caracteres, apenas ASCII).
    • Limites incompatíveis entre formulários de “criar” e de “login”.
    • Filtros que alteram a entrada do usuário ou descartam silenciosamente conteúdo que “parece SQL” ou HTML/JS.

Teatro de segurança vs. redução de danos

  • Um grupo: essas medidas são teatro de segurança prejudicial; elas:
    • Mascaram incompetência subjacente.
    • Dão falsa confiança.
    • São triviais de contornar por atacantes, ao mesmo tempo que frustram usuários.
  • Outro grupo: num mundo cheio de sistemas mal construídos que não podemos corrigir facilmente, mesmo mitigação grosseira que bloqueie padrões óbvios de injection pode reduzir danos, especialmente se auditores ou regulamentações puderem testá-las facilmente.
  • Contra-argumento: tais meias-medidas consolidam baixos padrões e atrasam correções reais; defende-se, em vez disso, uma responsabilidade legal e profissional mais forte.