En resumen: la autenticación de dos factores para accesos de administración hace que una contraseña robada o adivinada no baste por sí sola. Debe aplicarse en todos los lugares desde los que alguien puede modificar su sitio web o su servidor: CMS, hosting, panel, SSH, dominio, DNS y los buzones de los administradores. Tan importantes como la configuración son los códigos de emergencia y una regla clara sobre quién tiene un acceso propio a qué.
Por qué las contraseñas por sí solas no bastan para los administradores
Las contraseñas se pierden por muchos caminos: correos de phishing, software malicioso en un equipo de trabajo, filtraciones de datos en otros servicios o simplemente por su reutilización. Los ataques automatizados prueban sin parar credenciales robadas contra las páginas de login conocidas.
Con un segundo factor, el atacante necesita además algo que solo posee el usuario autorizado, por ejemplo un smartphone con una app de autenticación o una llave de seguridad. Eso eleva la barrera de forma considerable, sobre todo en cuentas con amplios permisos.
Para la dirección es importante una delimitación: la autenticación de dos factores protege los accesos, no el software que hay detrás. Una vulnerabilidad como PHP2Shell, que permite la ejecución de código sin autenticación, no se cierra con ella. Ambas cosas van juntas: software actualizado y accesos bien protegidos.
Qué métodos de dos factores son adecuados
Los métodos se diferencian en seguridad y en comodidad de uso. Para las cuentas de administrador debería emplear como mínimo apps de autenticación y, para los accesos especialmente críticos, llaves de seguridad o passkeys.
| Método | Protección contra phishing | Idoneidad para administradores |
|---|---|---|
| Código por SMS | baja | solo como transición |
| App de autenticación (TOTP) | media | buen estándar |
| Confirmación push | media, vulnerable a ataques por fatiga | adecuada con comparación de números |
| Llave de seguridad o passkey (FIDO2/WebAuthn) | alta | recomendada para accesos críticos |
| Clave SSH con frase de contraseña | alta | estándar para accesos a servidores |
Los códigos de un solo uso de una app pueden interceptarse en una página de phishing que parezca auténtica y reutilizarse de inmediato. Los métodos FIDO2, en cambio, comprueban la dirección de la página y no funcionan en una página falsa. Esa es la razón por la que son la mejor elección para administradores con acceso a muchos sistemas.
Autenticación de dos factores para accesos de administración: la lista completa
Los atacantes buscan el acceso más débil. Repase por eso todos los puntos desde los que alguien puede modificar su sitio web, su servidor o su dominio:
- CMS y backend de la tienda: WordPress, Shopware, TYPO3 y otros ofrecen autenticación de dos factores en el núcleo o mediante extensiones mantenidas. Qué variante se recomienda figura en la documentación del fabricante.
- Cuenta de cliente del hosting: quien entra aquí suele poder restablecer contraseñas, descargar copias de seguridad o reinstalar el servidor.
- Panel del servidor, como Plesk o cPanel, si existe.
- SSH y SFTP: claves en lugar de contraseña, véase el apartado siguiente.
- Registrador de dominios y DNS: un ajuste de DNS modificado redirige a sus visitantes y correos sin que el servidor se vea afectado.
- Buzones de correo de los administradores: por ellos pasan los restablecimientos de contraseña de casi todos los demás servicios.
- Repositorio de código y despliegue: quien puede escribir ahí puede desplegar código malicioso.
- CDN, WAF, Google Search Console y proveedores de pago.
Anote para cada entrada quién tiene acceso, si el segundo factor está activo y dónde están los códigos de recuperación. Esa lista es, al mismo tiempo, una parte importante de su plan de emergencia, porque tras un incidente hay que revisar y renovar esos accesos en poco tiempo.
SSH: claves en lugar de contraseña
Para los accesos a servidores, iniciar sesión con clave SSH es la protección fuerte habitual. La clave privada está en el dispositivo del administrador y protegida con una frase de contraseña; en servidores especialmente sensibles puede estar en una llave de hardware. Una vez configurado y probado el inicio de sesión con clave para todos los administradores, desactive el inicio de sesión con contraseña:
# /etc/ssh/sshd_config (extracto)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Comprobar la configuración antes de recargar el servicio
sshd -t && systemctl reload ssh # en sistemas RHEL: sshd
Al hacer el cambio, deje abierta una sesión existente y pruebe el inicio de sesión en una segunda ventana. Así, si hay un error, no se queda fuera. Cada administrador recibe una clave propia; las claves compartidas por todo un equipo no se pueden retirar limpiamente cuando se marcha alguna persona. Más información básica en Proteger por su cuenta servidores root y vServers.
Acceso de emergencia y códigos de recuperación
Una buena introducción prevé el fallo. Los smartphones se pierden, los empleados dejan la empresa, las llaves de seguridad se rompen. Sin un plan, en el momento equivocado no hay nadie con acceso disponible.
Registre dos factores para cada cuenta crítica, por ejemplo una llave de seguridad en la oficina y una app de autenticación, y guarde los códigos de recuperación separados de la contraseña.
Otras reglas que han dado buen resultado:
- Cuentas personales en lugar de inicios de sesión de administración compartidos, para que los cambios sean trazables.
- Un acceso de emergencia documentado, con credenciales guardadas por separado, cuyo uso llame la atención y quede registrado.
- Al salir empleados o prestadores de servicios, retirar el mismo día todos los accesos y claves.
- Tras un incidente de seguridad, revisar no solo las contraseñas, sino también los factores registrados y las sesiones activas.
En la introducción en el equipo ha dado buen resultado un procedimiento claro. Empiece por las cuentas que pueden causar más daño: hosting, dominio, DNS y los buzones de correo de los administradores. Después vienen los servidores, el CMS y los servicios. Fije una fecha límite a partir de la cual ya no sean posibles los inicios de sesión sin segundo factor y asegúrese antes de que todos los implicados lo hayan configurado.
Explique brevemente al equipo por qué es necesario el cambio y cómo funciona en el día a día. Una guía de una página con capturas de pantalla reduce notablemente las consultas. Los prestadores de servicios externos y las agencias deberían recibir accesos propios y personales con segundo factor en lugar de un inicio de sesión compartido, para que los accesos sigan siendo atribuibles y puedan retirarse limpiamente al terminar el proyecto.
Cómo proteger además las páginas de inicio de sesión frente a intentos automatizados se explica en la guía Proteger los inicios de sesión de administración contra la fuerza bruta.
¿Cómo ayuda PHP SOS en concreto?
- Elaboramos con usted una lista completa de todos los accesos de administración y mostramos dónde falta el segundo factor.
- Pasamos los accesos a servidores a claves SSH y desactivamos de forma controlada los inicios de sesión con contraseña en el marco del refuerzo del servidor.
- Documentamos los accesos de emergencia y las vías de recuperación de modo que funcionen en caso de necesidad.
- En el contrato de mantenimiento de seguridad revisamos los accesos con regularidad y eliminamos las cuentas huérfanas.
Preguntas frecuentes
¿Qué método de dos factores es el más seguro?
Las llaves de seguridad por hardware y las passkeys según el estándar FIDO2 se consideran especialmente resistentes al phishing, porque están ligadas a la dirección auténtica. Las apps de autenticación con códigos de un solo uso son un buen estándar. El SMS es mejor que nada, pero es la variante más débil.
¿Qué ocurre si se pierde el smartphone con la app de autenticación?
Para eso existen los códigos de recuperación que se muestran al configurarlo. Deben guardarse de forma segura, por ejemplo en una caja fuerte o en un gestor de contraseñas protegido. Además, al menos un segundo administrador debería poder restablecer el acceso.
¿Protege la autenticación de dos factores también frente a PHP2Shell?
No. PHP2Shell permite la ejecución de código sin autenticación; el inicio de sesión ni siquiera se utiliza. Contra PHP2Shell solo ayuda la actualización a una versión corregida de PHP con reinicio de todos los workers. La autenticación de dos factores protege frente a contraseñas robadas o adivinadas.
¿Basta con la autenticación de dos factores en el CMS?
No, un atacante elige el acceso más débil. La cuenta de hosting, el panel del servidor, SSH, la gestión de dominios, el DNS y los buzones de correo de los administradores deben estar igualmente protegidos; de lo contrario, la protección del CMS se puede eludir.