Vorige week gaven we het startsein voor een blogreeks van 10 weken waarin we de OWASP top 10 security risico’s behandelen. Maar in tegenstelling tot menig ander artikel of blog, doen wij het in simpele taal en hapklare brokken. Op die manier hoeft u niet onnodig veel te lezen en kunt het ook af zonder woordenboek. Wel zo fijn natuurlijk. Vorige week hebben we u uitgelegd wat een SQL-injectie is, en aan de cijfers te zien vond u dit een interessant stukje tekst. Laten we hopen dat het onderwerp van deze week u net zo kan bekoren. De nummer 2 op de lijst van de OWASP top 10 is namelijk Broken Authentication. Deze week beantwoorden wij dus de vraag wat is Broken Authentication?
Wanneer u deze term door de vertaler van Google haalt dan rolt er ‘gebroken authenticatie’ uit. En ondanks dat dit een beetje een vage uiting is, klopt het wel. Het zou overigens ook goed kunnen dat u deze overkoepelende term niet eerder heeft gehoord, deze wordt niet veel gebruikt in het nieuws. Maar toch zien we het regelmatig voorbij komen op de diverse media? Dat klopt! Maar dan in de vorm van: Microsoft biedt excuses aan voor datalek waarbij miljoen accounts gehackt werden. Wanneer u dit leest kunt u er eigenlijk wel vanuit gaan dat Broken Authentication er iets mee te maken heeft. Echter is een datalek vaak meer het gevolg dan een oorzaak.
Het werkt een stuk simpeler dan de term doet vermoeden. Bij een inlogpoging volgt elke gebruiker namelijk drie stappen. Te weten:
1. Identification: “Wie ben je?” – uw gebruikersnaam
2. Authentication: “Ben je wie je zegt dat je bent? – uw wachtwoord
3. Authorization – “Wat mag je?” – uw rechten
Zoals u mogelijk al zult vermoeden doet Broken Authentication zich voor in de tweede stap. Een aanvaller doet zich voor als een andere gebruiker aan de hand van verkregen credentials. Hoe deze verkregen zijn laten we in het midden. Maar hierbij kunt u bijvoorbeeld denken aan een eerder datalek waarbij gegevens zijn gelekt of wanneer de aanvaller een Brute Force aanval uitvoert en het systeem als het ware ‘dwingt’ gegevens te overhandigen.
Iedere applicatie is kwetsbaar voor deze vorm van aanvallen. Er hoeft maar één persoon zijn of haar gegevens te verliezen en een kwaadwillende heeft toegang tot de applicatie. En zelfs als niemand deze verliest, kan het alsnog worden gekraakt. Wat de gevolgen hiervan zijn is compleet afhankelijk van de applicatie waar het om gaat. De kans op het stelen van identiteit is wel heel erg groot en als dit gestolen account ook nog de nodige rechten heeft, kan er veel waardevolle data buit worden gemaakt. Dit zou in theorie niet snel moeten gebeuren omdat de meeste normale gebruikers maar weinig rechten nodig hebben. Maar je kunt natuurlijk pech hebben. Een ander aspect dat meespeelt is dat bedrijven vaak te weinig aandacht besteden welke gebruiker welke rechten heeft. En hoe meer accounts met teveel rechten, des te groter dat de schade bij Broken Authentication groter is.
Wil je liever niet dat gelijk alles op straat ligt wanneer de stagiair een keertje een briefje met haar inloggegevens verliest? Dan is het van belang om als bedrijf eens goed na te denken over het zogenaamde Identity and Access Management‘. Lang verhaal kort is dat het beleid dat je als bedrijf hanteert waarin staat uitgeschreven wie tot wat toegang moet hebben. De secretaresse heeft dus bijvoorbeeld geen toegang tot je Active Directory nodig. Een andere manier om dit te stoppen is het toekennen van gebruikerstaken. Dit wel zeggen dat wanneer ik een verandering wil toepassen, een ander dit moet goedkeuren. Dat maakt het leven van een hacker weer wat lastiger.
Een andere, veel voorkomende, oplossing is 2FA, ofwel Multi-factor Authentication (Two Factor Authentication). Dit verplicht de gebruiker om op minimaal twee verschillende manieren het systeem te vertellen dat deze persoon wel degelijk de juiste gebruiker is. Dit gebeurt bijvoorbeeld aan de hand van een sms met een code die naar de telefoon van de gebruiker wordt verzonden. Wil je voorkomen dat mensen November2020 als wachtwoord gebruiken? Stel dan een weak-password check in. Deze controleert aan de hand van een lijst met de 10.000 zwakste wachtwoorden of het gekozen wachtwoord daar niet in staat. Tot slot is het een goed idee om het aantal toegestane inlogpogingen te beperken. Zo kan een hacker niet ongelimiteerd zijn of haar gang gaan.
Zou u wel eens willen weten hoe het staat met de wachtwoorden binnen uw organisatie? Rootsec kan dit voor u controleren aan de hand van de zogenaamde ‘wachtwoordhygiëne-check‘. Onze supercomputer gaat dan, met uw toestemming, kijken hoe lang het duurt om de wachtwoorden van uw medewerkers te kraken. Ervaring leert dat we hier (helaas) niet heel lang voor nodig hebben.. Neem dus vooral contact op als u hierover twijfelt.