Seguridad Informática: cuando la fricción reemplaza a la evidencia
La seguridad informática resulta ser, en muchas organizaciones, una disciplina plagada de rituales que complican la vida de las personas usuarias sin más necesidad ni sustento que la superstición.
Formularios que no permiten copiar y pegar, contraseñas imposibles de recordar, flujos innecesariamente largos, confirmaciones redundantes. Medidas que incomodan al usuario, complican procesos críticos y degradan la experiencia general. Y todo sin ninguna evidencia sólida de que hagan al sistema más seguro.
El problema no es técnico.
Es epistemológico.
Seguridad vs. practicidad: una falsa dicotomía
Buena parte de las decisiones de “seguridad” que degradan la usabilidad se apoyan en una falacia formal bastante básica: la afirmación del consecuente. Como seguridad y practicidad suelen percibirse como incompatibles, se asume que cualquier cosa que vuelva un proceso más engorroso debe hacerlo más seguro.
En otras palabras, se toma una consecuencia frecuente como si fuera una causa, y un efecto colateral como si fuera un mecanismo de protección. El razonamiento es inválido, pero está tan naturalizado que rara vez se lo cuestiona.
No hay threat modeling detrás, ni análisis de vectores reales, ni mediciones de impacto. Hay incomodidad inducida, presentada como control. Esfuerzo confundido con robustez, molestia con mitigación. Y un axioma aceptado sin demostración.
Cómo se construyen las supersticiones
Las supersticiones tienen una ventaja cognitiva poderosa: no requieren prueba. Como no existe forma de afirmar causalmente por qué algo no ocurrió, cualquier acción previa puede ser postulada como la razón de su ausencia. El razonamiento es simple (y profundamente defectuoso): hice X, no pasó Y, entonces X evitó Y.
Supongamos que hoy fuimos a trabajar con los calzoncillos azules. No nos asaltaron por el camino. A partir de ahí, decidimos establecer una relación causal inexistente: los calzoncillos azules evitan asaltos. Desde ese momento, los usamos todos los días, convencidos de que nuestra seguridad depende de eso. El hecho de que jamás podamos demostrar lo contrario hace que la superstición se refuerce sola.
Este mismo mecanismo opera en muchas decisiones de seguridad informática. Se implementa una medida sin evidencia, no ocurre ningún incidente (como suele pasar la mayor parte del tiempo), y esa ausencia se usa como validación retroactiva. La superstición queda institucionalizada.
Superstición no es prevención
Cuando no hay estudios públicos, datos empíricos, estándares reconocidos ni análisis que demuestren que una práctica concreta mejora la seguridad, no estamos ante una medida preventiva: estamos ante una superstición.
Y ante una superstición, el peso de la prueba no recae en quien la cuestiona, sino en quien la introduce.
La única razón por la que estas prácticas prosperan suele ser una combinación de ignorancia del negocio respecto de procesos racionales de toma de decisiones, miedo difuso a que “algo pase” y una cultura organizacional donde nadie quiere hacerse cargo de explicar por qué no se implementó una medida, aun cuando su justificación viole reglas básicas de lógica proposicional, que forma parte del programa de estudios del secundario.
Si Seguridad Informática trae supersticiones al negocio, es función del negocio tener la madurez suficiente para rechazarlas. No gobernar por miedo. No decidir “por las dudas”. No aceptar fricción inútil solo porque alguien la rotuló como seguridad.
Casos típicos de superstición en Seguridad Informática
Las supersticiones de seguridad no aparecen de manera abstracta. Se manifiestan en patrones concretos, repetidos hasta el cansancio, defendidos con convicción pero sin evidencia. Veamos algunos de los más comunes.
1. Bloquear copiar y pegar en formularios sensibles
El caso más burdo y más frecuente es impedir copiar y pegar texto en campos “sensibles”: montos de transferencias, números de tarjeta, CBU, direcciones, tokens.
La lógica implícita es siempre la misma: si lo vuelvo más difícil, debe ser más seguro.
No hay estudios públicos, papers, estándares ni recomendaciones serias que indiquen que bloquear el portapapeles reduzca fraude o aumente la seguridad. No está en OWASP, no está en PCI-DSS, no está en ningún modelo de amenazas bien hecho. Es una decisión puramente ritual.
El resultado real es conocido: más errores de tipeo, más reintentos, más operaciones fallidas, más frustración, más tickets de soporte. Es decir: más riesgo operativo, no menos.
Si el endpoint está comprometido, bloquear “pegar” no sirve.
Si el endpoint no está comprometido, bloquear “pegar” no aporta nada.
Lo único que hace es tranquilizar a quien lo propuso.
2. Contraseñas deliberadamente inhumanas
Otra superstición clásica: políticas de contraseñas diseñadas para ser impronunciables, imposibles de recordar y renovadas con frecuencia arbitraria.
La creencia es que la complejidad forzada equivale a mayor seguridad. La realidad es que produce exactamente los comportamientos que se supone que intenta evitar: contraseñas anotadas, patrones previsibles, variaciones mínimas, reutilización.
Esto no es nuevo. Está documentado en estándares como NIST SP 800–63B, que señala que los requisitos arbitrarios de complejidad no aportan beneficios significativos y tienden a aumentar la frustración y las contramedidas de los usuarios. Aun así, sigue implementándose porque suena seguro.
De nuevo: fricción elevada, seguridad marginal o inexistente.
3. Expiración periódica sin motivo
Cambiar contraseñas cada 30, 60 o 90 días “porque sí” es otro ejemplo perfecto de superstición institucionalizada, persistente incluso después de haber sido cuestionada hace más de una década por organismos como el NCSC, que advierten explícitamente: “the more often users are forced to change passwords, the greater the overall vulnerability to attack”.
No hay compromiso detectado, no hay indicios de filtración, no hay evento que lo justifique. Se cambia porque siempre se hizo así. Y como nunca pasó nada grave después, la práctica se valida sola.
El razonamiento es circular: como nunca pasó nada, debe estar funcionando. Exactamente el mismo razonamiento que los calzoncillos azules.
4. CAPTCHAs que castigan a humanos
CAPTCHAs cada vez más intrusivos, opacos y fallidos, que afectan más a usuarios reales que a atacantes automatizados. Otro ritual de seguridad.
Los bots evolucionan. Los humanos se cansan. La fricción se desplaza hacia quien no es el problema.
Pero el CAPTCHA queda, porque “algo hay que poner”.
5. Confirmaciones redundantes sin información nueva
“¿Está seguro?” “¿Realmente está seguro?” “Confirme nuevamente.”
Sin aportar contexto adicional, sin resumen claro, sin cambio en el estado de riesgo. Pura repetición.
No es un control.
Es una liturgia.
6. Restricciones sin fundamento
Otro patrón clásico de superstición es imponer restricciones arbitrarias sobre los datos de entrada, sin ningún respaldo normativo, técnico ni de negocio, y luego justificarlas con la palabra mágica: seguridad.
- DNIs que “deben” tener exactamente ocho caracteres.
- Campos de CUIL/CUIT que no permiten más de 11 dígitos, impidiendo ingresar separadores habituales como puntos, guiones o espacios.
- Formularios que rechazan entradas perfectamente válidas porque no coinciden con el modelo mental del programador que las definió.
Estas decisiones no solo son incorrectas desde el punto de vista del dominio (como ya escribí en el caso del DNI argentino) sino que además suelen defenderse con argumentos técnicamente erróneos. He llegado a discutir con “expertos” de un banco que sostenían que estas restricciones eran “por seguridad”, y que por ese motivo había que limitar lo que el usuario podía tipear… usando JavaScript, lo cual es inherentemente inseguro.
Eliminar caracteres no numéricos de un input es trivial. Rechazar usuarios legítimos porque escriben como seres humanos no es una medida de seguridad: es una muestra de ignorancia técnica y de desprecio por la experiencia real.
7. “Por seguridad” como carta blanca para cualquier cosa
La seguridad es una carta tan poderosa que no solo la juega Seguridad Informática. La juegan soporte, producto, legal, compliance y cualquiera que necesite cerrar una conversación sin fundamentos.
Un ejemplo reciente y particularmente ilustrativo: la imposibilidad de eliminar manualmente chats en Gemini dentro de Google Workspace. Ante mi reclamo, la respuesta oficial fue que no se trata de un error ni de una limitación del producto, sino de una medida de seguridad.
No poder borrar información propia, en una cuenta paga, no tiene absolutamente nada que ver con medidas de seguridad. Es una decisión de diseño, y muy mala. O es que todavía no llegaron a ese punto del backlog.
El argumento de seguridad funciona porque es difícil de refutar en caliente. Nadie quiere quedar del lado de “quien bajó la guardia”. Entonces la frase “es por seguridad” se convierte en un comodín que justifica cualquier limitación, incluso aquellas que van en contra de principios básicos de control de datos, privacidad y experiencia de usuario.
El denominador común
Todos estos casos comparten algo fundamental: no están basados en evidencia, sino en miedo. No en modelos de amenazas reales, sino en la necesidad psicológica de sentir que “hicimos algo”.
Y lo más importante: la ausencia de incidentes se usa como prueba de eficacia, cuando en realidad no prueba absolutamente nada.
Eso es una superstición, no una estrategia de seguridad.
Un problema de UX que “no es un problema de UX”
Y acá es importante ser claros: esto no es, técnicamente, un problema de UX. Es una falla de razonamiento.
Demoler supersticiones no debería ser responsabilidad del área de UX. Pero no hacerlo impacta directamente en la experiencia de los usuarios, porque lo que los usuarios experimentan es siempre consecuencia de las decisiones de todos los involucrados. Especialmente cuando esas decisiones se toman a contramano de procesos racionales.
Desde UX no nos corresponde demostrar que estas prácticas no mejoran la seguridad. Nos corresponde mostrar el impacto negativo que tienen en la experiencia: en los procesos, en los errores, en los abandonos, en la confianza del usuario.
A Seguridad Informática le corresponde demostrar que estas prácticas no son supersticiones. Que están respaldadas por datos, estudios, estándares o evidencia empírica. La carga de la prueba es de quien introduce la fricción, no de quien la cuestiona.
Cuando estas decisiones prosperan, lo que vemos no es solo un fracaso del área de Seguridad Informática por introducir falsos positivos, sino también un fracaso del negocio por no contar con procesos racionales de toma de decisiones.
Muchas organizaciones donde esto ocurre no tienen UX. O dicen tener UX, pero no pesa en la mesa donde se decide. Y eso también es un síntoma.
Conozco mucha gente de negocio a la que le gusta decir que es “customer centric”. Pocas están dispuestas a cuestionar supersticiones cuando vienen envueltas en miedo, jerga técnica y la frase mágica: “por seguridad”.
Y así es como terminamos teniendo conversaciones en las que hay que repasar cosas que nuestras contrapartes deberían haber visto como parte de la educación básica.
Santiago Bustelo
Diciembre 2025