¿Cuánto tiempo debe durar un código de confirmación de correo electrónico para evitar la fuerza bruta?

Navega tus respuestas
2

Supongamos que queremos que los nuevos usuarios confirmen su dirección de correo electrónico en un sitio web seguro (uno en el que no queremos que los usuarios que hacen cuentas falsas se hagan pasar por otros usuarios). Por razones de UX podemos querer:

  • Códigos más cortos posibles en caso de que el usuario los escriba
  • códigos alfanuméricos para escribir fácilmente
  • No requiere que el usuario vuelva a ingresar su dirección de correo electrónico cuando confirme el código

Un código que es demasiado corto es vulnerable a los intentos de fuerza bruta para confirmarlo. Por ejemplo, el código 1234 podría ser adivinado fácilmente. El atacante solo registra [email protected] y luego envía códigos de verificación de spam hasta que alcanza el objetivo (y puede verificar muchos otros correos electrónicos aleatorios).

Hay una serie de estrategias para luchar contra esto, incluyendo:

  • Use un código largo que no se pueda adivinar, tal vez obligando al usuario a hacer clic en un enlace de verificación en lugar de escribirlo manualmente
  • Caduca el código con relativa rapidez, lo que le da al atacante menos tiempo
  • Obligue al usuario a identificar quién dice ser al iniciar sesión o al escribir su correo electrónico antes del código de confirmación. Luego expira el código después de X intentos. Esto obliga al atacante a tener que reiniciar constantemente sus adivinanzas, eliminando la posibilidad de una búsqueda exhaustiva. Sin embargo, es potencialmente un papercut UX. Tal vez un usuario haga clic en el correo electrónico de confirmación en un teléfono después de iniciar sesión en su escritorio. El teléfono requeriría iniciar sesión y es una ligera barrera para registrarse.
  • Utilice capcha, limitación de velocidad u otras estrategias para impedir la automatización. Es probable que esto no garantice resolver el problema solo.

Sin embargo, cada estrategia puede potencialmente dañar la UX. ¿Qué es un equilibrio razonable de UX sin comprometer la seguridad?

    
pregunta Bufke 16.09.2017 - 16:23
fuente

3 respuestas

1

Proporcione una URL con un identificador largo, el usuario no tiene que iniciar sesión y un código corto de 4 dígitos, donde el usuario tiene que iniciar sesión, y limite, por ejemplo, a 5 intentos por 24 horas.

Y no es que sea difícil obtener una cuenta de correo electrónico hoy, por lo que tiene un valor global limitado.

    
respondido por el vidarlo 17.09.2017 - 19:21
fuente
0

Coloque sus parámetros necesarios como (correo electrónico del usuario, tiempo de solicitud, ip del usuario, ...) en una matriz y agregue algunos datos aleatorios como semilla en su matriz. Luego encripte su matriz mediante AES-256 y agregue la salida a su url.
Ahora solo envíe la url única al correo electrónico del usuario.
Si los datos recibidos se descifran correctamente, puede validar la dirección de correo electrónico.

Entonces su código de identificación no es vulnerable a la fuerza bruta. También puede agregar cualquier otro parámetro de seguridad a la URL e implementar controles de seguridad adicionales.

    
respondido por el ShayanKM 16.09.2017 - 20:47
fuente
0

No creo que el hecho de que el usuario ingrese su correo electrónico sea malo desde una perspectiva de UX. Muchos sitios requieren que el usuario ingrese AMBOS códigos y amp; e-mail, pero sigue siendo utilizable.

En el registro, genere un hash seguro y almacénelo a lo largo de la ID única del usuario en una base de datos.

Envíeles un enlace: "site.example / verify / $ hash". En esta página, simplemente ingresarán su correo electrónico, ya que el hash nunca coincidirá con otro correo electrónico. Códigos de expiración después de un breve intervalo, o si la cuenta ha sido verificada (lo que ocurra primero).

Alternativamente, si no lo deseas, podrías no requerir la interacción del usuario, esto se podría lograr enviándolos: "site.example / Verify / $ hash / $ mail", que puede llenar automáticamente el campo de correo electrónico.

Para agregar a esto, probablemente sea mejor usar también un límite de captcha / tasa. A pesar de que un bot nunca puede adivinar el hash (esperemos que elijas un algo seguro), puede causar que la aplicación DOS inunde tu base de datos con solicitudes.

    
respondido por el Exhibitioner 21.09.2017 - 20:17
fuente

Lea otras preguntas en las etiquetas

Valor de DNSSEC con opción de permitir degradar protocolo U2F - Valor de contador y clonación de dispositivos