Broken Authentication

Door Lucas Dresscher

Wat is het en waar komt het voor?

In dit tweede artikel van mijn serie over de “OWASP Top 10 Application Security Risks – 2017” lijst behandel ik de kwetsbaarheid Broken Authentication. Misschien herkent niet iedereen direct deze officiële term, maar wel zeer herkenbaar is de zoveelste krantenkop waarin staat “Miljoenen accounts gehackt door datalek”. Broken authentication heeft hier veelal mee te maken.

Broken authentication kan de oorzaak zijn van zo'n krantenkop, maar vaker is het een gevolg. Vrijwel alle applicaties volgen namelijk voor inlog processen en dergelijke het volgende drie stappen principe:

1. Identification: “Wie ben je?” - dit is vaak de gebruikersnaam.
2. Authentication: “Ben je wie je zegt dat je bent? - dit is vaak het wachtwoord.
3. Authorization - “Wat mag je?” - dit zijn de rechten die deze gebruiker heeft.

Zoals de naam Broken Authentication doet vermoeden, doet het zich voor in de tweede stap. Een aanvaller gebruikt verkregen credentials om zich voor te doen als een bepaalde gebruiker om op deze manier diens rechten te krijgen. De aanvaller kan aan deze gegevens gekomen zijn door bijvoorbeeld eerdere datalekken, maar ook door zelf een Brute Force Attack (BFA)/Dictionary Attack of een ietwat geavanceerdere Rainbow Table Attack uit te voeren.

Wat kunnen de gevolgen zijn?

Bij een applicatie die kwetsbaar is voor Broken Authentication is het risico op identity theft zeer groot. Tevens kan er andere (bedrijfs)gevoelige gegevens geopenbaard worden. Dit zou niet moeten gebeuren, aangezien de meeste accounts die gehackt worden van gewone gebruikers zijn. Deze groep hoort in theorie zo weinig mogelijke rechten te hebben. Echter, de praktijk leert dat - veelal uit gemakzucht - dergelijke groepen veel meer rechten hebben dan nodig is. Hierdoor kan zelfs een matige hacker met het kraken van een simpel account al ver komen, laat staan een gevorderde hacker. Onder het volgende kopje “Hoe beveilig je je er tegen?” behandel ik dit probleem verder.

Hoe beveilig je je er tegen?

Om te voorkomen dat je direct in gevaar bent als de secretaresse op een phishing mail geklikt heeft, is het van belang dat je als bedrijf goed nagedacht hebt over Identity and Access management (IAM). Dit is gebaseerd op de volgende drie principes: (1) need to know basis, (2) least privilege en (3) segregation of duties. Ofwel, ga voor elke gebruikersrol precies na welke rechten nodig zijn en stel het systeem vervolgens zo in – en niet meer. Zorg er daarnaast voor dat gebruikerstaken gescheiden zijn; iemand die een aanpassing kan voorstellen, moet deze niet zelf kunnen goedkeuren.

Hieronder geef ik een korte lijst met do’s en don’ts om Broken Authentication tegen te gaan.

DO'S

  • Multi-factor authentication: hiermee laat je de gebruiker met twee of meerdere verschillende manieren authenticeren, in plaats met alleen een wachtwoord. Een veelgebruikte implementatie is een combinatie van een wachtwoord en een code verkregen via SMS of via een authenticator app zoals Google Authenticator.

  • Bouw een weak-password check in, die controleert of een gebruiker geen wachtwoord uit de lijst met met 1000 of 10000 slechtste wachtwoorden (uit gemak) wilt instellen.

  • Beperk het aantal inlogpogingen die iemand kan doen en log alle mislukte inlogpogingen.


DON'TS

  • Gebruik geen default credentials. Oftewel, stel geen standaard gebruikersnamen, wachtwoorden of andere accountgegevens in. Denk aan standaardgebruikersnamen admin of gebruiker1 en standaardwachtwoorden als password of wachtwoord.

  • Leg de gebruiker buiten de weak-password checker en een standaard minimumlengte van in ieder geval 8 tekens niet teveel restricties op tijdens het instellen van hun gebruikersgegevens. In tegenstelling tot wat sommige bedrijven nog steeds denken, is onderzocht dat verplichtingen als speciale tekens en hoofdletters of het verplicht periodiek aanpassen van je wachtwoord juist averechts werkt.


Vooruitblik

In het volgende artikel zal ik een kwetsbaarheid behandelen die velen verwarren met degene die ik hier heb besproken: Sensitive Data Exposure. Sensitive Data Exposure heeft zeker overeenkomsten met Broken Authentication, maar is op meerdere vlakken toch fundamenteel anders. Waarin zit dit verschil? Kun je je als bedrijf met enkele hier besproken preventiemaatregelen ook direct tegen deze kwetsbaarheid beveiligen? En welke rol speelt encryptie hierin? Lees het in het derde artikel van mijn Cybersecurity reeks.