Caracteres de inyección en contraseñas: por qué la contraseña más fuerte rompe el sitio web

El jefe planteó la pregunta con una sonrisa: ¿y si la mejor contraseña es la que hace colapsar el sitio web? Es una pregunta más profunda de lo que parece.

Así piensan la mayoría de las personas sobre los caracteres de inyección en contraseñas y la seguridad: elegir algo largo, mezclar mayúsculas, añadir un número, quizás un signo de exclamación. Los consejos apenas han cambiado en veinte años. Pero la amenaza real ha cambiado por completo. Ningún atacante va a sentarse frente a un teclado y escribir 500 millones de intentos a mano. El hardware moderno de descifrado puede probar miles de millones de hashes por segundo. La longitud de tu contraseña importa. El teatro de la complejidad, no.

Lo que sí importa, y de lo que casi nadie habla, es lo que ocurre cuando tu contraseña contiene caracteres que tienen un significado especial para el software detrás del formulario de inicio de sesión. Caracteres como ', ", ;, --, /, #, $ y |. No son meros signos de puntuación. Son instrucciones en SQL, en scripting de shell, en el análisis de URL. Y cuando un desarrollador negligente construye un formulario de inicio de sesión que envía tu contraseña directamente a una consulta de base de datos sin limpiarla primero, esos caracteres dejan de ser tu contraseña y se convierten en código.

Caracteres de inyección en contraseñas: cómo un formulario de inicio de sesión se convierte en una puerta trasera

El ejemplo clásico es la inyección SQLAtaque en el que código SQL malicioso se inserta en un campo de entrada para manipular o eludir consultas de base de datos.. Imagina una página de inicio de sesión que verifica tus credenciales así:

SELECT * FROM users WHERE username = 'tu' AND password = 'tucontraseña'

Si escribes cualquiercosa' OR '1'='1 en el campo de contraseña, la consulta se convierte en:

SELECT * FROM users WHERE username = 'tu' AND password = 'cualquiercosa' OR '1'='1'

Como '1'='1' siempre es verdadero, la base de datos devuelve todos los usuarios. Estás dentro. Sin contraseña. Como documenta la Web Security Academy de PortSwigger, un atacante puede iniciar sesión como cualquier usuario sin conocer la contraseña, simplemente usando la secuencia de comentario SQL -- para eliminar por completo la verificación de contraseña.

Este no es un problema teórico. La inyección SQL está detrás de algunas de las mayores filtraciones de datos de la historia. Es lo que OWASP califica como uno de los ataques más comunes y peligrosos en aplicaciones web.

La prueba irónica: si prohíben tus caracteres, probablemente no pueden manejarlos

Aquí está la paradoja a la que apuntaba el jefe. Cuando un sitio web te dice «las contraseñas no pueden contener caracteres especiales», te está revelando involuntariamente algo importante sobre su seguridad.

Una aplicación bien construida nunca le importa qué caracteres tiene tu contraseña. La contraseña se hashea antes de tocar una base de datos. Una función hash convierte P@$$w0rd';DROP TABLE-- en el mismo tipo de cadena incomprensible de longitud fija que hace con correcthorsebatterystaple. Los caracteres peligrosos desaparecen en el proceso de hasheo. Nunca llegan a la consulta SQL, al comando de shell ni a nada más.

Si un sitio prohíbe los caracteres especiales, una de dos cosas es cierta: o los desarrolladores son excesivamente cautelosos ante un problema que podrían resolver correctamente, o (más preocupante) están pasando tu contraseña por sistemas que se atragantan con esos caracteres. El segundo escenario implica que tu contraseña podría estar llegando a una consulta de base de datos, un script de shell o un sistema heredado sin la limpieza adecuada.

El investigador de seguridad Daniel Miessler mantiene desde 2007 una lista de la vergüenza de sitios web que rechazan los caracteres especiales. La lista original incluía grandes bancos como Chase, Wells Fargo y Suntrust. El desarrollador Scott Hanselman se encontró con un servicio financiero que le indicaba «Password should not contain any special characters, symbols or spaces» («La contraseña no debe contener caracteres especiales, símbolos ni espacios») y señaló el absurdo: un sitio que maneja tu dinero desalienta activamente las contraseñas fuertes.

Lo que el NIST dice ahora

El Instituto Nacional de Estándares y Tecnología de Estados Unidos actualizó sus directrices sobre contraseñas en SP 800-63B-4, publicado como versión final en 2025. Los cambios son significativos. El NIST ahora exige que los sistemas acepten todos los caracteres ASCII y Unicode en las contraseñas, permitan hasta 64 caracteres y exijan una longitud mínima de 15 caracteres. Las reglas de complejidad obligatoria fueron eliminadas explícitamente: nada de mayúsculas forzadas, nada de caracteres especiales requeridos, nada de cambios periódicos.

El razonamiento es sencillo. Las reglas de complejidad obligatorias llevaban a la gente a crear contraseñas como P@ssw0rd1!, que parece compleja a un verificador de políticas pero es trivial para una herramienta de descifrado. La longitud y la aleatoriedad son lo que realmente resiste los ataques de fuerza bruta.

Pero aquí está lo que el NIST entendió bien y que la mayoría pasa por alto: el estándar dice aceptar todos los caracteres. No dice exigirlos. La clave es que nada en tu contraseña debería hacer colapsar el sistema. Si lo hace, el sistema está roto.

La verdadera amenaza no es adivinar, sino filtrar

El mayor peligro para las contraseñas en 2026 no es que alguien adivine la tuya. Es que la empresa que la almacena la filtre. En 2019, Facebook admitió que entre 200 y 600 millones de contraseñas de usuarios habían sido almacenadas en texto plano, consultables por más de 20.000 empleados, con archivos que se remontaban a 2012. Sin hashear. Sin cifrar. En texto plano.

Facebook no fue el único caso. Un análisis de F5 Labs de 2021 reveló que el almacenamiento en texto plano fue responsable de la mayoría de los incidentes de filtración de credenciales en 2020. Muchas organizaciones seguían almacenando contraseñas sin hashearlas en absoluto, o usando algoritmos obsoletos como MD5 sin sal.

Cuando las contraseñas se almacenan en texto plano, la complejidad de tu contraseña es irrelevante. $uP3r_S3cur3!@#% y password123 están igual de expuestas. La única defensa es no tener una cuenta allí.

Lo que debes hacer en la práctica

¿Qué hacer entonces?

• Usa un gestor de contraseñas. Deja que genere contraseñas largas y aleatorias. 20 o más caracteres, cualquier carácter que el sitio permita.
• Prueba la tolerancia del sitio. Si un formulario de registro rechaza ', " o ; en tu contraseña, eso es una señal. Puede ser un diseño excesivamente cauteloso, o una señal de alerta sobre la arquitectura de seguridad del sitio.
• No trates la señal como prueba. Rechazar caracteres especiales es sospechoso, pero aceptarlos tampoco garantiza buena seguridad. Muchos sitios aceptan cualquier cosa y aun así almacenan contraseñas en texto plano.
• Usa la autenticación de dos factores en todas partes donde esté disponible. Una contraseña filtrada importa mucho menos cuando el atacante también necesita tu teléfono.
• No reutilices contraseñas. Si un sitio filtra tus credenciales, todos los demás sitios que comparten esa contraseña quedan comprometidos.

La verdad incómoda es que la seguridad de las contraseñas en gran parte no depende de ti. Puedes hacer todo bien y aun así quedar expuesto por una empresa que almacena tu contraseña en una hoja de cálculo. La mejor defensa es minimizar cuánto confías en un solo servicio con tu vida digital.

La pregunta funciona también como heurística de prueba de penetración: ¿qué ocurre cuando tu contraseña es en sí misma una carga útil de inyección? La respuesta revela más sobre la postura de seguridad de un sitio que cualquier política de privacidad.

La sabiduría convencional sobre los caracteres de inyección en contraseñas y la fortaleza de contraseñas se centra en la entropía: contraseñas más largas con conjuntos de caracteres más amplios resisten mejor los ataques de fuerza bruta. Eso es cierto pero incompleto. La tabla de contraseñas Hive Systems 2025 mide los tiempos de descifrado usando 12 GPU RTX 5090 contra bcrypt (factor de trabajo 10). Una contraseña de 8 caracteres solo con números cae en segundos. Una de 8 caracteres mezclando todos los tipos dura meses. Una contraseña aleatoria de 16 caracteres con ASCII completo requiere tiempo geológico. La longitud gana.

Pero la entropía solo es una defensa contra un vector de ataque específico: el descifrado offline por fuerza bruta de hashes robados. No dice nada sobre lo que ocurre cuando la propia contraseña se interpreta como sintaxis ejecutable.

Caracteres de inyección en contraseñas: la mecánica

Consideremos la consulta de inicio de sesión vulnerable clásica:

SELECT * FROM users WHERE username = '$user' AND password = '$pass'

Si $pass se concatena en esta cadena sin consultas parametrizadasTécnica de consulta donde los datos del usuario se tratan por separado de la estructura SQL, evitando ataques de inyección. ni escape adecuado, una contraseña como ' OR '1'='1 colapsa la lógica de autenticación. PortSwigger documenta la técnica específica: enviar administrator'-- como nombre de usuario con una contraseña en blanco reescribe la consulta a SELECT * FROM users WHERE username = 'administrator'--' AND password = '', comentando por completo la verificación de contraseña.

La inyección SQLAtaque en el que código SQL malicioso se inserta en un campo de entrada para manipular o eludir consultas de base de datos. es la variante más conocida, pero los campos de contraseña también pueden ser vectores para:

• Inyección de comandos del sistema operativo. Si un script de backend pasa la contraseña a un comando de shell (común en sistemas de autenticación heredados, wrappers LDAP o scripts personalizados), caracteres como ;, |, $(...) y las comillas invertidas se convierten en vectores de inyección de comandos. Una contraseña con ; rm -rf / podría, en una implementación desastrosa, ejecutarse en el servidor.
• Inyección LDAP. Caracteres como *, (, ) y tienen significado especial en las consultas LDAP. Una entrada de contraseña no desinfectada en una operación de enlace LDAP puede alterar la lógica de la consulta.
• Inyección XPath. Si la autenticación accede a un almacén de datos XML, ' y " pueden romper expresiones XPath de la misma manera que rompen SQL.

El denominador común: la contraseña se trata como parte de una estructura de control en lugar de como datos opacos. La defensa correcta se conoce desde hace décadas: consultas parametrizadas para SQL, escape adecuado para comandos de shell, y la recomendación de OWASP de nunca construir comandos a partir de entradas de usuario concatenadas.

La heurística del rechazo de caracteres

Cuando un sitio rechaza caracteres especiales en las contraseñas, revela una de tres cosas:

1. Defensa en profundidadEstrategia de ciberseguridad con múltiples capas de protección independientes, de modo que el fallo de una capa no comprometa todo el sistema. mal aplicada. Los desarrolladores conocen la inyección pero eligieron la restricción de entrada sobre la desinfección adecuada. Este es el mejor caso y sigue siendo una violación de las directrices de OWASP sobre contraseñas, que listan 33 caracteres especiales que deberían aceptarse.
2. Las contraseñas pasan por rutas de código no desinfectadas. Los caracteres se rechazan porque provocan errores o comportamiento inesperado más adelante: en SQL, en scripts de shell, en middleware heredado. Esto significa que la contraseña atraviesa esos sistemas en una forma que podría interpretarse como código.
3. Las contraseñas se almacenan o comparan en texto plano. Si la contraseña se hasheara antes de cualquier procesamiento, los caracteres especiales serían irrelevantes. Un hash bcrypt de '; DROP TABLE users;-- es una cadena inofensiva de 60 caracteres. Las restricciones de caracteres sugieren que la contraseña en bruto persiste más lejos en la cadena de procesamiento de lo que debería.

La «lista de la vergüenza» de Daniel Miessler (2007) nombraba a Chase, Wells Fargo y American Express entre los bancos que rechazaban caracteres especiales. Scott Hanselman señaló un servicio financiero que instruía a los usuarios «Password should not contain any special characters, symbols or spaces» («La contraseña no debe contener caracteres especiales, símbolos ni espacios»). Un comentarista en esa publicación señaló que Verizon en algún momento exigía caracteres especiales en el registro pero los rechazaba al iniciar sesión, un comportamiento coherente con un sistema donde dos rutas de código diferentes manejan la misma contraseña de forma distinta.

NIST SP 800-63B-4: el estándar ahora está de acuerdo

NIST SP 800-63B-4 (finalizado en agosto de 2025) codifica lo que los profesionales de la seguridad han argumentado durante años. Los requisitos clave para la autenticación basada en contraseña:

• Los verificadores DEBEN aceptar todos los caracteres ASCII imprimibles, el carácter espacio y los caracteres Unicode.
• Longitud mínima de contraseña: 15 caracteres (cuando la contraseña es el único autenticador).
• Longitud máxima: al menos 64 caracteres.
• Sin reglas de composición (sin mayúsculas, números o caracteres especiales obligatorios).
• Sin rotación periódica de contraseñas a menos que haya evidencia de compromiso.

El borrador de septiembre de 2024 que precedió a la versión final declaraba explícitamente: «Humans have a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed.» («Los humanos tienen una capacidad limitada para memorizar secretos complejos y arbitrarios, por lo que a menudo eligen contraseñas fáciles de adivinar.») El cambio va de exigir complejidad (que produce P@ssw0rd1!) a exigir longitud y aceptación de caracteres (lo que permite correct horse battery staple y sus 44 bits de entropía).

El problema del almacenamiento eclipsa el problema de adivinar

El descifrado offline es una amenaza seria, pero requiere una base de datos de hashes robada. El fallo más común es mucho más simple: contraseñas almacenadas en forma recuperable.

En marzo de 2019, Brian Krebs informó que Facebook almacenaba entre 200 y 600 millones de contraseñas en texto plano, consultables por más de 20.000 empleados. Los registros de acceso mostraban aproximadamente 9 millones de consultas internas que accedían a datos con contraseñas en texto plano. Los archivos se remontaban a 2012.

Facebook no fue un caso aislado. El informe de F5 Labs de 2021 sobre credential stuffingUn ciberataque en el que herramientas automatizadas prueban listas masivas de nombres de usuario y contraseñas robados en múltiples sitios web, aprovechando que muchos usuarios reutilizan las mismas credenciales., resumido por Securden, encontró que el almacenamiento en texto plano representó la mayoría de los incidentes de filtración de credenciales en 2020. Las organizaciones continuaban usando hashing débil (MD5, SHA-1 sin sal) o ningún hashing en absoluto. Frente a los criterios de referencia de Hive Systems, una contraseña hasheada con MD5 cae órdenes de magnitud más rápido que una hasheada con bcrypt de idéntica longitud y complejidad.

Cuando las contraseñas se almacenan en texto plano o con hash débil, la entropía de tu contraseña es irrelevante. Todas las contraseñas quedan igualmente comprometidas. La única defensa es el aislamiento de credenciales: contraseñas únicas por servicio, gestionadas por un gestor de contraseñas, con la autenticación de dos factores como red de seguridad.

El diagnóstico

La observación original se sostiene como heurística práctica:

• Intenta registrarte con caracteres especiales en tu contraseña. Caracteres como ', ", ;, --, $ y | son el conjunto mínimo de prueba. Si el sitio los rechaza, o es demasiado cauteloso o es genuinamente vulnerable.
• La aceptación es necesaria pero no suficiente. Un sitio puede aceptar ' en una contraseña y aun así almacenarla en texto plano. La prueba descarta a los peores infractores; no certifica al resto.
• Si un sitio no puede manejar la puntuación estándar en un campo de contraseña, pregúntate qué más no puede manejar. La entrada de contraseña es la entrada de usuario más sencilla que procesa una aplicación web. Si lo hacen mal aquí, la superficie de ataqueEl conjunto de puntos en un sistema donde un atacante puede intentar entrar, extraer datos o causar daño. probablemente es más amplia que solo el formulario de inicio de sesión.

La lógica subyacente es sólida: si los desarrolladores fueron demasiado perezosos para parametrizar correctamente un campo de contraseña, hay pocas razones para confiar en que lo hashearon, le añadieron sal o aseguraron la base de datos donde vive. La contraseña más fuerte no es solo larga y aleatoria. Es aquella que haría colapsar un sistema mal construido. Y si hace colapsar el sistema, tienes tu respuesta: no crees una cuenta allí.