- Las políticas que exigen autenticación frecuente solo generan fricción para el usuario sin un efecto real de mejora de seguridad
- Con el aumento de amenazas modernas como los ataques de fatiga de MFA, la autenticación repetida puede convertirse en una vulnerabilidad
- La función de bloqueo de pantalla del sistema operativo y las actualizaciones en tiempo real de las políticas de acceso son medidas de protección más efectivas
- La autenticación adicional solo es necesaria justo antes de acciones sensibles; los ciclos arbitrariamente cortos de inicio de sesión son innecesarios
- Los métodos modernos de control de acceso aplican políticas de forma automática y rápida sin interrumpir al usuario
Por qué la autenticación frecuente no mejora la seguridad
Problemas que provoca la autenticación repetida
- Cuando la sesión expira durante el flujo de trabajo y hay que volver a ingresar con frecuencia la contraseña y el MFA (autenticación multifactor), se produce una caída en la productividad
- Al principio bastaba con volver a introducir la contraseña, pero al añadirse la etapa de MFA, aumentaron el tiempo perdido y la molestia de los usuarios
- Cuanto mayor sea la frecuencia de solicitudes de MFA, mayor también es la probabilidad de éxito de los ataques de fatiga de MFA (MFA fatigue attacks)
- Antes se consideraba que cambiar la contraseña con frecuencia o usar tiempos de expiración de sesión cortos era una medida de seguridad eficaz, pero las guías modernas hoy lo evalúan más bien como algo contraproducente
- La seguridad no depende del ciclo de inicio de sesión, sino de qué tan rápido se reflejan la gestión de permisos de acceso y los cambios de políticas
La esencia de la autenticación
- La autenticación suele demostrar una de estas dos cosas
- Prueba de posesión del dispositivo: verificar si se tiene físicamente el dispositivo, como con Windows Hello PIN, YubiKey o una tarjeta inteligente
- Prueba de identidad personal: identificar si se trata realmente de ese usuario, como con una contraseña, Face ID o Touch ID
- La función principal de un Identity Provider (IdP) es centrarse en la verificación de identidad
- Face ID, Touch ID y Windows Hello son sistemas integrados con alta seguridad porque manejan al mismo tiempo la prueba de posesión del dispositivo y la prueba de identidad personal
- Muchos administradores configuran expiraciones de sesión cortas por la inquietud de que los cambios de políticas no se reflejen de inmediato
Amenazas de seguridad reales y el papel de la autenticación
- La mayoría de los atacantes intentan comprometer sistemas mediante phishing remoto, y robar contraseñas es muy fácil
- Para defenderse de ataques remotos, usar una segunda autenticación (por ejemplo, YubiKey) es una medida importante
- Cuando ocurren ataques físicos, como pérdida o robo de un dispositivo, normalmente la pantalla ya está bloqueada
- De hecho, cuanto más a menudo se inicia sesión, más oportunidades tiene un atacante de robar credenciales, lo que perjudica la seguridad
El papel del sistema operativo y de los servicios web
- Los sistemas operativos modernos protegen automáticamente el sistema con la función de bloqueo de pantalla cuando el usuario se aleja
- En lugar de aumentar la molestia del usuario con más autenticaciones, es preferible aplicar políticas de bloqueo automático
- Salvo en computadoras compartidas, la expiración corta de sesiones web no es más que un vestigio de la época de los cibercafés
- Fuera de servicios sensibles (por ejemplo, la banca en línea), las políticas inadecuadas de expiración de sesión terminan perjudicando tanto la seguridad como la usabilidad
Un modelo de seguridad eficiente y amigable para el usuario
- Lo ideal es la autenticación inmediata antes de una acción sensible (on-demand authentication)
- El modo check de Tailscale SSH y Slack Accessbot ofrecen la función de verificar al usuario al instante cuando hace falta
- Si además se aplica el bloqueo forzado de pantalla del sistema operativo, es posible mantener el equilibrio entre seguridad y comodidad
- La verificación continua del estado de seguridad (device posture check) y el control de acceso en tiempo real se realizan automáticamente sin depender del comportamiento del usuario
- Ejemplos:
- Si el dispositivo está desconectado, se pierde, o falla una inspección de seguridad, el acceso se revoca de inmediato
- Si cambia el rol o la identidad del usuario, la política de acceso se actualiza automáticamente
- Frente al enfoque de obligar al usuario a autenticarse una y otra vez, el enfoque de automatización en tiempo real es mucho más inteligente y seguro
Conclusión
- Iniciar sesión con frecuencia no mejora eficazmente la seguridad y, por el contrario, puede llevar a la reutilización de contraseñas, phishing y fatiga de MFA
- Un sistema de seguridad silencioso y automatizado es la mejor protección
- Tailscale busca una seguridad adaptativa, inteligente y realmente útil
- Está diseñado para que el usuario no tenga que ajustar manualmente los ciclos de inicio de sesión y solo experimente la mínima fricción de autenticación en el momento necesario
- Las funciones de verificación de seguridad en tiempo real de Tailscale también pueden extenderse a otras apps para proteger incluso sistemas heredados de forma segura
Enlaces de referencia
4 comentarios
También se mencionó en los comentarios de HN, pero comparado con un entorno de TI que cambia rápido, el problema es que las inspecciones y normativas de seguridad, basadas en estándares rígidos y anticuados, terminan frenando las cosas. Quizá esto ya sea algo que todos en primera línea conocen bien... jaja
Muchísimos servicios en Corea muestran la molesta notificación de que restablezcas tu contraseña una vez cada 30 días.
Como fue una obligación de seguridad de la información personal que se impuso durante años, resulta muy molesto... snif, snif
Opinión de Hacker News
Creo que las políticas obligatorias de cambio periódico o vencimiento de contraseñas son un problema aún mayor; con frecuencia terminan bloqueando las cuentas de la gente (por ejemplo, si la contraseña vence durante las vacaciones), y luego viene la molestia de tener que ir en persona a TI, pasar horas al teléfono con TI para pedir un restablecimiento, o contactarles a través de un colega que no esté bloqueado.
Muchas (¿la mayoría de?) empresas siguen aplicando estas políticas, pero NIST ya no recomienda cambios arbitrarios de contraseña.
Documento oficial de NIST
Microsoft también dice que el vencimiento de contraseñas hace más daño y no lo recomienda.
Documento oficial de Microsoft
Aun así, en TI o seguridad parece que estas recomendaciones no se consideran lo bastante “autorizadas”, y además todavía existen guías que siguen recomendando estas políticas.
A veces, cuando inicio sesión en algún sitio aleatorio y me obliga a restablecer la contraseña, pienso que quizá no se debe a un vencimiento por tiempo, sino a que la cuenta pudo haberse filtrado o visto comprometida.
Si el operador del sitio sabe que ciertas cuentas aparecen en una lista de filtración de datos, me parece razonable exigir un cambio forzado de contraseña en el siguiente inicio de sesión.
Le comenté esto a un responsable de ciberseguridad y me dijo que el estándar PCI exige cambios periódicos de contraseña, así que depende de cuál auditoría consideres más importante.
Hace tiempo estas políticas me fastidiaban tanto que simplemente las sorteaba agregando una letra al final de la contraseña cada vez, en orden de a a z.
Por suerte, en la empresa donde trabajo ahora llevo 3 años con la misma contraseña y estoy feliz.
No me parece lógico que los proveedores me pidan cambiar periódicamente la contraseña si no se ha filtrado.
Es absurdo que esto siga aplicándose como si todavía fuera un estándar oficial.
Al final, todas mis cuentas terminan usando solo el patrón 1234abcd@.
Con los productos de Apple esto me resulta realmente incómodo.
He confirmado que este patrón se aplica en todos los productos de Apple.
Configuro TouchID en la Mac, inicio sesión con mi cuenta de Apple en App Store, y cuando intento instalar una app me siguen apareciendo ventanas pidiéndome la contraseña; podrían autenticar con TouchID, pero aun así la piden cada vez.
Pasa igual incluso al instalar apps gratis, y me parece un paso totalmente innecesario.
Este patrón también aparece a veces en el iPhone de mi esposa.
Sobre todo al restablecer el teléfono y configurarlo de nuevo, Apple pide repetidamente volver a ingresar la contraseña.
Aunque la situación ya está suficientemente protegida con TouchID, siguen haciendo esto y resulta desesperante.
Si accedes a servicios de Apple desde un dispositivo que no es de Apple, la incomodidad es todavía peor.
Cada vez que inicio sesión en icloud.com, aunque pulse "confiar en este dispositivo", al día siguiente vuelvo a repetir el proceso de autenticación en dos pasos con contraseña + código de un solo uso.
Si Face ID falla durante un pago o al instalar una app, no deja usar el PIN como alternativa y obliga a ingresar la contraseña completa de la cuenta de Apple; además, ni siquiera puedes abrir la app del gestor de contraseñas.
Pasar por eso en la caja de pago es una experiencia realmente terrible.
Hay que asegurarse de que esté activada la opción para aprobar compras con TouchID.
(Hay que configurarlo en Settings > Touch ID & Password).
Si eso no está activado, puede seguir pidiéndote la contraseña.
Mi experiencia es que tras reiniciar solo hace falta autenticarse una vez, y después TouchID sirve para la mayoría de las autenticaciones.
Cada vez que conecto el iPhone a la Mac para sincronizar, aparece la ventana de "¿Confiar en este dispositivo?" tanto en la Mac como en el iPhone, y aunque siempre elijo "Sí", vuelve a preguntarlo en la siguiente conexión.
Me parece natural que se pida reautenticación en tareas que requieren privilegios de SUDO.
En esos casos, si agrupas las tareas relacionadas y haces que solo pida autenticación una vez, puedes reducir la cantidad de reautenticaciones.
Mi hijo usa un iPad muy viejo, con iOS 10.3, así que la app del gestor de contraseñas ni siquiera funciona, y el navegador también es una app de 32 bits, por lo que no puede abrir sitios modernos.
Entonces, cada vez que uso App Store tengo que escribir manualmente una contraseña de más de 50 caracteres, y es extremadamente molesto.
Creo que quienes deberían leer este tipo de artículos son los auditores que hacen auditorías de seguridad.
Mientras no cambie el criterio que ellos esperan ver, muchas empresas van a seguir obligadas a aplicar políticas tontas en la práctica aunque digan que son estándares de la industria.
Sobre todo las empresas pequeñas de ciertos sectores también tienen que sacar buena calificación en auditorías de seguridad, así que adoptan una gran cantidad de procedimientos inútiles.
Nos obligan a aplicar al menos 6 controles de seguridad que sabemos que en realidad no sirven, y los auditores todavía se resisten mucho a cambiar.
Cuando nos toca una auditoría SOC2, siempre les muestro las guías de NIST.
Si les enseñas el enlace, la mayoría termina aceptando el criterio de NIST.
Tanto Apple como Microsoft permiten configuraciones empresariales para que el equipo de seguridad desactive opciones como “recordar mi dispositivo” o “confiar en este dispositivo”.
Los auditores o el CISO (director de seguridad de la información) hacen auditorías totalmente basadas en checklist, así que da igual si realmente mejora la seguridad o no; lo importante es conseguir la aprobación de la auditoría.
Estas configuraciones solo aumentan la incomodidad del usuario y en la práctica hasta empeoran la seguridad real.
Creo que Microsoft también arruinó así los juegos de PC.
Sé que cada vez que ejecuto juegos como Minecraft o Master Chief Collection va a aparecer de la nada una ventana de reautenticación, y por eso termino posponiéndolo.
Por esta incomodidad incluso desactivé el 2FA (autenticación en dos pasos) en mi cuenta.
Es solo un juego, no una verificación bancaria; ojalá simplemente me dejaran jugar tranquilo.
Dicen que hace poco añadieron una función para autenticarse escaneando un código QR, pero me parece que quien diseñó este sistema está totalmente desconectado de la experiencia real del usuario.
Hay una parte que casi no se menciona en el artículo.
Creo que una mala UX (experiencia de usuario) puede convertirse por sí sola en una vulnerabilidad de seguridad.
Si un sistema se comporta de forma irracional en el día a día, es mucho más probable que los usuarios no detecten cambios o comportamientos anómalos cuando ocurra un problema real.
Por ejemplo, si la solicitud de contraseña aparece demasiado seguido, uno termina escribiéndola por costumbre, y en ese contexto es más fácil caer en riesgos como el phishing.
Además, si el sistema operativo no maneja bien los programas de inicio o el código sospechoso que corre en segundo plano, también es más fácil explotarlo.
Otro problema es que muchos profesionales de seguridad comunes casi no consideran la “psicología humana” como una variable importante, y todo tiende a diseñarse en función de checklists o de la conveniencia de la empresa.
Son errores que podrían prevenirse con un buen diseño de producto, pero como los proveedores de productos y servicios son mucho más activos ante cambios regulatorios que los consumidores, las mejoras casi no ocurren.
Por eso, en la práctica sí creo que un endurecimiento regulatorio ayuda al desempeño de la seguridad, pero desde la perspectiva de las empresas se da la extraña situación de que nadie quiere regulaciones sobre sus propios productos o servicios.
Los sistemas que piden reautenticación frecuente no mejoran realmente la seguridad (aunque los períodos de vencimiento muy largos serían una excepción parcial).
En un sistema de autenticación decente, lo clave es tener la capacidad de revocar privilegios de inmediato mediante expiración de sesión o manejo explícito de sesiones.
En la práctica, cuando revocas una sesión, el “retraso” hasta que esa sesión expire por completo y pierda todo acceso es mucho más importante que la frecuencia de reautenticación.
Esto se vuelve más complejo cuanto más grande es la estructura del esquema de autenticación y cuantos más sistemas intervienen.
Por eso se necesita un refresh token.
El token real vence periódicamente, pero al cliente se le da por separado la oportunidad de renovar un token nuevo.
La revocación del token se controla bloqueando la posibilidad de generar nuevos tokens.
Yo pienso algo parecido.
En la empresa usamos un método de autenticación en dos etapas.
Una o dos veces al día iniciamos sesión en keycloak con ADFS + MFA, y la mayoría de los sistemas usan keycloak como proveedor OIDC, renovando el token cada 10 a 15 minutos.
Así que normalmente solo pasamos por el proceso de autenticación molesto una vez al día, y si hace falta podemos cortar por completo el acceso a servicios conectados por VPN en menos de 15 minutos.
La ventaja es que, en uso normal, casi ni se nota este cambio.
No hace falta reautenticar; basta con renovar periódicamente el token existente.
Lo ideal es separar el tiempo de vencimiento de la autenticación (
auth) del tiempo de vencimiento de la autorización (authorization).Si obligas a reautenticarse con frecuencia, la gente termina buscando formas de saltárselo.
Acaban apareciendo toda clase de “trucos”: escribir la contraseña en papel, guardarla en Google Docs, ponerle a una Yubikey un Arduino + servomotor, reenviar los SMS al correo electrónico o mandar los códigos TOTP por Wechat.
Al final, mientras más severa se vuelve una política de autenticación incómoda, más buscan los usuarios atajos inseguros para poder usar su computadora aunque sea un poco como quieren.
En el artículo aparece una idea del tipo “ahora que la mayoría de los OS permiten desbloqueo con huella o rostro, ya no hay motivo para no bloquear la pantalla al alejarse”, pero en la práctica eso aplica muy poco a estaciones de trabajo (PCs de escritorio).
En 30 años dando soporte en campo, solo he visto una desktop con lector de huellas.
Cámaras casi no hay tampoco; de las PCs de 5 sedes que administro hoy, menos del 2% tienen cámara.
El reconocimiento facial además agrega otro factor de incomodidad para los usuarios.
Ya existe mucha desconfianza por el reconocimiento facial no consentido y encubierto (cámaras de vigilancia, escuelas/empresas/policía, etc.), y creo que esa incomodidad está totalmente justificada.
Aunque el equipo sea de mi propiedad, las empresas de software en la práctica diseñan todo de una manera que invade mi autoridad sin ningún límite moral real.
Por eso creo que las llaves de seguridad son más apropiadas para estaciones de trabajo.
Las políticas de seguridad informática en la industria funcionan con una lógica parecida a “nadie despide a quien compra IBM”: todos se limitan a hacer lo mismo que hacen los demás.
No importa si el sistema está roto o no; lo importante es haber hecho “lo que dice el libro”.
Y ese libro (el estándar) es uno muy deficiente, hecho hace 30 años.
Por eso se necesita una cantidad enorme de energía para convencer al responsable de seguridad de la información de que no hace falta cambiar la contraseña cada 3 meses.
En una empresa cliente tienen un límite de sesión de 30 minutos en todos los sistemas.
Ya de por sí no me gustaba Jira, pero tener que volver a iniciar sesión cada vez que quiero ver un ticket lo hace insoportable.
Al final entro en un círculo vicioso en el que termino viendo Hacker News en lugar de trabajar.
Por suerte, hoy en día la mayoría de los servicios al menos guardan en caché el contenido de mi trabajo.
Se llama SSO, o sea, ‘SINGLE sign on’, pero en la práctica no deja de pedir autenticación repetida.
No entiendo por qué tengo que ver mensajes pidiéndome autenticación SSO cientos de veces al día.
Con el celular se entiende por el riesgo de pérdida o robo, pero en desktop todavía es común dejar una computadora compartida (por ejemplo, en una biblioteca) sin cerrar sesión al levantarse, y muchos usuarios no son conscientes de eso.
Como yo lo recuerdo, SSO significaba iniciar sesión en varios sistemas con un solo ID, no necesariamente que fueras a iniciar sesión una sola vez.