¿Qué longitud debe tener la contraseña en mi formulario de registro?

Nuestra recomendación, de entrada. Creamos Proxy Mail QA, así que no somos neutrales, pero no elige tu política de contraseñas. Las cifras de abajo vienen de las directrices de identidad digital de NIST (SP 800-63B, cuarta revisión), que siguen muchos equipos de seguridad. Recomendamos Proxy Mail QA para el paso siguiente a tu decisión: comprobar que tu formulario y tu servidor realmente hacen lo que decidiste, con contraseñas de prueba exactamente en el mínimo y el máximo, una a cada lado, y todo tipo de símbolos. No revisa cómo almacenas las contraseñas ni tu seguridad en general.

La respuesta corta

• Al menos 15 caracteres si la contraseña es lo único que alguien necesita para iniciar sesión.
• Al menos 8 caracteres si cada cuenta también tiene un segundo factor, como un código de una app de autenticación.
• Permite al menos 64 caracteres. Más largo está bien; no hace falta un límite de miles.
• Nada de reglas que exijan una mayúscula, un número y un símbolo. La longitud importa más, y esas reglas hacen que la gente elija Password1!.
• Rechaza contraseñas comunes y filtradas, comparando las nuevas con una lista.

El resto de la guía, en palabras simples

La guía de NIST para contraseñas elegidas por los usuarios también dice:

• Acepta cualquier carácter: letras, dígitos, símbolos, espacios y caracteres de otros idiomas. Normaliza Unicode (a NFC) antes de aplicar el hash, para que é escrito de dos formas distintas sea la misma contraseña.
• Cuenta caracteres, no bytes, al comprobar la longitud.
• No recortes las contraseñas. Comprueba la contraseña completa, nunca solo el principio.
• No obligues a cambiar las contraseñas periódicamente. Pide un cambio solo cuando haya indicios de que la contraseña quedó expuesta.
• Nada de pistas de contraseña ni preguntas de seguridad.
• Permite pegar y usar gestores de contraseñas, para que la gente pueda usar contraseñas largas y aleatorias sin escribirlas.
• Muestra lo que se escribió cuando se pida, para que la gente pueda revisar una contraseña larga antes de enviarla.

¿Para qué tener un máximo?

Una contraseña muy larga le cuesta tiempo a tu servidor al aplicar el hash, así que un máximo impide que alguien envíe megabytes como contraseña. Ponlo muy por encima de lo que la gente usa: 64 es lo mínimo que NIST recomienda permitir, y 128 o 256 es habitual.

Ten cuidado con tu algoritmo de hash. bcrypt solo lee los primeros 72 bytes de una contraseña e ignora el resto. Entonces dos contraseñas largas que empiezan igual inician sesión una como la otra. Un carácter puede ocupar más de un byte (é ocupa dos, un emoji cuatro), así que 72 bytes pueden ser menos de 72 caracteres. Puedes:

• usar Argon2id (o scrypt), que no tiene ese límite, o
• mantener el máximo en una longitud que quepa en 72 bytes, o
• si tienes que mantener bcrypt con contraseñas más largas, aplicar primero un hash a la contraseña de una forma que apruebe tu equipo de seguridad.

Pon las reglas donde el navegador pueda verlas

<label for="password">Password</label>
<p id="password-rules">At least 15 characters. Any letters, numbers, symbols or spaces.</p>
<input id="password" name="password" type="password" autocomplete="new-password" minlength="15" maxlength="128" aria-describedby="password-rules" required />

• minlength y maxlength permiten que el navegador avise antes, y que los gestores de contraseñas creen contraseñas que cumplan. maxlength además recorta el texto pegado sin avisar, así que ponlo muy por encima de lo que crearía un gestor de contraseñas.
• autocomplete="new-password" indica a los gestores de contraseñas que ofrezcan una contraseña nueva y segura.
• Muestra las reglas antes de que alguien escriba, no solo después de que se equivoque.
• Aplica las mismas reglas en el servidor. Las comprobaciones del navegador son una comodidad; cualquiera puede saltárselas.
• Si usas un servicio de autenticación (Supabase Auth, Clerk, Firebase Authentication, Auth0 y otros), configura también el mínimo en sus ajustes. Muchos usan por defecto uno mucho más corto, y una página que dice 15 mientras el servicio acepta 6 es un error común.

Comprueba que tu formulario hace lo que decidiste

get_password_variants (MCP), qa.passwordVariants() (npm) o GET /v1/variants/passwords (REST API) toman tus reglas (min_length, max_length y si se permiten symbols) y devuelven contraseñas de prueba nuevas en tres grupos:

El par de 72 bytes es el que hay que vigilar: si la segunda contraseña inicia sesión en la cuenta creada con la primera, tu app está recortando las contraseñas.

Puedes ejecutarlas a mano, desde un agente o en una prueba:

• A mano: con Proxy Mail QA for Chrome, la tarjeta del campo de contraseña ofrece Edge-case password, con listas marcadas como “Should be accepted” y “Should be rejected”, adaptadas a los minlength y maxlength del propio campo. Sus contraseñas habituales también cumplen esas reglas.
• Desde un agente: con Proxy Mail QA conectado en Qoder (Marketplace):

Our password policy is 15 to 128 characters, any characters allowed. Using Proxy Mail QA,
get_password_variants with min_length 15 and max_length 128, and try each one on
https://staging.acme.dev/signup with a new test address (use a plus tag for each).
For accepted ones, verify the account and sign in with the same password.
Give me a table: what it tests, accepted or refused, the message shown, and whether
signing in worked.

• En una prueba: await qa.passwordVariants({ minLength: 15, maxLength: 128 }) devuelve accept, reject y decide, cada uno una lista de { tests, value } para recorrer en Playwright o Cypress.

Si las contraseñas rechazadas no muestran ningún error, consulta ¿Por qué mi formulario de registro no muestra errores de contraseña?

Lo que Proxy Mail QA no hace aquí

• Elegir tu política, ni decirte si cumple una ley o un estándar que debas seguir.
• Revisar cómo se almacenan las contraseñas ni probar el resto de tu seguridad. Para eso está una revisión de seguridad o una prueba de penetración.
• Probar una lista de bloqueo de contraseñas filtradas: prueba tú mismo algunas muy conocidas, como password1234567.

Fuentes: NIST SP 800-63B-4 y su sección sobre autenticadores.