Tu política de contraseñas es probablemente un PDF firmado en 2020 que nadie ha vuelto a leer. Y si alguien lo lee, el documento pide cosas que dejaron de tener sentido hace cinco años: rotar cada 90 días, complejidad obligatoria con símbolo y mayúscula, etc. Mientras tanto, alguien del equipo comercial escribe la nueva contraseña en un post-it bajo el teclado y reutiliza la misma combinación para otros servicios.
Eso no es lo peor. Lo peor es que la mayoría de las brechas corporativas no ocurren porque alguien adivine una contraseña débil. Ocurren porque alguien usa una contraseña corporativa que ya está circulando en una combolist desde la filtración de Adobe en 2013, de LinkedIn en 2012, o del último dump genérico que vendió alguien en un foro ruso por 20 dólares. El reporte Verizon DBIR 2024 lo dice claro: el 80% de las brechas web usan credenciales legítimas robadas o filtradas previamente.
Aquí está la verdad incómoda para cualquier IT manager: una política de contraseñas no protege a tu empresa. Lo que protege a tu empresa es saber cuándo esa política se rompió, qué credenciales ya están comprometidas, y qué hacer en los siguientes 60 minutos. En este artículo exploramos tres cosas: una plantilla moderna alineada con NIST 800-63B (revisión 2024), un plan de respuesta cuando una credencial corporativa cae filtrada, y la lógica operativa para conectar política, verificación y respuesta en un solo flujo.
Qué es una política de contraseñas (y por qué la mayoría no sirve)
Una política de contraseñas es el conjunto de reglas que define cómo se crean, almacenan, rotan y revocan las credenciales en una organización. Cubre longitud mínima, requisitos de complejidad, frecuencia de rotación, uso de gestores, autenticación multifactor, almacenamiento permitido y el workflow para cuando algo sale mal. En el papel, suena directo. En la práctica, es donde la teoría de la seguridad choca con la realidad operativa.
El problema es que la mayoría de las políticas se heredan. Las redactó un consultor que ya no trabaja en la empresa, las firmó un CISO que se fue hace tres años y nunca pasaron por una revisión seria. Las reglas siguen ahí porque cumplen un requisito formal de auditoría, no porque alguien las haya validado contra cómo usa el equipo sus credenciales hoy. El resultado es una política que tu auditor lee con calma y tu personal ignora con calma.
Hay un segundo problema más profundo: una política sin enforcement técnico es solo deseo. Si dices "longitud mínima de 12 caracteres" pero no lo configuras en Active Directory, Entra ID, o Google Workspace, no tienes política, tienes un PDF. Si dices "MFA obligatoria para acceso a sistemas críticos" pero no auditas qué cuentas tienen MFA habilitada, no sabes si la regla se cumple o no.
Las reglas que NIST 2024 descartó (y que tu política probablemente todavía exige)
El NIST publicó la última revisión de su guía de identidad digital, 800-63B, en 2024. Cambió el paradigma de seguridad de contraseñas de forma drástica, y la mayoría de las políticas corporativas no se enteraron. Vale la pena revisar qué dejó de ser recomendado:
Rotación periódica forzada cada 90 días: descartada.
Cuando obligas al usuario a cambiar la contraseña cada tres meses, no obtienes contraseñas más fuertes. Obtienes "Empresa2024Q1!", "Empresa2024Q2!", "Empresa2024Q3!". El usuario incrementa un dígito o cambia un símbolo, y mantiene la estructura predecible. NIST hoy recomienda forzar la rotación solo cuando hay evidencia de compromiso: filtración detectada, phishing exitoso, dispositivo extraviado.
Complejidad obligatoria con mayúscula, número y símbolo: descartada.
La complejidad por composición fue diseñada para ataques de fuerza bruta de hace una década. Hoy los atacantes usan diccionarios y combolists, no fuerza bruta pura. Una frase larga ("CaféMartesPajaroBicicleta") es exponencialmente más resistente que "P@ssw0rd2024!" y es más fácil de recordar para el usuario. NIST recomienda priorizar la longitud sobre la composición.
Prohibición de gestores de contraseñas: descartada y revertida.
Algunas políticas viejas prohibían gestores por miedo a "tener todas las contraseñas en un solo lugar". El consenso actual es el opuesto: los gestores de contraseñas reducen drásticamente el riesgo porque permiten al usuario tener una contraseña única y aleatoria por servicio sin esfuerzo cognitivo. Tu política debe exigir el uso de un gestor aprobado, no prohibirlo.
Preguntas de seguridad ("nombre de tu mascota"): descartadas.
La información disponible en redes sociales hace que estas preguntas sean trivialmente recuperables. Reemplázalas por verificación basada en MFA o tokens de respaldo.
Pista visible en login ("hint"): descartada.
Cualquier dato que el sistema muestra antes de autenticar reduce la entropía efectiva de la contraseña.
Las 8 cláusulas obligatorias de una política moderna
Una política funcional cabe en pocas páginas. No necesitas un documento de cuarenta páginas si tienes claras las cláusulas mínimas viables. Estas son las ocho que toda política corporativa moderna debe cubrir:
- Longitud mínima. 12 caracteres como base, 14+ recomendado. Para cuentas privilegiadas (admin, root, service accounts), 16+ caracteres o frase de cinco palabras.
- Diferenciación de cuentas privilegiadas. Un admin de dominio no puede tener las mismas reglas que un usuario de finanzas. Define tier 0 (root, domain admin), tier 1 (acceso a sistemas críticos), y tier 2 (usuarios estándar).
- MFA obligatoria por tipo de acceso. Cuentas privilegiadas: MFA con hardware token. Acceso remoto a sistemas críticos: MFA siempre. Acceso a aplicaciones SaaS corporativas: MFA por defecto.
- Gestores de contraseñas aprobados y prohibidos. Define la lista de gestores autorizados (1Password, Bitwarden, Keeper, etc.) y prohíbe el almacenamiento en navegador para cuentas corporativas.
- Rotación condicionada a evento, no calendario. Forzar reset solo si hay evidencia de compromiso: credencial filtrada en dark web, phishing exitoso, dispositivo extraviado, sospecha de acceso no autorizado en el audit log.
- Almacenamiento prohibido. Lista explícita: contraseñas en post-its, archivos de texto plano, en la pared, compartidos por chat, fotos en el celular.
- Workflow de onboarding y offboarding. Cómo se generan las credenciales iniciales, cómo se entregan al usuario, cómo se revocan al salir, cuántas horas hábiles tiene IT para revocar accesos tras la baja.
- Plan de respuesta a credencial filtrada. Esto es lo que la mayoría de las políticas omiten. Quién detecta, quién recibe la alerta, qué se hace en los siguientes 60 minutos, dónde se registra el evento, cómo se comunica al usuario afectado.
Cada cláusula necesita un control técnico que la respalde. Si la política dice "longitud mínima 12 caracteres" pero la GPO de Active Directory permite 8, la política es ficción. Antes de firmar la nueva política, mapea cada cláusula a la configuración técnica concreta que la enforce: GPO, Entra Conditional Access, Workspace password settings, IdP rules.
Por qué la política sola no funciona: el problema de la verificación
Aquí está el punto donde casi toda la literatura sobre password policy se queda corta. Asumen que si la política está bien redactada y los controles técnicos la hacen cumplir, el problema está resuelto. No lo está. La política puede ser perfecta, los controles pueden estar configurados al milímetro, y aún así tu empresa puede tener decenas de credenciales corporativas comprometidas en este momento sin que nadie lo sepa.
El motivo es simple: el atacante no tiene que adivinar tu contraseña. La compra. Los foros de la dark web venden combolists con cientos de millones de credenciales reciclando dumps de los últimos quince años. Si un empleado tuyo registró su email corporativo en LinkedIn, Adobe, Dropbox, MyFitnessPal, o cualquiera de las decenas de servicios filtrados desde 2012, esa credencial está en circulación. Y si reutilizó la contraseña, el atacante ya tiene acceso, sin tocar tu política.
El cambio mental que tienes que hacer es este: la política regula el comportamiento que puedes controlar. La verificación cubre el riesgo que tú no controlas: el comportamiento del usuario en otros servicios. Las dos capas son complementarias. Una sola no es suficiente.
Cómo detectar credenciales corporativas filtradas en la dark web
Detectar credenciales filtradas no es magia. Es un proceso continuo de comparación entre los emails y dominios de tu organización contra los dumps que aparecen en foros de la dark web, marketplaces, combolists, y volcados públicos. Lo que cambia entre soluciones es la frecuencia, la cobertura, y la calidad de los indicadores de severidad.
Un sistema de monitoreo serio busca tres cosas al mismo tiempo. Primero, dominios completos de tu empresa (@empresa.com, @empresa.cl) escaneados contra todos los dumps disponibles y foros privados. Segundo, emails específicos de cuentas críticas, como ejecutivos, administradores de sistema y service accounts, que aparezcan en cualquier filtración. Tercero, patrones de credenciales corporativas en combolists actuales, no solo dumps históricos.
La frecuencia mínima razonable es semanal. Mensual ya es tarde, porque una credencial filtrada esta semana puede ser usada en ataques automatizados en cuestión de horas. La diferencia entre detectar el lunes y el viernes es la de prevenir un incidente y responder a uno.
La severidad debe estar codificada por categoría. Una credencial de un practicante filtrada hace cinco años no tiene el mismo peso que la credencial de un admin en un dump del mes pasado. Un sistema operativo necesita un scoring que diferencie Critical (cuentas privilegiadas, ejecutivos, service accounts), High (acceso a sistemas críticos, cuentas con MFA débil), y Low (cuentas estándar sin acceso a datos sensibles).
Los patrones a monitorear por defecto son: dominios corporativos completos, todas las direcciones de C-level, cuentas administrativas de cada plataforma SaaS crítica (Microsoft 365, Google Workspace, AWS, Salesforce), y service accounts. Para empresas con presencia internacional, también monitorear dominios alternos y subdominios técnicos.
Plan de respuesta cuando una credencial corporativa aparece filtrada
Detectar es la mitad del trabajo. La otra mitad es saber qué hacer en los siguientes 60 minutos. Una alerta sin un workflow de respuesta es ruido. Lo que necesitas es un runbook claro con responsables y pasos secuenciados.
Hay un escenario que vale la pena tener en mente porque es el que rompe la mayoría de las respuestas improvisadas:
Viernes a las 6 de la tarde, el alert dispara: tres credenciales de C-level aparecen en un dump filtrado el día anterior. Severidad Critical. La mitad del equipo de IT ya se fue. ¿Qué hacés en los siguientes 60 minutos?
El workflow es éste, en orden:
- Forzar reset de las tres credenciales. Desde Entra ID, Active Directory, o tu IdP central. Esto invalida la credencial filtrada inmediatamente, aunque el atacante ya la tenga.
- Validar que MFA está activa y habilitada en las tres cuentas. Si alguna no la tenía, configurarla ahora con hardware token preferiblemente.
- Revisar el audit log de las tres cuentas en las últimas 72 horas. Buscar accesos desde IPs inusuales, geolocalización fuera de patrón, o tokens de sesión emitidos sin autenticación visible.
- Verificar los endpoints asociados a las tres cuentas. Si tu plataforma de gestión de endpoints muestra el último check-in y la geolocalización, confirmar que coincide con la actividad esperada del usuario.
- Aplicar lock remoto preventivo si hay actividad sospechosa en algún endpoint mientras se completa la investigación.
- Comunicar al usuario afectado por otros canales, no por email corporativo. Llamada o SMS al teléfono personal registrado.
- Registrar el evento completo en el audit log con timestamps, acciones tomadas, y responsables. Esto es la evidencia operativa que necesitas para auditoría.
El objetivo del runbook no es velocidad por velocidad, es evidencia operativa. Cuando llegue la auditoría externa preguntando "¿cómo verifican que su política de contraseñas funciona?", la respuesta es el log de respuesta a credenciales filtradas: aquí están las tres detectadas en marzo, aquí está el reset, aquí está el endpoint check, aquí está la comunicación al usuario, todo con timestamp.
Para empresas con protocolos de respuesta a brechas ya documentados, el flujo de credenciales filtradas se conecta directamente: es uno de los disparadores que activa el incident response plan general.
De la política al sistema operativo: cómo Prey cierra el ciclo
Hasta acá tienes una política moderna, un mecanismo de detección, y un plan de respuesta. Lo que falta es la integración operativa: ¿quién corre el monitoreo, dónde se centraliza la evidencia, cómo se conecta la detección de credenciales filtradas con la gestión de los endpoints asociados?
Prey Breach Monitoring cubre la capa de detección con scan semanal automatizado contra dumps y combolists publicos y privados. El reporte que entrega tiene tres elementos que son los que un IT manager necesita: severity scoring por credencial (Critical, High, Low), top de emails comprometidos con detalle de en qué breach aparecieron, y breakdown por categoría de activo expuesto (PII, credenciales, datos financieros). El reporte es descargable como CSV, lo que significa que se integra directo en el audit log y en cualquier dashboard interno de seguridad.
La pieza que conecta política con respuesta es la visibilidad de endpoints. Cuando una credencial cae filtrada y necesitas verificar el dispositivo asociado, las capacidades de tracking y management de Prey te permiten ver el último check-in del endpoint, su ubicación, su nivel de cumplimiento (encryption status, OS update level, MDM enrollment), y aplicar acciones remotas como lock o forced session reset si la situación lo amerita.
Conclusión
Una política de contraseñas no protege a tu empresa. Lo que protege a tu empresa es saber cuándo esa política se rompió, qué credenciales corporativas ya están comprometidas, y tener un plan de respuesta listo para los siguientes 60 minutos. La política es la primera capa, la verificación es la segunda, la respuesta es la tercera. Las tres juntas son lo que separa el cumplimiento documental del cumplimiento real.
El cambio mental que vale la pena hacer hoy es tratar la contraseña como un activo dinámico, no como un control estático. La contraseña que es segura hoy puede aparecer filtrada el mes que viene en un breach que no tiene nada que ver con tu empresa. Lo único que mantiene esa contraseña bajo control es la combinación de política + monitoreo + respuesta.
Lunes por la mañana, el primer paso concreto es éste: revisa la fecha de tu política actual, valida que las cláusulas obsoletas que listamos no estén en ella, y prueba si tus emails corporativos críticos aparecen en algún breach conocido. Esos tres movimientos te dicen, en menos de una hora, dónde está parada tu organización en el espectro de policy theater versus operational security.
Preguntas Frecuentes
¿Qué es una política de contraseñas?
Es el conjunto de reglas que define cómo se crean, almacenan, rotan y revocan las credenciales en una organización. Cubre longitud mínima, MFA, gestores aprobados, rotación, y workflow de respuesta a leaks. Una política funcional se traduce en configuración técnica concreta más un mecanismo de verificación continua, no solo en un documento firmado.
¿Cuál es la nueva política de contraseñas según NIST 2024?
NIST 800-63B (revisión 2024) recomienda priorizar longitud sobre complejidad, prohíbe la rotación periódica forzada, exige MFA, recomienda el uso de gestores de contraseñas, y elimina las preguntas de seguridad como respaldo. La rotación solo debe activarse cuando hay evidencia de compromiso: filtración, phishing exitoso, o dispositivo extraviado.
¿Cuáles son las contraseñas más comunes que debes prohibir?
"123456", "password", "qwerty", "admin", el nombre de la empresa, el año actual, y combinaciones secuenciales del teclado. Una política moderna no se limita a prohibir esta lista corta. Integra un check automático contra diccionarios y dumps conocidos en el momento de creación de la contraseña, usando la API del IdP o un check post-creación.
¿Cómo se redacta una política de contraseñas para una empresa?
Define el alcance (qué cuentas cubre y en qué tier), las reglas técnicas (longitud, MFA, gestores aprobados), el workflow de respuesta a credenciales filtradas, y el mecanismo de revisión anual. Asegura que cada cláusula tenga un control técnico concreto que la enforce en tu IdP o directorio. Política sin enforcement no es política, es deseo.
¿Qué hacer si una contraseña corporativa aparece filtrada en la dark web?
Forzar reset inmediato desde el IdP, validar MFA, revisar el audit log de la cuenta por accesos sospechosos en las últimas 72 horas, verificar los endpoints asociados, comunicar al usuario por canal out-of-band, y registrar el evento completo para auditoría. Para acelerar el proceso, conviene usar un sistema de monitoreo continuo que dispare la alerta tan pronto la credencial aparece en cualquier dump.
¿Es obligatorio cambiar las contraseñas cada 90 días?
No bajo NIST 800-63B (2024). La rotación periódica forzada produce contraseñas más débiles porque el usuario incrementa un dígito o cambia un símbolo manteniendo la estructura predecible. La rotación debe activarse solo cuando hay evidencia de compromiso, no por calendario.
