Por qué maxlength=20 en un input de password rompe logins

El bug que dejó a un usuario fuera de su cuenta en Vanguard durante un año

Un usuario con contraseña generada por 1Password (más larga de 20 caracteres) no podía entrar a su cuenta de Vanguard desde la web. Tras resetear la contraseña hasta tres veces y asumir que era un fallo del sitio, descubrió el verdadero motivo: el formulario de reset tiene un <input type="password"> con maxlength="20", mientras que el formulario de login no lo aplica.

El resultado fue devastador para la experiencia: en el reset, el navegador truncaba su contraseña a 20 caracteres sin avisar; al intentar hacer login, la contraseña completa se enviaba correctamente, y el sistema la rechazaba. La fuente original del caso es el blog técnico de Tanin Nanakorn.

Qué hace `maxlength` en un campo de password y por qué es un anti-patrón

El atributo HTML maxlength limita la cantidad de caracteres que el usuario puede escribir o pegar en un input. Según la documentación de MDN, las restricciones de longitud «no se reportan nunca si el valor se asigna mediante programación; solo se reportan para la entrada proporcionada por el usuario».

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En la práctica, esto significa tres problemas serios:

Truncado silencioso al pegar: si pegas una contraseña de 30 caracteres en un campo con maxlength="20", solo se guardan los primeros 20 sin ningún feedback visual.
Validación frontend y backend inconsistentes: si el backend acepta contraseñas largas pero el frontend las trunca, el usuario resettea una contraseña que nunca va a coincidir al hacer login.
Fricción con gestores de contraseñas: 1Password, Bitwarden, LastPass y similares suelen generar credenciales de 32+ caracteres por defecto. Un maxlength agresivo rompe ese flujo.

La guía de DhiWise sobre campos de password en HTML reconoce que maxlength y minlength son útiles para hacer cumplir políticas, pero advierte que deben usarse con cuidado para no degradar la experiencia.

Qué significa esto para tu startup

Si estás construyendo cualquier producto con autenticación (SaaS B2B, fintech, marketplace, app con login), este caso de Vanguard es un recordatorio de que los detalles de frontend tienen impacto directo en retención y soporte.

Un usuario que no puede entrar a su cuenta no va a debuggear tu HTML: va a asumir que tu producto está roto y va a buscar alternativa. En el caso de Vanguard, el usuario aguantó un año antes de investigar. En una startup etapa temprana, no tienes ese lujo.

Acción concreta 1: audita tus inputs de password esta semana

Abre DevTools, ve a cualquier formulario de registro, reset o cambio de contraseña en tu producto, y busca atributos maxlength en los <input type="password">. Si existen, evalúa:

¿El backend realmente rechaza contraseñas más largas, o solo lo copiaste de un tutorial?
¿Tu política de longitud coincide entre frontend y backend?
¿Probaste el flujo completo con un password de 32+ caracteres generado por un gestor?

Acción concreta 2: usa validación en el backend, no truncado en el frontend

MDN lo dice explícitamente: la validación en el cliente «no debe considerarse una medida de seguridad exhaustiva». La regla de oro es:

Frontend: permite pegar la contraseña completa, muestra feedback visual si excede el límite, pero no la recortes.
Backend: valida la longitud real, hashea con bcrypt o argon2, y rechaza con un mensaje claro si excede el máximo permitido.
UX: si necesitas un máximo, comunícalo antes de que el usuario pierda tiempo (placeholder, texto de ayuda, contador de caracteres visible).

Lecciones de UX y seguridad para founders técnicos

Más allá del bug específico, este caso ilustra tres principios que aplican a cualquier producto digital:

La consistencia entre flujos es innegociable: si el reset trunca y el login no, tienes un bug esperando a explotar. Documenta y testea cada flujo de autenticación de extremo a extremo.
Los gestores de contraseñas son la norma, no la excepción: según datos del sector, más del 30% de usuarios de internet usan algún gestor. Tu producto debe funcionar con contraseñas generadas de 30+ caracteres sin fricción.
El truncado silencioso es peor que el rechazo explícito: es preferible mostrar un error claro («máximo 20 caracteres») que cortar la entrada sin avisar y dejar al usuario en un limbo de «resetié pero no puedo entrar».

Si tu stack es JavaScript, el patrón recomendado es usar la Constraint Validation API de MDN con setCustomValidity() para dar mensajes contextuales en lugar de depender solo de atributos HTML estáticos. Esto te da control total sobre la experiencia de error.