Belastingdienst verscherpt eisen voor DigiD-wachtwoord
De Belastingdienst heeft vanaf vandaag de eisen voor DigiD-wachtwoorden verscherpt, waardoor gebruikers met een onveilig wachtwoord een nieuw wachtwoord zullen moeten aanmaken. Gebruikers krijgen in dit geval tijdens het inloggen het verzoek om een nieuw, sterker wachtwoord op te geven.
Na de wijziging van het wachtwoord worden gebruikers vervolgens ingelogd, zo laat de Belastingdienst vandaag op de eigen website weten. De verscherping van de eisen voor DigiD-wachtwoorden zijn onderdeel van maatregelen die in maart door minister Plasterk van Binnenlandse Zaken en Koninkrijksrelaties werden aangekondigd.
Vanwege verschillende fraudes met DigiD werd besloten om de activeringscodes per koerier te laten bezorgen. Naast de maatregelen voor deze risicogebieden zette de minister ook beleid in om de wachtwoorden van DigiD te versterken. Sinds 1 januari 2014 is dat gebeurd voor nieuwe gebruikers en vanaf vandaag wordt dat beleid ook voor bestaande gebruikers ingevoerd.
Reacties (26)
Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
20-05-2014, 12:03 door
Fwiffo
Wel handig om te weten wat die eisen dan zijn. Kon wat tips vinden op de site van digid maar mij is niet duidelijk of een wachtwoord als 'correct horse battery staple' toegestaan is. Lengte wordt aangeraden, maar misschien gaat de site klagen over het ontbreken van hoofdletters, cijfers en vreemde tekens (of kan het niet omgaan met spaties).
Het grootste probleem met digid blijft natuurlijk dat je die niet zo vaak nodig hebt, dus dat je gegarandeerd als je weer aangifte moet doen je sterke wachtwoord bent vergeten. Opschrijven mag natuurlijk niet. En hergebruiken al helemaal niet (en terecht)!
Het grootste probleem met digid blijft natuurlijk dat je die niet zo vaak nodig hebt, dus dat je gegarandeerd als je weer aangifte moet doen je sterke wachtwoord bent vergeten. Opschrijven mag natuurlijk niet. En hergebruiken al helemaal niet (en terecht)!
20-05-2014, 12:20 door
Fwiffo
Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Ze laten je ermee inloggen en dwingen je daarna die te veranderen als het niet aan hun 'geheime' eisen voldoet. Ander alternatief is een brute force en word lists op hun eigen database. Dat heeft tweakers.net ook een paar jaar geleden gedaan op al haar users.Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Het punt is dat onveilige wachtwoorden te makkelijk gebruteforced kunnen worden, met een brute force op de eigen database kom je er dus ook zo achter WELKE wachtwoorden onveilig zijn.Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
als je het aantal inlogpogingen enigszins limiteert is het brute forcen niet eens zo'n groot probleem. Je moet natuurlijk geen wachtwoord als 'geheim' of '12345' hebben maar er ligt te veel focus op sterke wachtwoorden, en te weinig op mitigatie van andere aanvallen, wat mij betreft. Daarbij komt dat de meeste eisen juist averechts werken; je verkleint de search space en je forceert veel gebruikers hun wachtwoord op te schrijven
20-05-2014, 12:49 door
linuxpro
Zou mij niet verbazen als die wachtwoord inderdaad plain-text in de database staan...
de slogan van de belastingdienst is toch "leuker kunnen we het niet maken , maar wel makkelijker !!! en daar zit nu het probleem ,, WEL MAKKELIJKER !!!!!! " whahahahahahha !!!!!!!
Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Denk dat ze hier naar kijken op het moment dat je bij het inloggen je wachtwoord invoert, zoals Fwiffo ook al aangaf. Anders zouden ze iedereen met een onveilig wachtwoord wel meteen een mailtje sturen.
20-05-2014, 13:12 door
Briolet
Door Anoniem:Het punt is dat onveilige wachtwoorden te makkelijk gebruteforced kunnen worden, met een brute force op de eigen database kom je er dus ook zo achter WELKE wachtwoorden onveilig zijn.
De vraag is echter of dat legaal is. Als 'klant' vertrouw je erop dat je wachtwoorden veilig opgeslagen worden. Als de site dan jouw wachtwoorden gaat kraken, lijkt het me dat ze illegaal bezig zijn, hoe legitiem de bedoeling ook is.
Een mooie juridische vraag voor Arnoud Engelfriet: Mag een site wachtwoorden van klanten gaan kraken?
(Of is die vraag al eens gesteld)
Hier krijg ik echter de indruk dat je pas bij inloggen gewaarschuwd wordt, en dat kraken dus niet gebeurd.
Door Briolet:
De vraag is echter of dat legaal is. Als 'klant' vertrouw je erop dat je wachtwoorden veilig opgeslagen worden. Als de site dan jouw wachtwoorden gaat kraken, lijkt het me dat ze illegaal bezig zijn, hoe legitiem de bedoeling ook is.
Een mooie juridische vraag voor Arnoud Engelfriet: Mag een site wachtwoorden van klanten gaan kraken?
(Of is die vraag al eens gesteld)
Hier krijg ik echter de indruk dat je pas bij inloggen gewaarschuwd wordt, en dat kraken dus niet gebeurd.
Ik weet niet of er juridisch verschil in zit, maar je kan natuurlijk een lijst van onveilige wachtwoorden opstellen en de hashes berekenen, deze hashes sla je op (zonder koppeling naar het achterliggende wachtwoord toe).Door Anoniem:Het punt is dat onveilige wachtwoorden te makkelijk gebruteforced kunnen worden, met een brute force op de eigen database kom je er dus ook zo achter WELKE wachtwoorden onveilig zijn.
De vraag is echter of dat legaal is. Als 'klant' vertrouw je erop dat je wachtwoorden veilig opgeslagen worden. Als de site dan jouw wachtwoorden gaat kraken, lijkt het me dat ze illegaal bezig zijn, hoe legitiem de bedoeling ook is.
Een mooie juridische vraag voor Arnoud Engelfriet: Mag een site wachtwoorden van klanten gaan kraken?
(Of is die vraag al eens gesteld)
Hier krijg ik echter de indruk dat je pas bij inloggen gewaarschuwd wordt, en dat kraken dus niet gebeurd.
Als je vervolgens gaat zoeken naar deze wachtwoord hash, weet je enkel dat het wachtwoord op de lijst van niet veilige wachtwoorden staat, zonder te weten wélk wachtwoord het is.
20-05-2014, 13:37 door
[Account Verwijderd]
[Verwijderd]
20-05-2014, 13:48 door
maboc
Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Je zou toch met bv. Java Script in de browser kunnen cheken of er hoofd-/kleineletters, nummerieke-/alphanummeriekecharacters. etc etc. in het WW zit?Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.
(Of is dit te kort door de bocht?)
Door linuxpro: Zou mij niet verbazen als die wachtwoord inderdaad plain-text in de database staan...
Waarom?Door maboc:
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.
(Of is dit te kort door de bocht?)
SSL/TLS versleutelt de data alleen tijdens het transport. Op de webserver is gewoon de plaintext data beschikbaar. Daar is wel tot op zekere hoogte een mouw aan te passen middels challenge response oplossing via javascript:Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Je zou toch met bv. Java Script in de browser kunnen cheken of er hoofd-/kleineletters, nummerieke-/alphanummeriekecharacters. etc etc. in het WW zit?Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.
(Of is dit te kort door de bocht?)
Server stuurt een verse random string als challenge
Gebruiker typt password in
Client (javascript in browser) berekent hash(hash(password)+challenge) en stuurt dat terug. Ook al wordt dit antwoord onderschept, het kan niet worden hergebruikt.
Server pakt passwordhash uit de DB en berekent ook hash(passwordhash+challenge) en vergelijkt dat met wat de client als antwoord gaf.
(dit is een versimpelde weergave, in werkelijkheid zitten dit soort mechanismes wat ingewikkelder in elkaar, bijvoorbeeld om ook salts te kunnen gebruiken).
Maar in elk geval bij het instellen van het wachtwoord zal dat doorgaans plaintext richting server gaan (via een beveiligde ssl/tls verbinding hopelijk) alwaar het dan gehasht (hopelijk incl. salt) en opgeslagen wordt.
De check of een wachtwoord aan de eisen voldoet zal inderdaad naar ik mag aannemen gewoon plaatsvinden op het moment dat iemand probeert in te loggen. Overhaaste conclusies trekken levert natuurlijk lekker smeuïge reacties op, maar slaan zonder onderbouwing werkelijk als een tang op een varken.
Het gaat om de wachtwoorden die bij DigiD zijn opgeslagen, niet bij de belastingdienst. De belastingdienst heeft de eisen ook niet verscherpt, maar DigiD in opdracht van de minister.
Ik moest mijn wachtwoord inderdaad wijzigen, eisen zijn: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 leesteken en 8 karakters (max 32). (er verschijnt een popup met deze informative als je je nieuwe wachtwoord in wil vullen.
Ik moest mijn wachtwoord inderdaad wijzigen, eisen zijn: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 leesteken en 8 karakters (max 32). (er verschijnt een popup met deze informative als je je nieuwe wachtwoord in wil vullen.
Door Anoniem:Ik weet niet of er juridisch verschil in zit, maar je kan natuurlijk een lijst van onveilige wachtwoorden opstellen en de hashes berekenen, deze hashes sla je op (zonder koppeling naar het achterliggende wachtwoord toe).
Als je vervolgens gaat zoeken naar deze wachtwoord hash, weet je enkel dat het wachtwoord op de lijst van niet veilige wachtwoorden staat, zonder te weten wélk wachtwoord het is.
Het ging hier om een brute force op de eigen wachtwoordendatabase. Jouw methode werkt dan alleen als je geen SALT gebruikt in je wachtwoord-hashes. Dat maakt je gevoelig voor aanvallen met een rainbow-table (de tabel met hashes die je zelf voorstelt maar dan met de wachtwoorden). Als je naast de gewone wachtwoordcontrole bij aanloggen deze hash wilt berekenen en tegen die tabel aanhouden dan kan je natuurlijk net zo goed het wachtwoord zelf op voldoende kwaliteit controleren en heb je die tabel niet nodig. En da's vermoedelijk precies wat ze bij Digid nu doen.Als je vervolgens gaat zoeken naar deze wachtwoord hash, weet je enkel dat het wachtwoord op de lijst van niet veilige wachtwoorden staat, zonder te weten wélk wachtwoord het is.
Daar gaat de belastingsdienst helemaal niet over, zij nemen de DigiD dienst af.
Logius gaat daarover, dus BZK. Dus het is zijn minst een vreemd bericht.
Logius gaat daarover, dus BZK. Dus het is zijn minst een vreemd bericht.
Op basis van de situatie zoals die reeds voor de invoering van DigiD bij de Belastingdienst bestond kan ik het volgende melden:
De interne regels, die deels in hard- en software zijn geïmplementeerd, verbieden een brute force op de passwords.
De passwords zijn niet plaintext beschikbaar, ook niet voor beheerders.
De interne regels, die deels in hard- en software zijn geïmplementeerd, verbieden een brute force op de passwords.
De passwords zijn niet plaintext beschikbaar, ook niet voor beheerders.
20-05-2014, 16:05 door
Briolet
Door Anoniem: Daar gaat de belastingsdienst helemaal niet over, zij nemen de DigiD dienst af.
Daar had ik overheen gelezen, maar dat klopt natuurlijk. Het zou vreemd zijn, dat als je via een gemeente inlogt, nog wel je minder veilige wachtwoorden mag gebruiken. De belastingsite vermeld slechts dat de eisen zijn aangescherpt. Oftewel, de titel van dit artikel klopt niet.
Je zou toch met bv. Java Script in de browser kunnen checken of er hoofd-/kleineletters, nummerieke-/alphanummeriekecharacters. etc etc. in het WW zit?
Moet heel makkelijk kunnen. Alleen zie ik op de inlogpagina maar één JS script actief en daar staat een datum van juli 2013 in de comment. Dus blijkbaar zit daar geen aanpassing in.
20-05-2014, 16:24 door
maboc
Door Orion84:
Crap...dat weet ik zelf eigenlijk ook wel...te gemakkelijk gereageerd. Maar inderdaad...zonder verdere maatrelen heeft de ontvanger de beschiking over de (plain)text die is opgestuurd.Door maboc:
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.
(Of is dit te kort door de bocht?)
SSL/TLS versleutelt de data alleen tijdens het transport. Op de webserver is gewoon de plaintext data beschikbaar. Door Anoniem: Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Je zou toch met bv. Java Script in de browser kunnen cheken of er hoofd-/kleineletters, nummerieke-/alphanummeriekecharacters. etc etc. in het WW zit?Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.
(Of is dit te kort door de bocht?)
Daar is wel tot op zekere hoogte een mouw aan te passen middels challenge response oplossing via javascript:
Server stuurt een verse random string als challenge
Gebruiker typt password in
Client (javascript in browser) berekent hash(hash(password)+challenge) en stuurt dat terug. Ook al wordt dit antwoord onderschept, het kan niet worden hergebruikt.
Server pakt passwordhash uit de DB en berekent ook hash(passwordhash+challenge) en vergelijkt dat met wat de client als antwoord gaf.
(dit is een versimpelde weergave, in werkelijkheid zitten dit soort mechanismes wat ingewikkelder in elkaar, bijvoorbeeld om ook salts te kunnen gebruiken).
Ben benieuwd of ze een dergelijk mechanisme toepassen.Server stuurt een verse random string als challenge
Gebruiker typt password in
Client (javascript in browser) berekent hash(hash(password)+challenge) en stuurt dat terug. Ook al wordt dit antwoord onderschept, het kan niet worden hergebruikt.
Server pakt passwordhash uit de DB en berekent ook hash(passwordhash+challenge) en vergelijkt dat met wat de client als antwoord gaf.
(dit is een versimpelde weergave, in werkelijkheid zitten dit soort mechanismes wat ingewikkelder in elkaar, bijvoorbeeld om ook salts te kunnen gebruiken).
Maar in elk geval bij het instellen van het wachtwoord zal dat doorgaans plaintext richting server gaan (via een beveiligde ssl/tls verbinding hopelijk) alwaar het dan gehasht (hopelijk incl. salt) en opgeslagen wordt.
Plaintext als voor de ontvanger bedoel je? Voor luisternde boefjes op de lijjn is eea. encrypt.De check of een wachtwoord aan de eisen voldoet zal inderdaad naar ik mag aannemen gewoon plaatsvinden op het moment dat iemand probeert in te loggen.
Overhaaste conclusies trekken levert natuurlijk lekker smeuïge reacties op, maar slaan zonder onderbouwing werkelijk als een tang op een varken.
Uh... slaat dit op mijn reactie, of is het in 't algemeen?Als jje bij de belastingdienst tijdens een sollicitatie met sluitende argumenten aangeeft dat DiGiD niet deugt.....
CEH, CISSP. (zegt niets, niet aan de overheid vertellen....)
Ik betaal liever nog meer belasting voor betere kwaliteit.
Al is de belastingdienst dan nog een zwak lampje vergeleken met de duisternis bij het gemeentelijk apparaat......
CEH, CISSP. (zegt niets, niet aan de overheid vertellen....)
Ik betaal liever nog meer belasting voor betere kwaliteit.
Al is de belastingdienst dan nog een zwak lampje vergeleken met de duisternis bij het gemeentelijk apparaat......
Eh...multi factor authenticatie, dat is ook mogelijk met Digid, dmv een sms code. Waarbij ik overigens niet begrijp dat men nog de keuze heeft dit wel of niet te kunnen gebruiken...
Door maboc:
Inderdaad.Maar in elk geval bij het instellen van het wachtwoord zal dat doorgaans plaintext richting server gaan (via een beveiligde ssl/tls verbinding hopelijk) alwaar het dan gehasht (hopelijk incl. salt) en opgeslagen wordt.
Plaintext als voor de ontvanger bedoel je? Voor luisternde boefjes op de lijjn is eea. encrypt.De check of een wachtwoord aan de eisen voldoet zal inderdaad naar ik mag aannemen gewoon plaatsvinden op het moment dat iemand probeert in te loggen.
Overhaaste conclusies trekken levert natuurlijk lekker smeuïge reacties op, maar slaan zonder onderbouwing werkelijk als een tang op een varken.
Uh... slaat dit op mijn reactie, of is het in 't algemeen?Het is echt stuitend om te zien hoe alle instanties, bedrijven, diensten e.d. elkaar napraten over wat een veilig
wachtwoord is. Allemaal eisen over tekenset, lengte, erin voorkomen van woorden, etc.
Laten we om te beginnen stellen dat authenticatie met een wachtwoord nooit veilig is. Je wilt een persoon authenticeren
en dan ga je gebruik maken van kennis. Kennis en persoon zijn niet aan elkaar gekoppeld dus het is zowizo onveilig.
Maar los daarvan: een wachtwoord is veilig als het niet bij de inbreker bekend is, en het authenticatie systeem beveiligd
is tegen brute-force attacks. Dat laatste moeten ze zelf regelen (door tellers/timers op inlogpogingen en door deugdelijke
opslag van de wachtwoorden).
Dat het wachtwoord niet bij een ander bekend is maak je nauwelijks waarschijnlijker door die idiote eisen eraan te stellen.
ALS dat al uitmaakt, dan maak je het eerder WAARSCHIJNLIJKER, slechter dus. Immers zodra een gebruiker niet meer
zelf een handig wachtwoord kan kiezen zal hij het gaan opschrijven. En dat houd je niet tegen.
M.a.w. dit soort policies werkt contraproductief. Dat "iedereen het doet" maakt dat niet minder waar, is alleen maar een
treurige indicatie van de status van beveiliging.
wachtwoord is. Allemaal eisen over tekenset, lengte, erin voorkomen van woorden, etc.
Laten we om te beginnen stellen dat authenticatie met een wachtwoord nooit veilig is. Je wilt een persoon authenticeren
en dan ga je gebruik maken van kennis. Kennis en persoon zijn niet aan elkaar gekoppeld dus het is zowizo onveilig.
Maar los daarvan: een wachtwoord is veilig als het niet bij de inbreker bekend is, en het authenticatie systeem beveiligd
is tegen brute-force attacks. Dat laatste moeten ze zelf regelen (door tellers/timers op inlogpogingen en door deugdelijke
opslag van de wachtwoorden).
Dat het wachtwoord niet bij een ander bekend is maak je nauwelijks waarschijnlijker door die idiote eisen eraan te stellen.
ALS dat al uitmaakt, dan maak je het eerder WAARSCHIJNLIJKER, slechter dus. Immers zodra een gebruiker niet meer
zelf een handig wachtwoord kan kiezen zal hij het gaan opschrijven. En dat houd je niet tegen.
M.a.w. dit soort policies werkt contraproductief. Dat "iedereen het doet" maakt dat niet minder waar, is alleen maar een
treurige indicatie van de status van beveiliging.
NIET BELASTINGDIENST bullshit journalisten weer, eisen komen van logius ofwel DIGID iedereen weet en zeker security.nl zou dat moeten weten dat iedereen die wil aansluiten op DIGID aan de voorwaarden van LOGIUS moeten voldoen.
ik snap er niets van ben nu vanaf zaterdag bezig om mijn aangifte blad te krijgen. Ik ben niet zo handig, en weet dus niet wat ik nu steeds fout doe. Termen als een catchacode, bergijp ik niet. Ik ga morgen maar weer eens naar de balastingdienst toe. zou wat graag een papieren aangifte willen doen.
bestaat er ook een mogelijkheid om extra geheugen in mijn boven kamer te krijgen om al deze "veilige" wachtwoorden in op te slaan want ik wordt zo langzaam aan gek van de codes die ik moet onthouden om iets gedaan te krijgen
en ja het plakkertje met het nieuwe wachtwoord schittert alweer op mijn monitor want onthouden is er niet meer bij
en ja het plakkertje met het nieuwe wachtwoord schittert alweer op mijn monitor want onthouden is er niet meer bij
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.