Ik kan niet goed rekenen, maar misschien iemand anders hier op het forum wel. Ik ben erg benieuwd hoeveel combinaties er mogelijk zijn van een gebruikersnaam en wachtwoord met dezelfde lengte, en hoelang een computer er over zou doen om alle combinaties te berekenen. Ik ben benieuwd hoe dat zit als je alleen letters en cijfers mag gebruiken... en wanneer je alle tekens mag gebruiken. Ik zet hier een schemaatje neer en ben benieuwd of iemand er iets van kan invullen. Wie durft? :-)

gebruikersnaam en wachtwoord zijn allebei 4 tekens, alleen letters en cijfers
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:

gebruikersnaam en wachtwoord zijn allebei 6 tekens, alleen letters en cijfers
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:

gebruikersnaam en wachtwoord zijn allebei 8 tekens, alleen letters en cijfers
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:

gebruikersnaam en wachtwoord zijn allebei 4 tekens, alle tekens
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:

gebruikersnaam en wachtwoord zijn allebei 6 tekens, alle tekens
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:

gebruikersnaam en wachtwoord zijn allebei 8 tekens, alle tekens
aantal mogelijke combinaties:
computer tijdsduur om alle combinaties te berekenen:
@Ozzie

Een botnet is een netwerk van computers die geïnfecteerd zijn. De hacker/hackersgroep kan met deze computers aanvallen uitvoeren zonder dat de gebruiker er zelf bewust van is. Het voordeel is, voor de hacker(s) dan, is dat het lastiger te traceren is van waar de aanval precies komt.

I.v.m. dat brute-force, moet je een beetje keuzes maken. Wanneer je zoiets op een forum toepast, mag je script niet te streng zijn. Anderzijds is het ook zo dat een strenge brute force een hogere serverload veroorzaakt.

Een IP-ban is een mogelijkheid, maar is vaak onvoldoende. Een groep hackers zal beschikken over voldoende IP's. Dit door bijvoorbeeld een botnet of door gewoonweg IP-adressen te spoofen ('te stelen'). Het nadeel is dan dat je servers enorm veel queries gaat liggen uitvoeren en waardoor je site wel is uit de lucht zou kunnen gaan.

Wat je bijvoorbeeld kan doen is inderdaad na 3 pogingen een IP-ban geven die geldig is gedurende 5 minuten. Wat je dan nog bijkomend kan doen, is een account (op gebruikersnaam) blokkeren indien die bijvoorbeeld in 12h 100 keer verkeerd is ingelogd. Ik denk dat de gebruiker liever een melding ziet in de aard van: "Je account is tijdelijk uitgeschakeld. Gelieve contact op te nemen met de beheerder." dan dat zijn account is gehacked.

Er zijn uiteraard nog tal van mogelijkheden. De kunst is een middenweg te vinden tussen veiligheid en gebruiksgemak.
Oké, thanks. Wat bedoel je hiermee: "Anderzijds is het ook zo dat een strenge brute force een hogere serverload veroorzaakt."? Waarom krijg je een hogere serverload?

"Wat je bijvoorbeeld kan doen is inderdaad na 3 pogingen een IP-ban geven die geldig is gedurende 5 minuten." Stel dat je zeker weet dat het om een hackpoging gaat, bijvoorbeeld omdat een bepaalde (hidden field) code niet is meegestuurd in het formulier, is het dan een goed plan om dat IP voor altijd uit te schakelen?
"Het nadeel is dan dat je servers enorm veel queries gaat liggen uitvoeren en waardoor je site wel is uit de lucht zou kunnen gaan."

Verder zou je inderdaad kunnen bannen als je zeker bent. Maar weet ook, als een hacker het echt op je gemunt heeft, dan zou hij wil is in je broncode kunnen gaan kijken naar zo'n hidden field. Dat zou hij dan ook gewoonweg kunnen faken. Ik vraag me af of je kan nakijken of iets bepaald via jouw eigen site is gepost, vast wel. (via IP?) Dan zou je dat ook kunnen dichttimmeren.
Volgens mij kan dat niet via IP toch?

Ik dacht zelf zoiets als bij iedere pagina-aanroep een geheime code genereren en in sessie zetten. En dan als een formulier gepost wordt vanaf mijn site, dan zet ik die geheime code als hidden field erin. Als de waardes gelijk zijn dan komt het van mijn eigen site. Ik weet alleen niet zeker of dit werkt eigenlijk. Kan iemand vanaf een andere server mijn site oproepen... en als hij m dan nogmaals oproept, zit ie dan nog steeds in dezelfde sessie? Zo ja, dan kan hij bij de 1e pagina-aanroep de geheime code uit de paginabrom halen. Maar ik weet dus niet of ie de sessie onthoudt.
Ik dacht van wel, al ben ik niet zeker. Maar het is in elk geval een goed idee om een hash in de sessie te plaatsen. (Bijvoorbeeld: sha1($username.'nQp&q74'.md5($password).'aB*M\'') ) Wat je sessies op zich ook veiliger maakt, is ze opslaan in de database of desnoods in een txt-bestand. Uiteraard dan wel voor zorgen dat de bezoeker niet bij die txt'en kan. Dit kan met je eigen session handler, kijk eensn aar set_session_handler().

Wat je in elk geval ook kan doen is de referrer checken, wat het ook weer -iets- lastiger maakt, want ook die is te faken.

Maar ik denk als je gewoon zorgt dat wachtwoorden op zijn minst veilig zijn, de input goed controleert, reffer, je sessie op orde hebben (geen wachtwoorden / rechten meegeven), een middel-strenge brute-force filter, mooie queries.... je meer dan safe zit.
OKé, thanks vooor de tips!!
Geen probleem ;-)
@Ozzie: Algemeen in het hele leven: De grootste angst is de angst voor de angst. Jij hebt zo ontzettend veel vragen over dingen die jij waarschijnlijk, als je standaard beveiliging inbouwt, nooit nodig hebt.
Haha... ik heb nooit een IT opleiding gehad SanThe, en daarom wil het zo goed mogelijk doen... maar daarnaast vind ik het ook erg leuk om dit soort dingen te weten... gewoon om ze te weten :-)
Ozzie PHP op 20/08/2011 10:23:08

en daarom wil het zo goed mogelijk doen...


Goed zo, de meeste phpers denken: het werkt, dus zal het wel goed zijn

Reageren