Hoe veilig is deze manier van human vertification(captcha)

Waarom al die overbodige variabelen aanmaken?
Kost alleen extra tijd en extra geheugen.

$humanctrl1 = rand(1, 9);
$humanctrl2 = rand(1, 9);
$humanctrlanswer = 0;
$humanctrlanswer += $humanctrl2;
$humanctrlanswer += $humanctrl1;
$_SESSION['humancheckansw'] = $humanctrlanswer;

$humanctrl1 = rand(1, 9);
$humanctrl2 = rand(1, 9);
$_SESSION['humancheckansw'] = $humanctrl1 + $humanctrl2;

En

$postcaptcha = $_POST["CAPTCHA"];
$humancheckfinalans = $_SESSION['humancheckansw']; 
if($postcaptcha!=$humancheckfinalans)
{                                          
    $wronganswermsg = "<strong>-</strong> There answer was not correct.<br>";
    $error = 1;
} 

if($_POST["CAPTCHA"] != $_SESSION['humancheckansw'])
{                                          
    $wronganswermsg = "<strong>-</strong> There answer was not correct.<br>";
    $error = 1;
} 

Jasper Schellekens op 28/09/2018 13:59:45

1: Tot in hoeverre is dit veilig?

Ik weet het niet hoor, maar je doet geen typecheck, en je controleert ook niet of het antwoord niet leeg is. Heb je al eens geprobeerd de sessie leeg te houden (door het uitschakelen van cookies ofzo) en het POST veld leeg te houden? Zo werken de meeste bots? Geeft de check dan niet juist het verkeerde resultaat? Oftewel: dit werkt niet in precies de gevallen waar dit wel zou moeten werken?

Jasper Schellekens op 28/09/2018 13:59:45

2: Kunnen bots toch nog door deze login heen wurmen?

Euh? Login? Hoe ziet de rest van de login er uit? Waarschijnlijk zou je een CRSF-token moeten gebruiken (werkt ook met check via sessie)? Daarnaast zou je een limiet op (foute) logins kunnen aanbrengen, om het spammen van je loginformulier tegen te gaan?

Ook moet je beveiliging meer zien als het werken in lagen. En niet in één onoverkomelijke muur die alles tegenhoudt (of zou moeten tegenhouden, want wat als dat niet gebeurt?). Je kunt er altijd langs / over of doorheen...

Dit is slechts één laag. Ik verwacht dat dit niet de enige is?

En als een mogelijke query voor inloggen / authenticatie lek zou zijn (vatbaar voor SQL-injectie of andere fratsen) dan ga je natuurlijk al/sowieso nat. Je "login" is zo sterk als de zwakste schakel.

Jasper Schellekens op 28/09/2018 13:59:45

3. Hoe kan ik dit beter doen dan hierboven.

Dat weet ik niet, wat hoop je te bereiken?

Zelfs banken gebruiken inmiddels Google reCAPTCHA dus misschien moet jij dat ook doen?

Of dat inderdaad, niet proberen je eigen wiel uit te vinden, maar gewoon standaard oplossingen gebruiken.

Ward van der Put op 28/09/2018 15:07:54

Zelfs banken gebruiken inmiddels Google reCAPTCHA dus misschien moet jij dat ook doen?

Dus we zijn compleet afhankelijk van Google...... Dat noem ik pas dom.