El reciente (y aún en curso) ataque de phishing a
cuentas de desarrollador de NPM
demostró una vez más que incluso los usuarios con conocimientos técnicos caen
en las trampas del phishing.
Cualquiera cae en la trampa si se utiliza un correo electrónico bien
dirigido.
Para que el ataque de phishing a NPM tuviera éxito, bastaba con un correo
electrónico bien redactado y una página de destino convincente. En este caso,
se utilizó «npmjs[.]help», pero unos días después, alguien también
registró «npmjs[.]cam» (el TLD es .CAM, no .COM, un truco de phishing
poco utilizado).
Entonces, si incluso los desarrolladores experimentados caen en estas trampas,
¿cómo protegemos a personal como Recursos Humanos o, peor aún, a nuestro
equipo de ventas? ¿Más capacitación sobre seguridad de clics? ¿Instruirles a
«no hacer clic en enlaces»? ¿O… autenticación de triple factor?
Se ha demostrado que la capacitación es, en el mejor de los casos, ineficaz y
no evitará que el equipo de ventas abra un programa de comisiones actualizado
presa del pánico. Si se supone que los usuarios no deben hacer clic en un
enlace, ¿por qué no los eliminamos simplemente en la pasarela de correo (en
lugar de reemplazarlos con un contenedor)?
La verdadera solución reside en cómo autenticamos, y no se trata de
múltiples factores.
La autenticación multifactor aborda un problema diferente: parte de los
secretos de autenticación puede verse comprometida. El phishing sofisticado y
exitoso puede comprometer todos los factores.
El phishing funciona porque los usuarios no pueden identificar los sitios
web de forma fiable.
Las URL y los certificados TLS son medios técnicos que identifican sitios web,
pero no son adecuados para la identificación por parte de la mayoría de los
humanos. Es demasiado fácil crear un dominio similar, y a menudo ni siquiera
es necesario.
La autenticación multifactor no funciona, ya que un atacante puede pasar
credenciales, como las implementadas en herramientas como
evilginx, solicitando al usuario que proporcione todos los parámetros de
autenticación necesarios. La única forma de protegerse de este tipo de
herramientas es que el usuario no tenga que seleccionar las credenciales
correctas.
Cualquier mecanismo de autenticación que requiera que el usuario decida qué
credencial usar para un sitio web en particular no es fundamentalmente
resistente al phishing.
La forma más simple de un esquema de autenticación «más resistente al
phishing» es un administrador de contraseñas.
Los administradores de contraseñas son bastante eficaces para determinar qué
sitio web está visitando un usuario y qué credenciales usar. Por supuesto, los
usuarios a menudo pueden sobrescribir esta decisión, lo que provoca phishing.
Una mejor opción es la criptografía, que solo permite el acceso a
credenciales específicas para sitios específicos.
Por ejemplo, las
PassKey. Estas claves de acceso se seleccionan automáticamente en función del origen
del sitio en el que el usuario intenta iniciar sesión. El usuario no puede
seleccionar credenciales diferentes, lo que garantiza la seguridad contra el
phishing. Los certificados de cliente TLS también podrían funcionar, pero su
implementación correcta es técnicamente más compleja y, por lo tanto, no son
prácticos para la mayoría de los sitios públicos.
El NIST, en su publicación
SP 800-63B, establece específicamente:
«La resistencia al phishing requiere autenticación criptográfica de uno o
varios factores. Los autenticadores que implican la entrada manual de una
salida (por ejemplo, los autenticadores fuera de banda y OTP) NO DEBEN
considerarse resistentes al phishing, ya que la entrada manual no vincula la
salida del autenticador a la sesión específica que se está autenticando». Esto define los métodos de autenticación populares, como el MFA, no
resistentes al phishing.
En resumen: deja de culpar al usuario y, en su lugar, comienza a trabajar
en las Passkey para cualquier sitio que consideres que necesita un poco más
de seguridad.