La contraseña no puede contener: select, insert, update, delete, drop

Artículo original ↗ Discusión en Hacker News ↗

Una página de restablecimiento de contraseñas de una universidad que prohíbe contraseñas que contengan palabras clave SQL como “select”, “insert” y “drop” ha desatado un debate sobre lo que esto revela acerca de sus prácticas de seguridad. Los comentaristas sostienen que estos filtros por palabras clave son el clásico “teatro de seguridad” y apuntan a un posible manejo inseguro de contraseñas en texto plano y a la falta de consultas parametrizadas, aunque algunos lo ven como una forma tosca de reducción de daños en entornos con sistemas heredados o WAFs demasiado agresivos. El intercambio se amplía hacia una crítica de los débiles estándares del sector para el almacenamiento de contraseñas, el hashing del lado del cliente y la rendición de cuentas regulatoria por las filtraciones de datos.

Implicaciones de la prohibición de palabras clave en las contraseñas

  • Muchos ven la regla de “no select/insert/update/delete/drop en la contraseña” como una señal de alerta de malas prácticas de seguridad, lo que sugiere:
    • Posibles consultas SQL concatenadas con cadenas en lugar de consultas parametrizadas.
    • Posible gestión de contraseñas en texto plano dentro de SQL en vez de solo hashes.
  • Otros sostienen que quizá solo refleje un WAF mal configurado o un sistema heredado, no necesariamente el backend actual, pero aun así indica que algo está mal implementado.
  • Un comentarista del sitio aclara que esta página en particular es solo una interfaz para la gestión externa de cuentas y que el texto se añadió por solicitud, sin una razón técnica clara.

Manejo correcto de SQL y contraseñas

  • Hay un consenso fuerte: la defensa correcta contra la inyección SQL son las consultas parametrizadas, no las listas negras de palabras clave ni el escape manual.
  • Los enfoques de lista negra/“sanitización” se critican por frágiles, eludibles y difíciles de mantener.
  • Varios comentarios insisten en que las contraseñas deberían:
    • Hashearse (con sal, KDF lento) del lado del servidor lo antes posible.
    • Nunca almacenarse ni registrarse en texto plano.
    • Idealmente nunca llegar a la base de datos en texto plano; solo deberían ir valores hasheados.

Hashing del lado del cliente, WAFs y protocolos

  • El hashing del lado del cliente suele criticarse:
    • Lo que se envíe (hash o contraseña) se convierte en la credencial; permite ataques “pass-the-hash” y no protege de forma significativa contra MITM o fugas de la base de datos.
  • Algunos mencionan protocolos tipo PAKE/SRP que evitan enviar la contraseña en absoluto, pero señalan que son raros en aplicaciones web.
  • Varios especulan que reglas excesivamente agresivas de WAF están bloqueando subcadenas parecidas a SQL (incluidas en contraseñas y texto de formularios), causando fallos visibles para el usuario y provocando estos avisos de “no use palabras SQL”.

Política de contraseñas y problemas de usabilidad

  • Prohibir palabras comunes como select entra en conflicto con las recomendaciones de frases de contraseña y con contraseñas de varias palabras al estilo xkcd.
  • Se ponen ejemplos de:
    • Límites arbitrarios de longitud y caracteres (por ejemplo, PINs de 6 dígitos, máximo de 9 caracteres, solo ASCII).
    • Límites distintos entre formularios de “crear” e “iniciar sesión”.
    • Filtros que destrozan la entrada del usuario o eliminan silenciosamente contenido que “parece SQL” o HTML/JS.

Teatro de seguridad vs. reducción de daños

  • Un sector: estas medidas son teatro de seguridad perjudicial; ellas:
    • Encubren incompetencia subyacente.
    • Dan una falsa sensación de seguridad.
    • Son triviales de eludir para atacantes mientras frustran a los usuarios.
  • Otro sector: en un mundo lleno de sistemas mal construidos que no podemos arreglar fácilmente, incluso mitigaciones toscas que bloquean patrones obvios de inyección podrían reducir daños, especialmente si auditores o regulaciones pueden comprobarlas con facilidad.
  • Contraargumento: tales medias tintas consolidan estándares bajos y retrasan las correcciones reales; en su lugar se aboga por una mayor responsabilidad legal y profesional.