Van Huffelen: openbaar maken broncode DigiD moet voor veiligere app zorgen
Het gedeeltelijk vrijgeven van de broncode van de DigiD-app moet voor een veiligere app zorgen, zo stelt staatssecretaris Van Huffelen van Digitalisering. Begin dit jaar besloot de overheid om de broncode van de DigiD-app deels via GitHub openbaar te maken. Dit zorgde voor vragen en zorgen bij de VVD, zo blijkt uit een debat van de vaste commissie voor Digitale Zaken over informatiebeveiliging bij de overheid dat vorige week plaatsvond.
"De broncode van de DigiD-app is na een Woo-verzoek openbaargemaakt. DigiD moet voor iedereen veilig zijn, vinden wij. Hoe is dat gewaarborgd? Enkele fragmenten van die broncode kunnen echt een beveiligingsrisico hebben. Er moet een continuïteit zijn op het gebied van de veiligheid daarvan. Het moet blijven werken. Denk daarbij ook aan informatie over infrastructuur en waar de app op draait. Dat is best een risico voor hackers. Hoe gaat de overheid om met dit soort Woo-verzoeken? Dat geldt ook voor andere applicaties. Wat mij betreft is het: Woo tot hier en niet verder. Niet alles hoeft altijd openbaar", stelde VVD-Kamerlid Rahimi.
Hij stelde als it'er zorgen te hebben over het openbaar maken van alles. "Dat lijkt soms goed, maar soms kan het ook best dingen prijsgeven over de infrastructuur die wij hebben, de codes die wij gebruiken en de parameters die worden doorgestuurd. Daar kan een hacker best wel wat mee. Daar kan een regering ook best wel wat mee. Daar maak ik me gewoon zorgen om. Ik vind dat openbaarheid goed is. We moeten wel echt naar het volgende kijken. De broncode van de DigiD-app is gepubliceerd op GitHub. Daar kan iedereen bij. Daar zitten letterlijk fragmenten bij waarop "security" staat. Dat kan ervoor zorgen dat sommige dingen eruit worden gehaald. Iemand kan dan iets bouwen."
Rahimi is dan ook bang voor allerlei narigheid, zoals phishing of malafide apps. "Daarom zei ik ook, voor de grap: Woo tot hier en niet verder. Dit soort dingen moeten we niet doen." Volgens Van Huffelen zijn de zorgen onterecht. "Onze strategie bij open source is om broncodes te delen om daarmee de kwetsbaarheid van overheidssystemen te verminderen, door ervoor te zorgen dat partijen, al dan niet door onszelf daartoe uitgenodigd, mee kunnen kijken naar hoe onze programmatuur eruitziet. Daarmee kunnen ze fouten eruit halen en aangeven of er zwaktes in die programma's zitten. Dat wil niet zeggen dat je daarmee de beveiligingssleutels ook openbaar maakt. Dat hebben we bij DigiD ook niet gedaan. Dat zou namelijk kunnen leiden tot veiligheidsrisico's."
De staatssecretaris voegde toe dat het idee is om open source te gebruiken om daarmee programma's veiliger te maken. "Opensourcesoftware of combinaties van verschillende opensourceprogrammatuur is overigens ook iets wat heel veel partijen gebruiken. Maar we doen dat vanuit veiligheid en natuurlijk op een manier die verantwoord is, door ervoor te zorgen dat informatie die afbreuk doet aan de veiligheid van systemen, zoals versleutelingsmechanismes, wachtwoorden, verwijzingen naar technische infrastructuur enzovoorts, natuurlijk niet wordt gedeeld."
Maar ik moet wel zeggen: Broncode hebben maakt het wel makkelijker.
Anders heeft het totaal geen nut. Wat broncode publiceren waarvan je toch niet kunt controleren of de echte app daar wel gebruik van maakt daar heb je weinig aan.
Anders heeft het totaal geen nut. Wat broncode publiceren waarvan je toch niet kunt controleren of de echte app daar wel gebruik van maakt daar heb je weinig aan.
Wat nu gepubliceerd is is een moment opname, en bovendien onvolledig. Does not compile :(
Ik wacht met smart op de dag dat de overheid al haar apps ook gewoon in de FDroid store plaatst.
De identificatie is als het goed is hier goeddeels op gebaseerd als het goed is. Als 'openbaar maken' de boel verzwakt, dan zit het toch al niet goed in elkaar volgens bovenstaande.
Anders heeft het totaal geen nut. Wat broncode publiceren waarvan je toch niet kunt controleren of de echte app daar wel gebruik van maakt daar heb je weinig aan.
Persoonlijk vind ik dat dit toegestaan moet zijn. Authenticatie moet een protocol zijn, niet een arbitraire blob.
(De staatssecretaris heeft waarschijnlijk de gebruikelijke term versleutelingsalgoritmes bewust niet gebruikt, om het daarop aanslaan van nog meer noobs te voorkomen. Aarrghh een algoritme!)
Anders heeft het totaal geen nut. Wat broncode publiceren waarvan je toch niet kunt controleren of de echte app daar wel gebruik van maakt daar heb je weinig aan.
https://reproducible-builds.org/
... en tools om de benodigde vergelijkingen te doen, zoals:
https://diffoscope.org/
Ook als builds niet volledig identiek zijn kan je met dergelijke tools al heel ver komen in het maken van vergelijkingen. Als het niet alles is voor een app betekent dat nog niet meteen dat het niets is.
Dat blijft altijd aanmodderen. Als jij een manier weet te bedenken om dat te vermijden, die nog echt werkt ook, dan doe je iets waar volgens mij nog nooit iemand in is geslaagd.
Software door de overheid publiek inspecteerbaar te maken is het juiste plan.
Het probleem van digitalisering is dat commerciële partijen dit promoten, vanzelfsprekend zonder de nadelen te benoemen. Als regeringen en kamerleden daar niet zelf doorheenprikken, en ook geen capabele en onafhankelijke adviseurs hebben die dat voor hen doen, lopen we recht in de val (wat steeds vaker lijkt te gebeuren).
Als alternatief kunnen schriftelijke vragen gesteld worden, waar zowel de vraagstellers, de beantwoorders als de lezers daarvan ter zake deskundigen kunnen raadplegen.
Als hij een IT-er is met deze angsten dan ben ik blij dat hij politicus is geworden en geen IT systemen meer bouwt. Dergelijke zaken zet je in je configuratie en niet in je broncode.
Peter
Als hij een IT-er is met deze angsten dan ben ik blij dat hij politicus is geworden en geen IT systemen meer bouwt. Dergelijke zaken zet je in je configuratie en niet in je broncode.
Peter
Ik denk dat je dit statement iets te simpel leest .
Er zit gewoonlijk een hoop van de API structuur verwerkt in code , te zien aan hoe de API calls opgebouwd worden.
En dat is best erg behulpzaam als je kwaadwillend bent op het availability aspect van security.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
