El problema es que esto solo ayuda si una cuenta en particular es atacada. Pero en lugar de probar 100 contraseñas en una cuenta, un atacante también podría probar una contraseña común en 100 cuentas. Para evitar esto, también debe controlar el número total de inicios de sesión fallidos y comenzar a mostrar CAPTCHAs cuando el número sea excepcionalmente alto.
Para facilitar su uso, los inicios de sesión fallidos deben caducar automáticamente después de un tiempo. No tiene sentido mantener el contador más de, digamos, 24 horas.
Por último, pero no menos importante, tenga cuidado con las condiciones de carrera cuando realmente implemente esto. Muchas personas primero verifican el número de inicios de sesión fallidos y luego incrementan el contador si es necesario. Pero esto le permite a un atacante enviar un número arbitrario de solicitudes simultáneas entre la verificación y el incremento, y cada vez que el servidor todavía "vea" el contador anterior. Necesita una sola consulta donde incremente el contador y obtenga el nuevo valor al mismo tiempo, y luego debe verificar ese valor. Diferentes sistemas de bases de datos tienen diferentes técnicas para esto. En PostgreSQL, puede usar una consulta UPDATE con una cláusula RETURNING . En MySQL, puede usar una consulta UPDATE con la expresión de incremento envuelta en LAST_INSERT_ID() y luego obtener el valor incrementado con SELECT LAST_INSERT_ID() . Tenga en cuenta que no puede realizar una consulta simple SELECT después de la actualización, porque es posible que el contador ya haya aumentado mientras tanto.