> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Obtén información sobre las prácticas recomendadas para trabajar con conexiones sin contraseña. # Prácticas recomendadas para las conexiones sin contraseña
## Implementar el inicio de sesión
Puede implementar la autenticación sin contraseña redirigiendo al Universal Login de Auth0 o integrando el inicio de sesión en su aplicación. Siempre recomendamos implementar Universal Login. Para saber por qué, lea [Universal Login centralizado vs. inicio de sesión integrado](/es/docs/authenticate/login/universal-vs-embedded-login). Para obtener más información sobre cómo implementar la autenticación sin contraseña, lea los siguientes artículos: * [Sin contraseña con Universal Login](/es/docs/authenticate/passwordless/passwordless-with-universal-login) * [Autenticación sin contraseña con Universal Login](/es/docs/authenticate/passwordless/implement-login/universal-login) * [Autenticación sin contraseña con inicio de sesión integrado](/es/docs/authenticate/passwordless/implement-login/embedded-login)
## Use SMS y correo electrónico como factores de autenticación
La implementación sin contraseña de Auth0 permite autenticar a los usuarios con un solo factor. Ese factor único puede ser un código de un solo uso enviado por correo electrónico o SMS, o un enlace mágico enviado por correo electrónico. Aunque usar correo electrónico o SMS puede ser más seguro que una contraseña débil, ambos presentan problemas conocidos: * Los números de teléfono no son suficientes para autenticar a los usuarios. El [sistema de enrutamiento telefónico SS7 que utilizan las redes celulares presenta vulnerabilidades comprobadas](https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html), por lo que no se recomienda como factor de autenticación. Existen muchos vectores de ataque, desde el uso de ingeniería social hasta el intercambio de tarjetas SIM y la compra de acceso a la red SS7. * Tener acceso a una dirección de correo electrónico no es suficiente para autenticar a un usuario (por ejemplo, alias, reenvío y varias personas que usan una misma cuenta). Los proveedores de correo electrónico varían en sus prácticas de seguridad, y algunos no exigen ninguna verificación de la identidad del usuario. SMTP es un protocolo muy antiguo, y muchos proveedores todavía reenvían tráfico SMTP sin cifrar, lo que aumenta la probabilidad de sufrir un ataque de interceptación. Por estas razones, recomendamos que, si usa autenticación sin contraseña, también implemente [Autenticación multifactor (MFA)](/es/docs/secure/multi-factor-authentication) con un factor distinto cuando el usuario realice una operación sensible desde el punto de vista de la seguridad.
## Evite los ataques de phishing
Un ejemplo de cómo podría ser un ataque de phishing es el siguiente: 1. El usuario hace clic en un enlace de un correo electrónico o un sitio web malicioso. 2. El usuario llega al sitio falso del atacante, donde se le pide que introduzca su número de teléfono para autenticarse. 3. El usuario introduce su número de teléfono, y el atacante introduce ese mismo número de teléfono en la aplicación legítima. 4. La aplicación legítima envía un SMS al usuario. 5. El usuario introduce el código de un solo uso en el sitio web del atacante. 6. El atacante ya puede iniciar sesión en el sitio web legítimo. Para reducir las probabilidades de éxito de este ataque, el usuario debe esperar que el SMS identifique claramente la aplicación. Debe configurar la plantilla de SMS para que mencione el nombre del inquilino y/o el nombre de la aplicación: ```http wrap lines theme={null} Tu código de verificación para acceder a Acme @@application.name@@ es @@code@@ ```
## Prevenir ataques de fuerza bruta
Auth0 cuenta con las siguientes protecciones contra ataques de fuerza bruta: * Solo se aceptará el código (o enlace) de un solo uso emitido más recientemente. Una vez emitido el último, cualquier otro quedará invalidado. Una vez utilizado, el último también quedará invalidado. * Solo se permiten tres intentos fallidos de introducir un mismo código de un solo uso. Después de eso, será necesario solicitar un nuevo código. * El código de un solo uso emitido será válido durante tres minutos (de forma predeterminada) antes de caducar. * Si un usuario sin contraseña ha sido bloqueado [administrativamente](/es/docs/manage-users/user-accounts/block-and-unblock-users), Auth0 no enviará ningún código OTP por SMS o correo electrónico hasta que se desbloquee al usuario. Este comportamiento evita que tus proveedores de SMS y correo electrónico reciban solicitudes innecesarias. El tiempo de expiración del código de un solo uso puede modificarse en [Auth0 Dashboard > Authentication > Passwordless](https://manage.auth0.com/#/connections/passwordless).
## Prevenir ataques de enumeración de usuarios
La enumeración de usuarios ocurre cuando un actor malicioso utiliza técnicas de fuerza bruta para adivinar o confirmar qué usuarios son válidos en un sistema. Cuando **Disable Sign Ups** está habilitado, tu aplicación puede volverse vulnerable a ataques de enumeración de usuarios. Auth0 recomienda no habilitar esta configuración para garantizar la máxima seguridad de tu aplicación y de sus usuarios. Si habilitas **Disable Signs Ups**, la [protección contra ataques de fuerza bruta](/es/docs/secure/attack-protection/brute-force-protection) puede mitigar la amenaza de algunos de estos ataques, pero no protege completamente tu aplicación. Es posible que los usuarios quieran autenticarse con distintos factores sin contraseña a lo largo del tiempo. Por ejemplo, podrían registrarse inicialmente mediante SMS y, más adelante, empezar a autenticarse con correo electrónico. Puede lograrlo permitiéndoles vincular sus distintos perfiles mediante la [vinculación de cuentas](/es/docs/manage-users/user-accounts/user-account-linking/link-user-accounts).
## Establezca el encabezado auth0-forwarded-for a efectos del límite de tasa
El endpoint `/passwordless/start` tiene un [límite de tasa](/es/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy) de 50 solicitudes por hora por dirección IP. Si llama a la API desde el servidor, la dirección IP de su backend puede alcanzar fácilmente estos límites de tasa. Para obtener información sobre cómo solucionar este problema, lea la sección Límites de tasa en endpoints sin contraseña de [Uso de las API sin contraseña](/es/docs/authenticate/passwordless/implement-login/embedded-login/relevant-api-endpoints).