Security concern - Implementing limited retries ? about django-rest-framework-passwordless HOT 3 OPEN

This sounds like a good idea, but I think if we do it we should use DRF's throttle policy somehow instead of building our own rate limiting mechanism.

from django-rest-framework-passwordless.

given that throttling for non-trival cases generally require some sort of shared backend (i.e. redis), you should rely on (and really, need) the underlying framework's throttling capabilities to be configured and enabled. there might be some setting at drfpasswordless level for ease of customization - but you can't just have that.

to limit retries - you may be able to get by with enabling rest_framework.throttling.AnonRateThrottle as one of the DRF DEFAULT_THROTTLE_CLASSES and setting the rate to something like 'anon' : '10/minute'. that will apply rate limiting over drfpasswordless APIs.

from django-rest-framework-passwordless.

I did some testing and yes it is possible to brute-force the 6-digit code. This should be mentioned in the README, as the configuration described there is insecure.

Using AnonRateThrottle won't work, as it looks at the X-Forwarded-For header which an attacker can spoof. A better solution is to rate-limit /auth/token based on the email address or mobile number in the request, rather than the source IP address. This can be done with django-ratelimit. This solution does create a denial-of-service vulnerability, where an attacker could lock out a valid user.

This library is also vulnerable to account enumeration. The responses from /auth/email and /auth/mobile specify whether an account exists or not which is a concern in many applications. I modified the code so that the same response was sent regardless however I found that it was still possible to enumerate accounts based on response time. Rate-limiting /auth/email and /auth/mobile helps but does not eliminate this vulnerability.

from django-rest-framework-passwordless.