Researching brute force logins

Hi @Kenyuri !

In a recent call, you and I were discussing CHT’s resilience to brute force attacks. With our work in #6530 (which you helped out with!!) CHT 4.6 and later now offers some basic protection against brute force login attempts.

I believe you’d suggested a finding that after many hundreds of attempts that the login would succeed. Could you provide more details?

In my research, I’m unable to reproduce these results. To test, I set up an instance of the CHT In docker helper running CHT 4.17 and then ran this code:

#!/bin/bash

set -e

results1=''
for i in `seq 1 1500`;do
    randPass=$(uuidgen)
    dataRaw1="{\"user\":\"medic\",\"password\":\"${randPass}\"}"
    response1=$(curl -s -o /dev/null -w "%{http_code}\n"  -X POST -H "Content-Type: application/json"  https://medic:password@192-168-68-23.local-ip.medicmobile.org:10443/medic/login --data-raw $dataRaw1)
    results1+="$response1"$'\n'
done

echo "CHT Login"
echo "$results1" | awk 'NF'| sort | uniq -c

echo;echo "Sleeping 60s...";echo
sleep 60

results2=''
for i in `seq 1 1500`;do
    randPass=$(uuidgen)
    dataRaw2="{\"name\":\"medic\",\"password\":\"${randPass}\",\"locale\":\"en\"}"
    response2=$(curl -s -o /dev/null -w "%{http_code}\n" 'https://medic:password@192-168-68-23.local-ip.medicmobile.org:10443/_session' -X POST  -H 'Content-Type: application/json'  --data-raw $dataRaw2)
    results2+="$response2"$'\n'
done

echo "_session login"
echo "$results2" | awk 'NF'| sort | uniq -c

The results look like this where 401 is failed, 429 is too many login attemtps and 302 is a redirect to the login page:

$ ./brute-force.sh
CHT Login
     35 401
   1465 429

Sleeping 60s...

_session login
   1500 302
2 Likes