Daar ik met een login/ledenscript bezig ben zou ik graag extra beveiligingen toepassen tegen het brute forcen van sha1/md5
ik encrypt mijn paswoorden reeds met sha1(md5(paswoord)) maar weet dat mensen die een volledige digitale woordenboek omgezet hebben in een md5 en sha1 of beide, paswoorden van leden die niet echt goed zijn, eenvoudig zullen kunnen kraken.
Mijn oplossing tot dusver (deze is enkel voor md5 en kan hetzelde voor sha1 doen uiteraard.
kunnen jullie even controleren of onderstaand stukje code meer beveiliging bied.
Je vergeet 1 heel belangrijk gegeven, de meeste databases met md5 en zijn waarden, gebruiken alleen maar alfanumerieke strings, dus voeg een =,!,* aan je string toe. Wat ook helpt is het paswoord omdraaien.
Toch denk ik dat je al genoeg maatregelen heb getroffen, nu alleen maar maken dat er geen XSS of mysql-injections in je code zit
bedankt dolfje voor je respons, ga alvast wat vereder werken eraan, ik ben eigen lijk enkel nog op zoek naar een woordenlijst omgezet om zelf brute force toe te voegen om zo aan de bezoeker te melden of zijn paswoord veilig / onveilig of iets dergelijks is.
Weet iemand of heeft iemand zo een lijst van bvb een woordenboek omgezet in sha1 en md5?
Zo'n lijst heb je daarvoor niet nodig, je geeft enkel een score aan het paswoord a.h.v. volgende criteria:
- hoe langer het paswoord hoe beter
- Zitten er cijfers in
- Zitten er hoofdletters in
- Zitten er speciale tekens in
- zit er herhaling in
Ik heb ooit een keer een functie voor mezelf geschreven omdat ik me verveelde . Weet niet meer waar ik hem heb maar dit is een beetje het idee dat ik had.
Hashen met md5, dan sha1, dan heb je een string van 40 karakters. Die deel je door 4. Dus dan houd je 4 groepen van 8 over. Groep 1 zet je op de 3de plek, 2 op de 1ste, 3 op de laatste en 4 op de 2de. Daarna gooi je nog eens sha1 over die verwisselde string en dan zou je nog eens een keer sha1 of md5 kunnen doen want dan verklein je weer naar md5.
Maar krijgen ze nou je functie te pakken dan heb je alsnog niets
Je kan zoveel mogelijk truukjes uithalen met sha1 en md5 enzo, maar als een hacker gewoon een heel boek standaard wachtwoorden door je login script haalt. Dan heb je er allemaal niets aan.
Dus om echte Brute force tegen te gaan, moet je een beveiliging inmaken dat je bv. 5 keer per sessie mag inloggen en het 3 achtereenvolgende sessie mag proberen. Als er dan dus 15x het verkeerde wachtwoord is ingetypt (houd je bij met een cookie of je zet het IP in je database), dan ban je het ip voor bep. tijd.
Klinkt moeilijk om in elkaar te zetten maar het is gewoon sessie, cookie en database uitlezen, vergelijken en klaar. Maar dan heb je wel een degelijk beveiliging tegen bruteforce.
Een 2de plan, is om de login velden eerst 3 seconden te disablen, dit gaat enigszins tenkoste van je gebruikersvriedenlijkheid, maar je gaat dan wel tegen dat een hacker heel snel achter elkaar probeerd inteloggen (je kan deze vertraging ook intern inbouwen met behulp van PHP sleep();, dat is iets meer gebruikersvriendelijk).
klinkt niet moeilijk maar een goede oplossing enkel blijk ik soms problemen te hebben met IP adressen, stel de bezoeker surft met een random ip, dus geen fixed ip dan kan het zijn dat zijn ip al na 15 min veranderd, ik ondervind dat probleem nu ook met een leden/login script waar ik dezelfde techniek reeds gebruik om een lid te verifiëren.
Het eerste idee van ThAlmigthy is wel goed, het 2e idee is ook niets mis mee.
Maar is het niet dubbelop? want je server moet het script ook nog laden he? dus dan zou je ongeveer iets van 4 to 6 seconden moeten wachten.
Maar het is zeker een goed idee om Brute Forcing tegen te gaan
Wat ik altijd doe bij een inlogscript is het volgende:
Een gebruiker krijgt 3 kansen om goed in te loggen. Wanneer dit niet het geval is moet hij / zij op de 4e kans 5 seconden wachten. Bij de 5e 11 seconden enz enz.
Je moet een gebruiken altijd 1sec laten wachten vooraleer ze kunnen inloggen, ookal zou het paswoord goed zijn. Zo kunnen ze maximaal 86400 wachtwoorden proberen in 1 dag (ookal kunnen ze hun ip-adres veranderen enz.) Zo boet je niet in tegen gebruiksvriendelijkheid en ben jij beveiligd.
Voor 4 letters te raden (brute-forcing) heb je al 810000 pogingen nodig (als je ervan uit gaat dat je 30 verschillende tekens hebt. Het zijn er meer!) Dus als je dan kijkt op een dag tijd als er teveel inlogs zijn, of verdachte inlogs, kan je een ban proberen te maken.
Dan nog moeten ze bij die meerdere verbinding 1 seconde wachten vooraleer ze het antwoord hebben. In mijn voorbeeld moeten ze dan al 10 instanties inzetten, vooraleer ze een 4letterig paswoord kunnen raden.
Maak dan dat de gebruikers minimaal 6 letters moeten invoeren (=729000000 combinaties) en moeten ze al 8400 instanties/seconde inzetten vooraleer ze het wachtwoord kunnen raden. (ik denk die computer eerder crash dan dat je het wachtwoord hebt.)
Dus dit is een ultraveilig concept. Je moet alleen maar zorgen dat er geen andere security-exploits zijn. (plus een andere beveiliging kan niet kwaad. Beter te veel dan te weinig)
m.a.w. ze mogen nog proberen, zelfs met meerdere verbindingen is het goed concept.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
. Weet niet meer waar ik hem heb maar dit is een beetje het idee dat ik had.
Actiefste leden van de maand
