Doelgroep: MBO niveau 4 – eerstejaars studenten.

Periode 2, Thema 5 voor Security, Privacy en Ethiek

Waarom dit thema voor deze doelgroep: studenten bouwen al loginfunctionaliteit in PHP en MySQL en dit is een volgende logische stap. De password hashing is een mooi onderwerp voor discussie samen met dat een admin ook maar gewoon een mens is die nieuwsgierig kan zijn naar andermans wachtwoorden, etc. Een goed moment om ze dus na te laten denken over de ethiek achter deze techniek.

Inleiding

Als softwareontwikkelaar in opleiding werk je al snel met inlogsystemen. Dit onderwerp sluit daarom goed aan bij jouw praktijk

Authenticatie en autorisatie worden vaak door elkaar gehaald, maar betekenen in de kern iets totaal anders.

Wat is inloggen? Wat is een rol?

We maken een loginformulier met PHP en MySQL en leren daarna over rechten toekennen (bijv. admin vs gebruiker).

We behandelen ook dat ongeacht hoe goed je beveiliging in elkaar steekt de mens de zwakste schakel kan zijn en hoe mensen gefopt kunnen worden om anderen per ongeluk binnen een systeem te laten.

Onderwerpen

Authenticatie: wie ben jij?
Dit is het proces waarbij een systeem vaststelt of jij bent wie je zegt dat je bent.

Autorisatie: wat mag jij?
Eenmaal ingelogd bepaalt het systeem of jij bepaalde rechten hebt. Als softwareontwikkelaar maak je dit systeem die de vergelijkingen met de database doet zelf.

Social engineering
Iemand misleiden zodat hij jou toegang geeft.

Spoofing
Jezelf technisch voordoen als iemand anders om toegang te krijgen.

Security en Privacy

Authenticatie

Waarom is authenticatie belangrijk?
Authenticatie is de manier waarop je checkt wie iemand is.
Een voorbeeld hiervan kan heel simpel: jij logt in met je gebruikersnaam en wachtwoord op een systeem zoals een website. Zie het als de portier van een club. Je zegt: “Ik ben René.” De portier zegt: “Laat je ID maar zien.” Dat ID = je wachtwoord.

Om zeker te weten dat jij echt bent wie je zegt dat je bent, moet je iets ‘bewijzen’. Dat bewijs kan op drie verschillende manieren worden geleverd:

1. Wat je hebt
   Denk aan iets dat je bij je draagt. Bijvoorbeeld:
   
   • Een sleutel
   • Een pasje (zoals een schoolpas of toegangspas)
   • Een USB-stick met beveiligingsfunctie

Dit werkt een beetje zoals bij een sleutelbos: alleen als je de juiste sleutel hebt mag je naar binnen.

2. Wat je weet
   Dit is informatie die alleen jij hoort te weten. Bijvoorbeeld:
   
   • Je wachtwoord
   • Een pincode
   • Je geboortedatum

Net als bij een kluis met een code: alleen wie de code kent krijgt toegang.

3. Wie je bent
   Dit gaat bijvoorbeeld over iets dat uniek is aan jouw lichaam. Bijvoorbeeld:
   
   • Je vingerafdruk
   • Je gezicht (Face ID)
   • Je stem of je oog (retina-scan)

Denk aan een sci-fi film waar deuren opengaan als iemand zijn oog laat scannen: dat is biometrie.

Bron: https://www.fortinet.com/resources/cyberglossary/authentication-vs-authorization

Authenticatie draait meestal om alleen een gebruikersnaam en wachtwoord. Maar alleen een wachtwoord is vaak niet veilig genoeg meer. De bovengenoemde drie vormen van bewijs kun je dan ook combineren.

Dat noemen we Multi-Factor Authenticatie (MFA).

Op je telefoon gebruik je voor school ook al MFA. Je moet bijvoorbeeld naast je gebruikersnaam en wachtwoord (iets dat je weet) ook een code invullen die je via een app zoals Microsoft Authenticator (iets dat je hebt). Zo voorkom je dat iemand met alleen jouw wachtwoord toch kan inloggen.

Het volgende filmpje legt in het kort extra uit wat MFA eigenlijk is:

Autorisatie

Waarom is autorisatie belangrijk?

Autorisatie is het proces waarbij je als gebruiker bepaalde rechten krijgt om ergens bij te mogen. Denk aan toegang tot een fysieke ruimte (zoals een serverruimte) of digitale informatie (zoals een database, applicatie of website). Veel mensen halen autorisatie en authenticatie door elkaar, maar dat is niet juist. Eerst moet een systeem weten wie je bent (authenticatie) en pas daarna bepaalt het systeem wat je mag doen (autorisatie).

Bron: https://www.fortinet.com/resources/cyberglossary/authentication-vs-authorization

Rollen en Toegang

RBAC (Role-Based Access Control)
Dit is de technische term voor het beheer van rollen. In je applicatie wil je dus niet iedereen alles kunnen laten doen. Dit doe je o.a. voor de volgende punten:

1. Voorkomen dat gebruikers bij elkaars data kunnen

Stel je voor: je logt in bij je bank, maar je zou ook het saldo van andere klanten kunnen zien. Dat mag natuurlijk niet. Daarom krijgt iedere gebruiker alleen toegang tot z’n eigen account.

2. Beschermen van betaalde functies

Sommige websites (zoals online kranten of tools als Adobe of Office 365) hebben gratis en betaalde functies. Zonder autorisatie zouden gratis gebruikers ook toegang kunnen krijgen tot de premium functies en dat zorgt voor verlies van inkomsten.

3. Scheiding tussen intern en extern gebruik

Stel je hebt een systeem waar zowel klanten als medewerkers in kunnen. Medewerkers moeten dingen kunnen aanpassen, klanten niet. Zelfs binnen het team moeten niet alle collega’s alles kunnen. Een stagiair mag bijvoorbeeld niet bij vertrouwelijke klantgegevens.

Daarom maak je meerdere soorten gebruikers aan: klanten, supportmedewerkers, admins, etc. Iedere rol krijgt eigen rechten.

Bron: https://www.fortinet.com/resources/cyberglossary/authentication-vs-authorization

Ben je een gewone gebruiker? Dan mag je alleen je eigen profiel zien. Ben je een admin? Dan mag je veel meer. In een kantoorpand heb je misschien een toegangspas. Iedereen komt binnen (authenticatie), maar niet iedereen mag in de serverruimte (autorisatie).

Zonder deze regels zou iedereen alles kunnen zien of doen en dat is onveilig.

Waarom is dit belangrijk?

• Minder risico bij fouten.
• Minder risico bij misbruik (opzettelijk of niet).
• Overzichtelijke rechtenstructuur.

Least Privilege

Als een hacker dan toch toegang krijgt tot een gebruikersaccount, maar die gebruiker heeft beperkte rechten dan valt de schade mee. Daarom is het belangrijk dat je least privilege toepast: geef gebruikers alleen wat ze echt nodig hebben.

Stel dat je een auto leent van iemand. Je krijgt de sleutel van de deur, maar niet die van het handschoenenkastje waar zijn privéspullen liggen.

Zo hoeft een helpdeskmedewerker bijvoorbeeld ook niet bij alle privédata van klanten te kunnen. Alleen bij wat de medewerker nodig heeft om z’n werk te doen is dan beschikbaar voor de rol waarmee de persoon heeft ingelogd

Praktijk

Als softwareontwikkelaar is het sowieso verstandig om te weten hoe je een inlogscherm maakt. Dit hebben we ook behandeld thema 1 – MySQL injectie, maar nu maken we een inlogformulier, waarbij de beveiliging beter is geregeld. Daarna gaan we ook nog kijken naar hoe je bijvoorbeeld zelf rollen met rechten kunt programmeren.

Hiervoor gebruik ik XAMPP en een test-database in phpMyAdmin.

We starten met het bouwen van een simpel loginformulier, waarbij wachtwoorden versleuteld worden en in de database worden gezet. Daarna maak ik een tabel voor rollen en demonstreer ik hoe een admin wel data kan verwijderen en een normale gebruiker niet.

Ik leg het allemaal uit in de volgende video:

Wachtwoorden veilig opslaan – wat is hashing?
We slaan nooit het echte wachtwoord op in de database.
We slaan alleen een versleutelde versie op; dat noemen we een hash.

Waarom?
Als je database wordt gehackt, dan kunnen aanvallers de wachtwoorden niet gewoon lezen. Een hash is een soort wachtwoord dat even door de gehaktmolen is gegaan, niet het wachtwoord zelf. Bij het inloggen gaat de invoer door dezelfde gehaktmolen en wordt er gekeken of het gehakt dat daar uit komt hetzelfde is als het gehakt dat staat opgeslagen in de database.

password_hash(): maakt een veilige hash van een wachtwoord.

password_verify(): checkt of het wachtwoord overeenkomt met de hash.

De menselijke factor

Als je een loginformulier bouwt en de beveiliging in orde hebt denk je misschien: “Zolang je alleen binnenkomt met de juiste gebruikersnaam en het juiste wachtwoord zit het goed.” Maar daar houdt beveiliging niet op. Er is namelijk nog steeds een zwakke plek die altijd zal blijven bestaan en die je moeilijk kunt tegengaan met je code: de gebruiker zelf.

Gebruikers kunnen misleid worden om zelf hun gegevens af te geven of handelingen uit te voeren die het systeem openzetten voor anderen. En hier komt social engineering om de hoek kijken.

Social Engineering

Bij social engineering probeert een aanvaller via manipulatie of misleiding toegang te krijgen tot systemen of gegevens.

Ze doen zich voor als iemand die je vertrouwd of zou moeten vertrouwen om binnen te komen.

Ze schotelen je een systeem (zoals een login op een website) voor die vertrouwd lijkt.

In beide gevallen ben je vaak geneigd om mee te werken en zo eventueel iemand binnen te laten die eigenlijk helemaal niet binnengelaten moet worden. Het is mens-eigen om anderen te willen helpen. Daarom is het belangrijk om ook beveiligingsprocedures en het beleid van je bedrijf of school aan te houden om ervoor te zorgen dat er goede stappen blijven gezet worden.

Voorbeeld:
Een kwaadwillende belt een collega op en doet zich voor als systeembeheerder om vervolgens om het wachtwoord te vragen “voor onderhoud”.

Hier is een YouTube filmpje die het ook mooi uitlegt in het Engels:

Zoals je kunt zien zijn mensen vaak bereid om anderen te willen helpen. En kwaadwillenden gebruiken juist die goedheid in anderen om binnengelaten te worden. Zij het als vertrouwd persoon of als vertrouwd systeem in spoofing.

Spoofing

In het kort nog spoofing, omdat dit een veelvoorkomende vorm is van cybercriminaliteit waarbij aanvallers zich voordoen als iets of iemand anders. Ze proberen dus als het ware je rollen-systeem te omzeilen.

Ze doen zich bijvoorbeeld voor als een bekende afzender van een e-mail, een vertrouwd telefoonnummer of zelfs een officiële website. Het doel is om mensen te misleiden, gegevens te stelen, malware te verspreiden of toegang te krijgen tot een netwerk. Deze aanvallen vinden vaak plaats en kosten wereldwijd jaarlijks honderden miljoenen euro’s.

Zoals genoemd in de video zijn verschillende vormen van spoofing die ik hieronder nog eens toelicht in het Nederlands:

Telefoonspoofing
Een aanvaller laat het lijken alsof je gebeld wordt door een vertrouwd nummer zoals je bank. Vervolgens proberen ze informatie te vragen, zoals inloggegevens of pincodes.

E-mailspoofing
Criminelen sturen e-mails die lijken te komen van een bekende afzender zoals bijvoorbeeld van een collega of leidinggevende. Vaak bevatten deze e-mails links naar nepwebsites die enorm veel lijken op een echte bekende website of bijlagen met malware.

Website- of DNS-spoofing
Een nepwebsite wordt gebouwd die bijna exact lijkt op een echte website. Vaak proberen deze sites jouw gebruikersnaam en wachtwoord te stelen.

ARP/MAC-spoofing
Binnen een netwerk doen aanvallers zich voor als een ander apparaat. Hierdoor kunnen ze data onderscheppen die voor een ander bedoeld was.

IP-spoofing
Hierbij vervalst een aanvaller zijn IP-adres, zodat het lijkt alsof het verkeer van een ander, vertrouwd systeem komt.

Waarom is dit belangrijk voor jou als ontwikkelaar?

Spoofing laat zien dat je niet alleen moet denken aan de code, maar ook aan hoe gebruikers kunnen worden misleid. Denk dus altijd aan beveiliging op meerdere lagen: techniek, rollen en last, but not least; de mens.

Ethiek

Toegang is geen toestemming

Wanneer je als developer authenticatie en autorisatie implementeer, geef je gebruikers toegang tot systemen en gegevens. Maar zodra jijzelf als developer volledige toegang hebt — bijvoorbeeld tot de database — komt de ethische kant om de hoek kijken.

Wat mag je als developer eigenlijk zien?
Alleen omdat jij technisch alles kunt zien betekent dat nog niet dat je dat ook moet willen of mag doen.

Zie je het wachtwoord van de gebruiker?
Bij goed gebruik van password_hash() en password_verify() kun je het wachtwoord niet eens achterhalen. En dat is precies de bedoeling: zelfs met toegang tot de database heb je geen recht op die kennis.

Mag je ongemerkt meekijken met gebruikersdata?
Bijvoorbeeld naar wat iemand invoert of doet in je applicatie? Als developer kun je logs aanzetten en meekijken, maar dat roept vragen op: wanneer is dat gepast en wanneer een inbreuk op privacy?

Reflectie op de menselijke factor

Mensen zijn de zwakste schakel: wat kun je als developer doen om je systeem en je gebruikers te beschermen?

Vragen die je jezelf kunt stellen bij het ontwikkelen van software:

• Mag een admin alles zien?
• Zou jij alles willen kunnen?
• Hoeveel toegang is eigenlijk verantwoord?

Eigen mening en visie

Wat wist ik al?
Voorafgaand aan dit thema had ik globaal al kennis van het verschil tussen authenticatie en autorisatie. Ik wist dat authenticatie te maken heeft met het verifiëren van iemands identiteit door bijvoorbeeld in te loggen met een gebruikersnaam en wachtwoord. Autorisatie gaat over welke rechten iemand heeft nadat hij of zij is ingelogd en welke acties zijn toegestaan op basis van de rol van de gebruiker.

Daarnaast had ik ook al gewerkt met sessies en prepared statements in PHP in onder andere eerdere lessen over beveiliging tegen SQL-injectie (zoals behandeld in thema 1). Verder had ik ook al wat basiskennis van hashing (bijvoorbeeld met password_hash en password_verify) dus dit was goed uit te leggen in dit artikel.

Wat heb ik geleerd?
Tijdens het maken van deze video en het bouwen van het voorbeeldsysteem heb ik meerdere nieuwe inzichten opgedaan:

Nuances in authenticatie en autorisatie:
Waar ik het verschil al kende heb ik nu de impact van dat verschil echt kunnen aantonen bij studenten door een praktische context te maken en te demonstreren aan deze doelgroep. Het zichtbaar maken van functionaliteiten op basis van rollen (zoals een delete-knop alleen tonen aan ingelogte admins) maakt deze normaal gesproken vrij abstracte begrippen concreet voor ze.

De menselijke factor:
Wat me vooral is bijgebleven is hoe belangrijk het is om niet alleen te denken vanuit techniek, maar ook vanuit gedrag en de ethiek die daarachter zit. Een systeem kan technisch goed dichtgetimmerd zijn, maar als gebruikers wachtwoorden hergebruiken, admin-accounts niet goed beheren of als beheerders niet goed nadenken over de stappen die ze nemen dan ontstaan er alsnog risico’s. Dit aspect heb ik goed kunnen benadrukken bij mijn eerstejaars MBO-4 studenten van software development.

Fouten als leerpunt:
Tijdens de opname maakte ik bewust ruimte om fouten en het oplossen ervan te laten zien zoals de verwarring in de kolommen van de database (‘PASSWORD’ (met hoofdletters) en ‘password’ (kleine letters). Ik merkte dat dit juist een goed leermoment is voor de kijker: studenten zien dat fouten maken normaal is en dat je leert door het te onderzoeken. Dit gaf me het inzicht dat in lessen ook fouten maken ook betekent dat je eigen leerproces zichtbaar mag zijn.

Inspiratie voor toekomstig lesmateriaal:
Door deze aanpak ben ik gemotiveerd geraakt om vaker praktijkgerichte thema’s vaker in video-vorm op te nemen in mijn onderwijs. Mijn teamleider gaf zelfs aan dat hij, ondanks dat hij geen ICT-achtergrond heeft, de video erg verhelderend vond. Dit bevestigde voor mij dat ik complexe materie begrijpelijk kan maken voor een breed publiek zoals ook aangegeven in feedback van collega’s in het verleden. In de toekomst wil ik vergelijkbare thema’s behandelen zoals 2FA, meer van social engineering en basisprincipes van encryptie. Dit heb ik al wel in de thema’s hier kunnen aanhalen, maar er kan nog meer over verteld worden in de lessen vooral met praktijk-voorbeelden en opdrachten daarbij.

Wat ga ik ermee doen?
Ik wil deze aanpak structureel integreren in mijn lesvoorbereiding. Dat betekent dat ik vaker een combinatie ga maken van theorie, demonstratie, codevoorbeelden en bewustwording rondom ethiek en dus het gedrag dat daarbij hoor. Daarnaast wil ik studenten actief laten reflecteren op hun eigen (onbewuste) handelen dat eventueel risico’s met zich mee brengt door bijvoorbeeld in de les situaties te bespreken.

Deze ervaring heeft me niet alleen iets geleerd over authenticatie en autorisatie, maar vooral over hoe ik deze kennis op een leuke en interactieve manier (kahoot en video’s) kan overbrengen en daarmee studenten kan helpen bewuster en veiliger met systemen om te gaan.

Bronnen

Techquickie. (2018, 18 juni). How does Multifactor Authentication work? | MFA and privacy explained [Video]. YouTube. Geraadpleegd op 30 maart 2025, van https://www.youtube.com/watch?v=lEHhivPJQ5w

Computerphile. (2015, 4 augustus). What is Social Engineering? [Video]. YouTube. Geraadpleegd op 30 maart 2025, van https://www.youtube.com/watch?v=Vo1urF6S4u0

ProtonMail. (2020, 8 april). What is Email Spoofing? Spoofing Email Explained [Video]. YouTube. Geraadpleegd op 30 maart 2025, van https://www.youtube.com/watch?v=qdp_ormFCu8

IBM Technology. (2022, 14 juli). What Are Spoofing Attacks? [Video]. YouTube. Geraadpleegd op 30 maart 2025, van https://www.youtube.com/watch?v=uo53e8PkYqc

Fortinet. (z.d.). What is Authentication? Geraadpleegd op 31 maart 2025, van https://www.fortinet.com/resources/cyberglossary/authentication-vs-authorization