Home / Nieuws & Blogs / Een wachtwoord + MFA: voldoende voor de beveiliging van accounts?

Een wachtwoord + MFA: voldoende voor de beveiliging van accounts?

| 21 maart 2023

Co-auteur: Information Security Consultant Mathijs Verschuur

Een wachtwoord in combinatie met MFA is tegenwoordig een veelgebruikte methode om accounts te beschermen tegen ongeautoriseerde toegang. Dat het gebruik van MFA als aanvulling op zichzelf geen voldoende beschermingsniveau biedt, blijkt wel uit recente informatiebeveiligingsincidenten zoals bij Lastpass en Uber.

Om accounts in de praktijk een passend beschermingsniveau te kunnen geven zijn er een heel aantal beleidsmatige overwegingen en technische maatregelen waarmee rekening gehouden dient te worden. In deze blog proberen we er een aantal aan te stippen, om zo organisaties te helpen de informatiebeveiliging naar een hoger niveau te tillen. 

Wat is MFA en wat is de toegevoegde waarde?

Even terug naar de basis: MFA staat voor Multi-Factor-Authentication en biedt een extra verificatiestap in het inlogproces. Naast de reguliere combinatie ‘gebruikersnaam en wachtwoord’ kan deze extra verificatiestap grofweg worden onderverdeeld in de volgende categorieën: 

  • Kennis van de gebruiker, denk aan: een wachtwoord of PIN-code
  • Bezit van de gebruiker, denk aan: een fysieke sleutel (bijvoorbeeld een Yubikey), bankpas, telefoon
  • Biometrie van de gebruiker, denk aan: een vingerafdruk, gezichtsherkenning, stemherkenning

Verder kan nog worden gedacht aan:

  • Locatie van de gebruiker
  • Gedragingen van de gebruiker

Het staat vast dat het toepassen van MFA op zichzelf een positieve invloed heeft op de beveiliging van een account. Hiermee wordt namelijk de drempel verhoogd om het account te compromitteren. Op het moment dat een aanvaller toegang probeert te krijgen tot het account is niet alleen het wachtwoord nodig, ook de MFA-verificatie dient gelijktijdig te worden uitgevoerd. 

Hoe kunnen accounts met wachtwoord + MFA alsnog succesvol worden aangevallen? 

Beide authenticatiemethoden kunnen nog altijd gecompromitteerd worden. Voor wat betreft wachtwoorden kan dit op meerdere manieren: 

1. Brute-force-attacks, waarbij geprobeerd wordt accounts te compromitteren door zo veel mogelijk pogingen te doen het wachtwoord te raden. Bij geraffineerde aanvallen wordt geprobeerd om dit op zo’n manier te doen dat bestaande beheersmaatregelen als geautomatiseerde account-lockouts niet getriggerd worden (op basis van het aantal niet geslaagde inlogpogingen in vastgesteld tijdsbestek). Een account kan kwetsbaar zijn voor een dergelijke aanval door één of een combinatie van de volgende oorzaken:

  • Zwak wachtwoordbeleid van de organisatie: de organisatie schrijft geen strengere richtlijnen voor dan de minimaal door het informatiesysteem (bijvoorbeeld: applicatie, laptop, server) gestelde vereisten, resulterend in:
  • Zwak wachtwoordbeheer van de gebruiker:
    • Sommige gebruikers gaan niet verder dan de minimale richtlijnen van de organisatie of betreffende het informatiesysteem (bijvoorbeeld 8 karakters met enige complexiteitsvereisten), resulterend in wachtwoorden met een minimale veiligheid. 
    • Het gebruik van dezelfde wachtwoorden voor verschillende accounts. Als een gebruikersaccount eenmaal is gecompromitteerd, is een ander account met hetzelfde wachtwoord een reële volgende. Zeker gezien er grootschalige handel plaats vindt in gecompromitteerde accountgegevens. 

Opmerking: haveibeenpowned.com geeft informatie over in het verleden buitgemaakte accountgegevens.

2. Social engineering aanvallen, bijvoorbeeld ‘phishing’, waarbij geprobeerd wordt het slachtoffer te manipuleren, zodat het (geheime) informatie achterlaat, bijvoorbeeld logingegevens.

3. Voorgaande gebeurt regelmatig in combinatie met een nagemaakte (gespoofde) website, in beheer van de aanvaller. De gebruiker wordt verleid om hier logininformatie achter te laten. Deze aanvalsmethode staat beter bekend als een Man-in-the-Middle aanval, waarbij een aanvaller zichzelf tussen de gebruiker en de applicatie plaatst. 

Recente nieuwsberichten laten zien dat een account voorzien van MFA alsnog gecompromitteerd kan worden. Hier volgen enkele manieren: 

1. Zwakke MFA-implementatie: het implementeren van MFA dient uiteraard zorgvuldig te gebeuren. Daarbij is het belangrijk dat MFA als niet-optioneel ingesteld staat. Indien dat wel het geval is kan een gebruiker er voor kiezen MFA uit te zetten.

2. MFA-moeheid: door een grote hoeveelheid aan MFA-validatieverzoeken in korte tijd kan een gebruiker minder scherp worden. Zo kan het voorkomen dat een gebruiker een validatieverzoek goedkeurt die geïnitieerd is door een aanvaller. In dit geval is het wachtwoord van de gebruiker al in bezit van de aanvaller. 

3. Man-in-the-middle: Ook voor MFA is een Man-in-the-middle aanval goed mogelijk. Denk aan: 

  • malware op het apparaat van de gebruiker, waarmee MFA codes onderschept kunnen worden. 
  • sessiecookies welke niet voldoende beveiligd zijn door de webapplicatie aanbieder, waardoor een 'pass-the-cookie' aanval mogelijk wordt. 

Wat te doen om aanvallen te voorkomen? 

Om bedreigingen zoveel mogelijk te voorkomen, volgt hier een stappenplan om te komen tot een robuustere accountbeveiliging voor een organisatie: 

1. Voer een risico-analyse uit 

Voor zover nog niet gedaan, voer altijd een risico-analyse uit:

  • Welke bedrijfsmiddelen (bijvoorbeeld informatiesystemen) zijn essentieel voor de organisatie?
  • Welke bedreigingen zijn reëel voor deze bedrijfsmiddelen op basis van diens kwetsbaarheden?
  • Wat is het huidige en gewenste risiconiveau?

Opmerking: Voor een volledig beeld van richtlijnen en overwegingen aangaande risicomanagement, zie: ISO 31000.

2. Stel beleid en bijbehorende actieplannen op om de risico’s te managen

Organisaties doen er goed aan het applicatielandschap nauwkeurig in kaart te brengen (met een autorisatiematrix, zie ook: Factsheet Autorisatiebeheer) en gradaties te maken in applicaties op basis van het risico die gepaard gaan met informatieverwerking. Denk hierbij aan:

  • de gevoeligheid van de informatie die wordt verwerkt; en
  • het belang van de applicatie voor de continuïteit van de dienstverlening. 

Naar aanleiding van het risiconiveau van een applicatie zou een organisatie een minimumset aan maatregelen moeten overwegen:

  • Een sterk wachtwoordbeleid (zie bijvoorbeeld de richtlijnen van Microsoft of NIST) in combinatie met beleid voor MFA & SSO (Single-Sign-On):
    • Denk na over bevoorrechte accounts (bijvoorbeeld beheeraccounts), het gevaar van een gecompromitteerd beheeraccount en de zwaarte van de te treffen beheersmaatregelen staan niet in vergelijking tot een gecompromitteerd gebruikersaccount 
    • Maak keuzes in toegestane MFA-methodiek en hoe lang sessies geldig mogen zijn (en doe dit risico-gebaseerd). Een vijfmaal daags te valideren pop-up op een telefoon voor hetzelfde account zal MFA-moeheid sneller in de hand werken dan het wekelijks handmatig invoeren van een stel random gegenereerde cijfers. Maak een weloverwogen afweging tussen gebruiksgemak versus veiligheid.
      • De steeds sterker groeiende community voor het inzetten van hardwarematige MFA-sleutels is hierin een belangrijke overweging.
    • Ook het toepassen van SSO is een belangrijke maatregel. SSO maakt het voor gebruikers mogelijk om met één set inloggegevens toegang te krijgen tot meerdere applicaties. Dit kan een groot voordeel zijn (gebruiksgemak), maar zal dus ook het aanvalsoppervlak vergroten. Vandaar dat gekeken moet worden naar het geheel aan te treffen beheersmaatregelen. 
  • Stel limitaties vast over het aantal toegestane foutieve loginpogingen voor (gevoelige) accounts.
  • Overweeg locatiespecifieke beheersmaatregelen, zoals striktere beheersmaatregelen voor het verlenen van toegang aan personen vanuit externe locaties vanuit het organisatienetwerk (IP-restricties of VPN). Al dan niet in combinatie met het toepassen van verdere netwerksegmentatie van het netwerk van de organisatie.
  • Overweeg threat detection and response oplossingen (bijvoorbeeld NDR: Network Detection and Response of EDR: Endpoint Detection and Response) om tijdig te kunnen acteren op verdacht netwerkverkeer.
  • Overweeg anti-spam oplossingen en best-practices als het gaat om mailprotocollen, zoals: SPF, DKIM, DMARC:
    • SPF (Sender Policy Framework): een methode om e-mailspoofing te voorkomen door te controleren of de verzender van een e-mailbericht namens het domein mag verzenden;
    • DKIM (Domain Keys Identified Mail): een methode om de authenticiteit van een e-mailbericht te controleren door te verifiëren of het bericht is ondertekend met een privésleutel, horend bij een publieke sleutel, die is gepubliceerd in de DNS-records van de verzendende domein;
    • DMARC (Domain-based Message Authentication, Reporting and Conformance): een methode om de implementatie van SPF en DKIM te verbeteren en de verzender van een e-mailbericht te verifiëren en te beschermen tegen spoofing en phishing.

3. Communiceer en implementeer het beleid

  • Maak gebruikers bewust van de beleidsvereisten en bijbehorende achterliggende overwegingen, inclusief de gevolgen bij niet naleving.
  • Probeer de beleidsrichtlijnen zoveel mogelijk afdwingbaar te maken, zodat er niet omheen gewerkt kan worden: 
    • MFA en wachtwoordvereisten zijn niet langer optioneel als deze voor betreffende apparatuur en applicaties verplicht gesteld worden. Ook zijn er aanvullende tools die hier aanvullend in kunnen voorzien (bijvoorbeeld: Azure Password Protection).
  • Faciliteer gebruikers in middelen om de veiligheid op een hoog niveau te krijgen/houden. Denk bijvoorbeeld aan software om sterke wachtwoorden te genereren en veilig op te slaan (bijvoorbeeld: 1password, bitwarden, etc. Let hierbij op: de ene wachtwoordmanager staat hoger aangeschreven dan de andere). 

4. Controleer regelmatig op naleving

van het beleid (risico-gebaseerd) en de effectiviteit van de bijbehorende getroffen technische beheersmaatregelen. Houd daarbij rekening met eventueel gewijzigde externe vereisten en best-practices. 

Stuur het beleid en de implementatie vervolgens tijdig bij op basis van opgedane bevindingen en bijbehorende analyses.

Benieuwd hoe ICTRecht Security u hiermee kan helpen? Neem contact met ons op!