Waar ik mee zou beginnen is één aanpak kiezen voor het aanspreken van je database.
In bovenstaande code gebruik je zowel de rechtstreekse manier om queries op te bouwen (op een onveilige manier) en vervolgens gebruik je prepared statements voor het loggen van fouten (zij het op een verkeerde manier, die ook onveilig is).
Persoonlijk vind ik prepared statements in MySQLi nogal bagger. Als je daar fan van bent kun je mogelijk beter PDO gebruiken. Maar ook dan geldt dat een onjuist gebruik onveilig is.
En dan moet de code in bovenstaand fragment nodig gerefactored worden. Deze kan vele malen korter. Hebben al die errorcodes echt nut en betekenis? Ik hoop dat je niet terugkoppelt aan een gebruiker wat er precies niet goed was aan de inlog, want dit maakt het inbreken in je site makkelijker.
De uitkomt van een inlogpoging is ofwel GOED ofwel FOUT, en verder niets.
Waar ik mee zou beginnen is één aanpak kiezen voor het aanspreken van je database.
In bovenstaande code gebruik je zowel de rechtstreekse manier om queries op te bouwen (op een onveilige manier) en vervolgens gebruik je prepared statements voor het loggen van fouten (zij het op een verkeerde manier, die ook onveilig is).
Persoonlijk vind ik prepared statements in MySQLi nogal bagger. Als je daar fan van bent kun je mogelijk beter PDO gebruiken. Maar ook dan geldt dat een onjuist gebruik onveilig is.
En dan moet de code in bovenstaand fragment nodig gerefactored worden. Deze kan vele malen korter. Hebben al die errorcodes echt nut en betekenis? Ik hoop dat je niet terugkoppelt aan een gebruiker wat er precies niet goed was aan de inlog, want dit maakt het inbreken in je site makkelijker.
De uitkomt van een inlogpoging is ofwel GOED ofwel FOUT, en verder niets.
Ik koppel terug dat een invulveld leeg is, of dat een account geblokkeerd is.
Dat is het ontsluiten van informatie over de toestand van een account wat mij niet verstandig lijkt.
Je zou eerder een algemene foutmelding kunnen geven als een loginpoging strandt. Hierbij zou je niet eens onderscheid te hoeven maken of iemand iets invult of niet, maar je zou in de afhandeling dan verdere controles geheel kunnen skippen (als een gebruikersnaam of wachtwoord leeg is hoef je niets te controleren omdat dat toch nooit wat oplevert).
Je zou in de algemene foutmelding kunnen opnemen dat als een inlogpoging herhaaldelijk mislukt dat iemand kan proberen zijn/haar wachtwoord op te vragen. Vervolgens zou je dan iemand persoonlijk vervolgstappen kunnen berichten. Hierin zou je ook kunnen aangeven dat iemand zijn account is geblokkeerd en wat deze persoon vervolgens kan doen.
In dit concrete geval:
- een aanvaller weet dan dat dat een bestaand (zij het een gedeactiveerd) account betreft, waarmee deze een informatie-bestand kan opbouwen van accounts die mogelijk toegepast kan worden bij andere "ingangen" in je applicatie
- de aanvaller weet dan ook dat het op dat moment niet zinnig is om met dat account verdere loginpogingen te ondernemen
Ik zou eigenlijk alleen intern inlogpogingen bijhouden, en daarbij enkel het onderscheid maken tussen het slagen of falen hiervan en niet zozeer wat hier precies mis aan was, tenzij dit om een of andere reden heel belangrijk is. Anders is dit toch een beetje verspilde moeite.
Ik zal dan de fouten wel blijven opslaan, maar niet terugkoppelen naar de website.
Op de website maak ik dan wel een melding dat het inloggen niet gelukt is.