Question: When applying rate-limiting after failed password?

Issues & Feature Request
1

When applying a lockout after x number of unsuccessful login attempts?
Would it be advisable for:

  1. Ban x IP address (Lockout) after x unsuccessful attempts.
  2. Ban user (Lockout) after x unsuccessful attempts (doesn’t matter IP).
  3. Just Ban IP per X unsuccessful login attempts.

This refers to a current challenge available in multiple programming languages on the SecDim platform.

Thanks for your input…

2

The challenge in question does not have strict check so it is easy to build a lock out.

You can ban globally across all users (if number of failed attempt went over a certain limit, return 427), or a single user or an IP address.

In the real world, burst check should be per user per IP address.

Also search in this forum for technical analysis of Optus (no sutpo) challenge. it has some pointers.

1 Like
3

HI Pedram, I have built a lockout function but there is an issue with the security tests. I am working on Play - SecDim (energy.py).

In the security tests:

test_CWE_209_Error_message_should_not_revel_whether_username_or_password_are_incorrect():

*Case: Incorrect Password*

This sets the failed password count for Alice to 1.

def test_CWE_770_Temporary_lock_out_after_3_attempts_return_http_429_for_3s():

*Tests Alice another 3 times - 403*

*Tests for lockout for Alice - 429*

*Sleeps for 3 seconds*

*Tests Alice Again - 403*

After 2 of the initial 3 incorrect attempts, the count for Alice’s incorrect password attempts is at 3, so the account is locked out causing the security test to fail.

>       assert response.status_code == 403
E       assert 429 == 403
E        +  where 429 = <Response [429 Too Many Requests]>.status_code

test_security.py:58: AssertionError

Error received from securitytest.

m477@Coding:~/Documents/Python/Test_Functions$ /bin/python3 /home/m477/Documents/Python/Test_Functions/work.py
Request: 1 | Now: 08:10:04.206043 | Status Code: 403 | Content: b'{"message":"[e] Incorrect credentials."}'
Request: 2 | Now: 08:10:04.214249 | Status Code: 403 | Content: b'{"message":"[e] Incorrect credentials."}'
Request: 3 | Now: 08:10:04.226774 | Status Code: 403 | Content: b'{"message":"[e] Incorrect credentials."}'
Request: 4 | Now: 08:10:04.250233 | Status Code: 429 | Content: b'{"message":"[e] Too Many Requests"}'
Sleeping for 3 Seconds...
Request: 5 | Now: 08:10:07.261647 | Status Code: 403 | Content: b'{"message":"[e] Incorrect credentials."}'

Testing the lockout policy locally yields the above results, which I believe meets the definition of the 2nd security test.

Is this where the {"x-forwarded-for": "192.168.13.61"}, header comes into play?
Do I need to implement something per user per IP address? :thinking:

Sorry if this is unclear, thankyou for your time!

4

Sorry I was not right in my first response. Yes, IP matters. so lockout should be per IP. The reason we have those x-forawarded-for is to make sure each test originates from a different IP, so two tests do not have side effect on each other. This means, your lockout need to have IP check as well.

1 Like