Una política de contraseñas debe dificultar el acceso no autorizado a las cuentas sin hacer que el comportamiento seguro sea innecesariamente complicado. Las mejores políticas son claras, prácticas y están alineadas con la forma en que las personas realmente trabajan. Fomentan contraseñas largas y únicas, apoyan el uso de gestores de contraseñas, requieren autenticación multifactor donde corresponde y eliminan reglas obsoletas que empujan a los usuarios hacia comportamientos predecibles.
\nEste artículo explica qué hacer y qué evitar en una política de contraseñas moderna, cuáles son las mejores prácticas y proporciona una plantilla editable que puedes adaptar para tu organización.
\nUna política de contraseñas es un conjunto de reglas que define cómo se crean, almacenan, usan, comparten, cambian y protegen las contraseñas. Se aplica a empleados, contratistas, administradores, cuentas de servicio y, a veces, a clientes, según los sistemas involucrados.
\nUna buena política de contraseñas debe responder a preguntas prácticas:
\nEl objetivo no es crear el conjunto de reglas más complicado. El objetivo es reducir el riesgo real.
\nLa longitud es uno de los factores más efectivos contra ataques de adivinación y fuerza bruta. Un mínimo universal para toda la organización es, por lo general, más fácil de comprender y de aplicar para los equipos de TI que reglas separadas para usuarios estándar, administradores y casos especiales. Un valor práctico de partida es requerir al menos 16 caracteres para todas las cuentas de usuarios humanos. Más largo es mejor si los usuarios recurren a gestores de contraseñas o frases de contraseña generadas aleatoriamente.
\nLos usuarios deben poder crear contraseñas mucho más largas que el mínimo requerido. Evita límites máximos bajos como 16 o 20 caracteres. Un máximo de al menos 64 caracteres es un punto de partida razonable, y muchos sistemas pueden soportar más.
\nDebe permitirse el uso de frases de contraseña, siempre que sean largas y no estén basadas en citas comunes, letras de canciones, nombres de empresa o frases predecibles. Por ejemplo, una frase construida con varias palabras aleatorias normalmente es mejor que una contraseña corta con sustituciones forzadas.
\nCada cuenta debe tener una contraseña única. Reutilizar contraseñas es una de las principales causas por las que una brecha en un servicio se convierte en toma de control de cuentas en otro. Un gestor de contraseñas hace que el uso de contraseñas únicas sea práctico, ya que los usuarios no tienen que memorizar todas las credenciales.
\nTu política debe permitir y promover expresamente los gestores de contraseñas aprobados. Se debe permitir a los usuarios pegar contraseñas en los formularios de inicio de sesión, usar autocompletado y generar contraseñas aleatorias. Bloquear el pegado puede parecer protector, pero a menudo desincentiva un uso sólido de gestores de contraseñas.
\nLas contraseñas deben ser rechazadas si aparecen en listas de brechas conocidas, listas de contraseñas comúnmente utilizadas o listas de denegación específicas de la organización. Esto es más útil que obligar a incluir una mayúscula, un número y un símbolo.
\nLa autenticación multifactor debe estar habilitada donde sea técnicamente viable, especialmente para administradores, acceso remoto, servicios en la nube, correo electrónico, gestores de contraseñas, sistemas financieros y otros sistemas de alto valor. La MFA no reemplaza contraseñas sólidas, pero reduce el impacto de credenciales robadas.
\nPrefiere MFA resistente a phishing, como passkeys, llaves de seguridad hardware o autenticadores de la plataforma. Las aplicaciones autenticadoras suelen ser mejor opción que los SMS. La MFA por SMS no debe usarse si hay disponible cualquier otro método alternativo, ya que los números de teléfono pueden ser interceptados, clonados (SIM-swapping), transferidos o abusados en procesos de recuperación de cuenta.
\nEsto no es teórico. En 2018, Reddit comunicó que atacantes interceptaron la autenticación de dos factores basada en SMS y accedieron a sistemas internos: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. En 2021, Coinbase informó que atacantes robaron criptomonedas de al menos 6.000 clientes tras abusar de credenciales y debilidades en el proceso de recuperación por SMS de Coinbase: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nLas contraseñas deben cambiarse cuando exista evidencia o sospecha razonable de compromiso. Ejemplos: phishing, malware en el dispositivo del usuario, exposición de credenciales en una brecha, actividad de inicio de sesión sospechosa o divulgación accidental.
\nSe deben evitar las contraseñas compartidas cuando sea posible disponer de cuentas individuales. Si el uso de credenciales compartidas es inevitable, deben almacenarse en un gestor de contraseñas aprobado, limitar el acceso solo a usuarios autorizados y registrar los eventos de uso compartido en la medida de lo posible.
\nEl restablecimiento suele ser el punto más débil en la seguridad de las cuentas. Los flujos de restablecimiento deben verificar la identidad, expirar rápidamente los enlaces de restablecimiento, usar tokens de un solo uso y notificar a los usuarios cuando su contraseña haya sido cambiada.
\nCambios obligatorios de contraseña cada 30, 60 o 90 días suelen llevar a contraseñas más débiles. Los usuarios tienden a hacer cambios pequeños y predecibles, como añadir un número o modificar la estación del año. Las guías de Identidad Digital de NIST eliminaron los cambios rutinarios y solo exigen cambio tras una sospecha de compromiso. Consulta la sección 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Exige cambios solo tras sospecha, cambios de rol, recuperación de cuenta o cuando la contraseña ya no cumple la política.
\nReglas como \"debe incluir mayúscula, minúscula, número y símbolo\" no garantizan fortaleza. Password1! cumple muchas reglas de complejidad pero sigue siendo débil. Da prioridad a la longitud, unicidad, aleatoriedad y comprobación contra brechas.
Bloquear el pegado dificulta el uso de gestores de contraseñas. Puede llevar a los usuarios a crear contraseñas más cortas y fáciles de tipear. Permite pegar y autocompletar, salvo motivo de seguridad específico y documentado para no hacerlo.
\nLas pistas suelen revelar demasiada información. Si un usuario recuerda la respuesta, un atacante podría adivinarla también. Usa procesos de restablecimiento seguros en su lugar.
\nLos sistemas jamás deben almacenar contraseñas en texto plano ni en cifrado reversible. Se deben usar algoritmos modernos de hash lento y con salt (sal), como Argon2id, bcrypt, scrypt o PBKDF2, dependiendo de las capacidades del sistema y los requisitos regulatorios.
\nAlgoritmos de hash rápidos como MD5, SHA-1, SHA-256 o SHA-512 no son apropiados para contraseñas por sí solos. Están diseñados para ser rápidos, lo que facilita ataques de fuerza bruta si hay una filtración de base de datos. Para más información, revisa nuestro artículo sobre la evolución del hashing de contraseñas.
\nNo se deben enviar contraseñas por email, chat, tickets, documentos ni capturas de pantalla. Usa un gestor de contraseñas con funciones seguras de compartición y control de acceso.
\nLas contraseñas no deben contener nombres, fechas de nacimiento, nombres de empresa, patrones de teclado, caracteres repetidos o sustituciones comunes como @ por a y 0 por o. Los atacantes prueban estos patrones primero.
Utiliza requisitos fáciles de entender:
\nLas cuentas de administrador, cuentas de servicio y acceso a producción requieren controles más estrictos. Exige contraseñas más fuertes, MFA, acceso limitado, monitoreo y reemplazo inmediato al cambiar el acceso.
\nContraseñas fuertes no compensan permisos excesivos. Los usuarios solo deben acceder a sistemas y secretos necesarios para su función.
\nDetecta patrones inusuales de inicio de sesión, viajes imposibles, intentos repetidos fallidos, acceso desde países nuevos y actividad fuera del horario habitual. La política de contraseñas debe estar respaldada con monitoreo y respuesta ante incidentes.
\nLas formaciones deben centrarse en el problema de reutilización, phishing, páginas de inicio falsas, fatiga de MFA, compartición segura y cómo reportar compromisos sospechosos. No culpes a los usuarios; haz que el comportamiento seguro sea sencillo.
\nUna política debe ser comprensible. Si es muy larga, vaga o estricta, la gente la esquivará. La mejor política es la que realmente puede aplicarse y seguirse.
\nUtiliza la siguiente plantilla como punto de partida. Ajusta las secciones entre corchetes según la organización, tipo de sistemas, nivel de riesgo y requisitos legales.
\nPolítica de Contraseñas\n\nVersión: [1.0]\nResponsable: [Departamento de Seguridad / TI]\nFecha de entrada en vigor: [AAAA-MM-DD]\nCiclo de revisión: [Cada 12 meses]\n\n1. Propósito\n\nEsta política define los requisitos para crear, usar, almacenar, compartir y cambiar contraseñas en [Nombre de la Organización]. El propósito es reducir el riesgo de acceso no autorizado, robo de credenciales, toma de control de cuentas y pérdida de datos.\n\n2. Alcance\n\nEsta política aplica a todos los empleados, contratistas, personal temporal, proveedores de servicios y cualquier otro usuario que acceda a sistemas, aplicaciones, redes, servicios en la nube o datos de [Nombre de la Organización].\n\nEsta política aplica a cuentas de usuario estándar, cuentas privilegiadas, cuentas de servicio, cuentas compartidas y cualquier sistema donde se usen contraseñas para autenticación.\n\n3. Requisitos para la creación de contraseñas\n\nTodas las contraseñas deben cumplir los siguientes requisitos:\n\n- Las cuentas de usuarios humanos deben usar contraseñas de al menos 16 caracteres.\n- Las contraseñas deben ser únicas y no deben reutilizarse entre cuentas de trabajo o personales.\n- No deben contener nombres, usuarios, nombres de empresa, fechas de nacimiento, patrones de teclado, caracteres repetidos u otra información fácil de adivinar.\n- No deben basarse en frases comunes, citas, letras de canciones o sustituciones predecibles.\n- No deben aparecer en listas conocidas de contraseñas comprometidas o comunes.\n- Se pueden incluir espacios, símbolos, números, letras mayúsculas y minúsculas.\n- Se permiten frases de contraseña si son largas, únicas y no basadas en frases públicas o predecibles.\n\n4. Gestores de contraseñas\n\n[Nombre de la Organización] exige o recomienda expresamente el uso de un gestor de contraseñas aprobado para crear, almacenar y compartir contraseñas.\n\nLos usuarios pueden utilizar el generador de contraseñas, autocompletado y función de copiar-pegar del gestor aprobado. No se deben almacenar contraseñas en navegadores, hojas de cálculo, documentos, aplicaciones de notas, emails, mensajes de chat, capturas de pantalla ni herramientas no aprobadas.\n\n5. Autenticación multifactor (MFA)\n\nLa MFA debe estar habilitada donde sea técnicamente posible, incluyendo pero no limitado a:\n\n- Cuentas de correo electrónico\n- Sistemas de acceso remoto\n- Cuentas de gestores de contraseñas\n- Servicios en la nube\n- Cuentas administrativas\n- Sistemas financieros, de RRHH y de alto riesgo\n- Cualquier sistema clasificado como [confidencial / crítico]\n\nCuando sea posible, los usuarios deben usar MFA resistente a phishing como passkeys, llaves hardware de seguridad o autenticadores de la plataforma. Se prefieren apps autenticadoras antes que SMS. Está prohibido el uso de MFA por SMS si existe cualquier otro método y solo puede usarse cuando no hay otra opción técnica más segura.\n\n6. Cambio de contraseñas\n\nLas contraseñas deben cambiarse inmediatamente cuando:\n\n- Se sepa o sospeche que la contraseña ha sido comprometida.\n- El usuario introdujo su contraseña en un sitio sospechoso de phishing.\n- La contraseña fue compartida con una persona no autorizada.\n- Se detecta malware o acceso no autorizado en el dispositivo del usuario.\n- La contraseña aparece en una brecha de datos conocida.\n- Cambios de rol o situación laboral del usuario privilegiado.\n- El departamento de TI o Seguridad lo requiera.\n\nNo es obligatorio el cambio periódico salvo que lo exija la ley, normativa, contrato o limitación técnica. No se deben cambiar las contraseñas haciendo modificaciones predecibles sobre la anterior.\n\n7. Compartición de contraseñas\n\nNo se debe compartir contraseñas por email, chat, tickets, documentos, capturas de pantalla, llamadas telefónicas ni comunicación verbal.\n\nSolo se permiten credenciales compartidas cuando no es técnicamente posible tener cuentas individuales o cuando lo aprueba expresamente [Seguridad / TI]. Dichas credenciales deben almacenarse y compartirse mediante el gestor de contraseñas aprobado y el acceso debe limitarse a usuarios autorizados.\n\n8. Cuentas privilegiadas\n\nLas cuentas privilegiadas deben usar contraseñas únicas que no se usen en ninguna cuenta estándar. Deben tener MFA habilitado donde sea técnicamente viable y ser revisadas regularmente.\n\nLas contraseñas privilegiadas deben rotarse cuando un administrador deja la organización, cambia de rol, ya no necesita acceso o se sospeche compromiso.\n\n9. Cuentas de servicio y secretos de aplicación\n\nLas contraseñas de cuentas de servicio, API keys, tokens y secretos de aplicación deben almacenarse en un sistema aprobado de gestión de secretos o gestor de contraseñas aprobado.\n\nLas credenciales de servicio no deben embeberse en código fuente, archivos de configuración, imágenes, documentación o scripts salvo que estén protegidas mediante un proceso de gestión de secretos aprobado.\n\n10. Restablecimiento de contraseñas y recuperación de cuentas\n\nEl proceso de restablecimiento debe verificar la identidad antes de restaurar el acceso. Los enlaces de restablecimiento y contraseñas temporales deben ser de un solo uso, expirar rápidamente y transmitirse solo mediante canales aprobados.\n\nSe debe notificar a los usuarios cuando su contraseña haya sido cambiada o restablecida. Las contraseñas temporales deben cambiarse en el primer inicio de sesión.\n\n11. Controles técnicos\n\nLos sistemas que almacenen o procesen contraseñas deben:\n\n- No almacenar nunca contraseñas en texto plano.\n- Hashear contraseñas con un algoritmo moderno, lento y con sal: PBKDF2, scrypt, bcrypt o Argon2.\n- No usar MD5, SHA-1, SHA-256, SHA-512 u otros algoritmos rápidos de hash para contraseñas por sí solos.\n- Proteger los endpoints de autenticación mediante rate limiting o mecanismos equivalentes.\n- Rechazar contraseñas débiles, comunes y comprometidas.\n- Permitir a los usuarios pegar contraseñas desde gestores de contraseñas.\n- Soportar longitudes razonables, al menos 64 caracteres si es posible técnicamente.\n- Registrar eventos de autenticación relevantes para la seguridad.\n\n12. Reporte de sospechas de compromiso\n\nLos usuarios deben reportar inmediatamente sospechas de compromiso de contraseña, phishing, mensajes inesperados de login, solicitudes de MFA no iniciadas o divulgación accidental de contraseña a [contacto de Seguridad / TI].\n\n13. Excepciones\n\nCualquier excepción a esta política debe ser documentada, evaluada en términos de riesgo, acotada en el tiempo y aprobada por [liderazgo de Seguridad / TI]. Se deben aplicar controles compensatorios siempre que sea posible.\n\n14. Aplicación\n\nEl incumplimiento de esta política puede dar lugar a la retirada del acceso, obligación de recibir formación en seguridad, medidas disciplinarias u otras acciones de acuerdo a las políticas de [Nombre de la Organización] y la legislación aplicable.\n\n15. Revisión\n\nEsta política debe revisarse al menos una vez al año o tras cambios significativos en los sistemas, las amenazas, requisitos legales o en la operativa del negocio.\nUna política de contraseñas sólida no consiste en hacer la vida difícil. Se trata de eliminar hábitos débiles, apoyar el uso de gestores de contraseñas, emplear MFA y reaccionar rápido cuando se exponen credenciales. Mantén la política práctica, aplicable y centrada en ataques reales como el phishing, credential stuffing, reutilización de contraseñas y cuentas comprometidas.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Política de Contraseñas: Recomendaciones, Errores Comunes, Buenas Prácticas y una Plantilla Editable","description":"Descubre los requisitos que debe tener una política de contraseñas moderna, qué reglas obsoletas evitar y copia una plantilla práctica para tu organización.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"es","langPathPrefix":"/es"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}