Esta semana apareció en Lobsters un rant de maurycyz.com titulado “A rant about phishing: It’s not the user’s fault” y me sentí directamente interpelado. No porque yo haya caído en un phishing últimamente (tocaré madera), sino porque llevo años administrando servidores y aplicaciones web propias, y cada vez que toco un flujo de login de algún SaaS corporativo pienso lo mismo que este tipo: le estamos pidiendo al usuario común que haga forense de DNS en cada clic. Y después nos sorprendemos cuando caen.
El problema real: lo legítimo parece estafa
El argumento central del artículo es simple y demoledor: durante años la recomendación de seguridad fue “no hagas clic en links sospechosos”. Suena razonable, salvo por un detalle: el flujo de login típico de muchas empresas hoy pasa por cinco o seis dominios distintos, con UUIDs gigantes, subdominios de terceros y redirecciones que nadie puede auditar a simple vista. El autor pone un ejemplo real (con nombres cambiados) donde ni el usuario, ni la contraseña ni el 2FA viven en el dominio de la empresa. O sea: el sitio legítimo es indistinguible de un phishing.
Y ahí está la clave. Si enseñamos a la gente a ignorar la URL —porque honestamente las URLs legítimas de hoy son ininteligibles—, entonces al atacante le basta con armar una página con un campo de contraseña y el logo de la empresa. La URL ya no importa, porque el usuario aprendió que nunca importa.
El candado verde que ya no protege nada
Otro punto con el que coincido al 100%: el HTTPS como señal de confianza está muerto. Sí, Let’s Encrypt y los certificados gratis fueron una de las mejores cosas que le pasaron a la web. Pero también significa que cualquier estafador consigue su candadito en segundos. El cifrado te dice que la conexión es privada, no que la otra parte sea honesta. Igual que un sobre sellado puede venir de un estafador. Y sin embargo sigue habiendo capacitaciones corporativas enseñando “fíjate que tenga el candado”.
Lo que propone el autor (y yo firmo)
Lo bueno del rant es que no se queda en la queja: propone reglas casi estilo RFC 2119 para cualquier organización:
Un solo dominio raíz reconocible. Los servicios internos en subdominios de ese dominio. Nada de empresa-auth.com ni empresa.alguienmas.com ni auth.otro.com/empresa. Cada una de esas formas normaliza que las URLs “raras” son legítimas, y eso entrena mal al usuario.
Los links de email y SMS bajo el dominio propio. Si necesitas mandar a otra parte, haz una redirección desde tu dominio. Y con los teléfonos igual: nunca digas “llama a este número” en un mensaje; pon el contacto en una página de tu dominio y enlaza ahí.
Para mí esto aplica directo a mi pega. Administro aplicaciones con login propio — WordPress, apps PHP con autenticación casera — y la regla que sigo es precisamente esa: el login vive en el dominio del sitio, siempre. El día que un tercero me pida integrar su flujo de auth en otro dominio, lo voy a mirar con lupa, porque cada excepción le enseña al usuario que desconfiar es opcional.
La lectura del día
El artículo completo es corto, directo y con un diagrama muy útil sobre cómo se lee una URL (spoiler: la parte importante, el dominio de segundo nivel, está justo en el medio, donde menos se mira). Si trabajas en algo que tenga usuarios que inicien sesión — o sea, prácticamente cualquier weá con login — dále una leída. Y si eres de los que diseñan flujos de autenticación, tómatelo como una lista de chequeo: tu dominio es tu marca de confianza. No la regales, no la diluyas, y no hagas que tus usuarios aprendan a ignorarla.
Fuente de inspiración: A rant about phishing: It’s not the user’s fault (and not DNS either)
