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