Limitar el intento de inicio de sesión de usuario contra PBKDF2

  

1) ¿Mi razón de ser para limitar el número de intentos que un usuario puede iniciar sesión es razonable?

No, absolutamente no de la forma en que lo describe. Está bien limitar el número de intentos fallidos en un corto período de tiempo y escalar desde allí, pero nunca debe establecer un límite estricto para un período largo como un día entero. ¿Quién eres tú para decirme que no puedo iniciar sesión en mi cuenta por 201a vez hoy?

  

2) ¿Hay algún defecto en mi argumento

Sí. MD5 / SHA1 / SHA256 / SHA512, etc. es estúpidamente defectuoso para el hashing de contraseñas. Además, PBKDF2 ha sido ampliamente utilizado durante muchos años. No hay signos de que se rompa "en unos pocos años". Consulte esta respuesta para obtener más detalles.

  

3) ¿Mi jefe está correcto?

Absolutamente, sí.

Creo que el punto en el que estás confundido aquí es la diferencia entre en línea y sin conexión en los ataques de fuerza bruta. Esencialmente, los dos controles que estás mirando están diseñados para diferentes ataques y ambos deberían aplicarse (es decir, no es uno u otro)

Su idea de limitar los inicios de sesión del usuario antes del bloqueo se refiere a un ataque de fuerza bruta en línea. esto ocurre cuando un atacante intenta adivinar la contraseña a través de la aplicación. Por lo general, recomiendo 10 inicios de sesión incorrectos antes del bloqueo, el razonamiento es que si un usuario no puede adivinar la contraseña en 10 intentos, la ha olvidado :).

El algoritmo de hash utilizado para almacenar contraseñas se defiende principalmente contra ataques de fuerza bruta sin conexión. Esto ocurre cuando el atacante tiene acceso a las contraseñas con hash y puede intentar descifrarlas directamente (por ejemplo, no a través de la aplicación). Aquí sería correcto usar PBKDF2 (o bcrypt o scrypt) ya que están diseñados específicamente para este propósito y ralentizarán el proceso de adivinación de los atacantes.

El problema de usar MD5 o SHA-1 es que estos no están diseñados para el almacenamiento de contraseñas, sino que están diseñados (parcialmente) para ser rápidos, lo cual es una propiedad que no queremos cuando se evita un ataque de fuerza bruta sin conexión.

  

1) ¿Mi justificación para limitar el número de intentos que un usuario puede iniciar sesión es razonable?
  2) ¿Hay algún defecto en mi argumento?

Absolutamente , pero no completamente. En primer lugar, 200 intentos es un número enorme; la mayoría de las personas lo mantendrán por debajo de 20 por día, y pienso en 50 como en un número razonable de intentos.
Sin embargo, la falla en su "razón de ser" está bloqueando a las personas de sus cuentas. Como alguien ya notó, un atacante sabiendo que esta vulnerabilidad podría usarla para bloquear a las personas de sus cuentas (esto es más un troll que un ataque). Lo que implementé en mi sitio web es:

  

1. Almacene el número de intentos en un archivo (el hash md5 del intento de nombre de usuario) y actualícelo si es necesario
  
2. Recupera el número actual de intentos. Si es más grande que, por ejemplo, tres, pida al usuario que responda primero a un CAPTCHA.
  

Creo que deberías seguir este tipo de algoritmo, es decir, Allow a reasonable number of "free" attempts, then challenge or otherwise slow down the user before logging him in .

  

3) ¿Mi jefe está correcto?

No veo por qué atenerse a un algoritmo en particular, pero sí , él tiene razón: PBKDF2 es actualmente una función segura (no se prevén ataques). Además, tener un "número de iteraciones deseadas" es una característica muy buena, ya que aumenta el espacio donde se distribuyen los hash (claves, realmente) [esta característica es bastante inútil si cualquier usuario puede registrarse en el servicio]. Si realmente es el caso de un entorno de alta seguridad, donde la seguridad está por encima del rendimiento, es posible que desee emplear REALMENTE PARANOID como ElGamal key generation , junto con bcrypt.