Ministerie maakt broncode van DigiD-app opensource

De broncode van de DigiD-app is nu als opensource beschikbaar op GitHub. Het ministerie zegt hiermee de werking van de app transparant te willen maken. Alleen bepaalde gevoelige informatie, zoals informatie over de infrastructuur, blijft geheim.

De broncode is te bekijken via een GitHub-pagina van het ministerie van Binnenlandse Zaken en te hergebruiken onder de EUPL-licentie. Enkele fragmenten blijven geheim, omdat ze bijvoorbeeld een beveiligingsrisico kunnen vormen. Deze fragmenten zijn vervangen door de letter S, voor security. Andere fragmenten waaruit persoonsgegevens van ontwikkelaars te herleiden zijn, zijn vervangen door de letter P, voor privacy.

Op dit moment is de gepubliceerde broncode een momentopname, schrijft staatssecretaris van Digitalisering Alexandra van Huffelen. DigiD-agentschap Logius wil later ook nieuwe versies openbaar kunnen maken, maar hiervoor moet de software eerst geschikt worden gemaakt. "Daarnaast moet de organisatie klaar zijn om deze andere manier van werken te ondersteunen", schrijft de staatssecretaris. "Het kost tijd om dit zorgvuldig te kunnen doen, naast de dagelijkse werkzaamheden om te zorgen dat DigiD veilig en betrouwbaar blijft werken."

Later wil Logius daarnaast de broncode van de DigiD-software die bij het agentschap draait, opensource maken. Het agentschap heeft zich echter eerst op de app gericht. Wanneer de Logius-software vrijgegeven moet worden, is niet bekend. Het ministerie stelt de broncode als opensource beschikbaar, nadat Logius in juni 2022 een 'Wet open overheid'-verzoek kreeg. Met DigiD kunnen burgers veilig inloggen bij bijvoorbeeld overheidssites.

Reacties (122)

[CurlyMo]

Hier overigens de informatie rond het Woo verzoek zelf:
https://www.rijksoverheid...rzoek-over-broncode-digid
https://www.rijksoverheid...making-broncode-digid-app

[Reactie gewijzigd door CurlyMo op 22 juli 2024 16:00]

[Freeaqingme]

Op zich is dit natuurlijk toe te juichen, en een goede eerste stap.

Echter:

Enkele fragmenten blijven geheim, omdat ze bijvoorbeeld een beveiligingsrisico kunnen vormen. Deze fragmenten zijn vervangen door de letter S, voor security.

Dat betekent dat derden dus nog steeds niet in staat zijn om de app zelf ook te bouwen. Bijvoorbeeld als ze niet Android of iOS willen draaien. Zolang dat geen mogelijkheid is wens ik de app niet te gebruiken.

Blijf het van de zotte vinden dat dit soort dingen niet gebaseerd zijn op open standaarden. Stel je voor dat je enkel met een webbrowser van de overheid hun websites zou kunnen openen. Dat moet je niet willen. Niet als individu, en ook niet als maatschappij.

[HooksForFeet]

Blijf het van de zotte vinden dat dit soort dingen niet gebaseerd zijn op open standaarden.

Als ik de informatie van Logius zo eens bekijk dan is DigID gewoon gebaseerd op de voor de overheid verplichte open standaarden. Welke onderdelen zijn volgens jou niet op open standaarden gebaseerd en op basis van welke standaarden zou je die onderdelen dan willen zien?

[Freeaqingme]

Goed punt. Het is inderdaad 'open' in de zin dat het HTTP(S) implementeert, en niet een of ander obscuur obfuscated binair TCP protocol. Dat gezegd hebbende, is er denk ik nergens een beschrijving van welke http-requests je dan moet doen om een eigen implementatie te kunnen maken.

Ik gebruik zelf Android, dus in principe zou ik prima met de standaard-app uit de voeten moeten kunnen. Maar ik wil wel de vrijheid hebben om als ik dat zou willen een ander platform te kunnen gebruiken. Sterker nog, ik zou het ook gewoon op m'n desktop willen kunnen gebruiken.

[HooksForFeet]

Dat zou idealiter zo zijn ja, maar dat is meer een kwestie van ontwikkeldocumentatie dan van open source of open standaarden. Ik ben het met je eens dat het heel prettig zou zijn als je zelf ook requests zou kunnen doen.

De vraag is dan wel: wat doe je dan aan de onvermijdelijke wildgroei aan nep-DigID-apps die prima werken om mee in te loggen op overheidswebsites maar onzichtbaar ook requests van de ontwikkelaar accepteren om op jouw belastingdienstportaal in te kunnen loggen?

Er zal iets moeten zijn waardoor het DigID-backend weet dat dit geen malafide app is en dat het om een oprechte request van de eigenaar van het account gaat. Dat gaat dan al snel neerkomen op een audit van je code door de overheid voor je toegang krijgt.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[Freeaqingme]

Eens. Ik zie dat punt ook wel. Alleen de gekozen oplossing is - hoewel wel simpel - m.i. de verkeerde: Een overheid zou juist op basis van inclusie moeten werken, het is geen start-up die zich richt op 80% van de doelgroep en de rest maar in de kou kan laten staan.

Het probleem van de nep-apps is niet iets dat je oplost door het maar geheim te maken, dat moet op het niveau van de distributielaag (appstores, package signing, etc) gebeuren.

Verder zijn er zat andere landen waar men dit wel platform-neutraal kan. Daarbij gebruikt men dan bijv. een smart card reader welke rijbewijzen kan gebruiken als smartcard (bijv. Belgie of Estland).

[HooksForFeet]

Als je op de distributielaag gaat bepalen welke apps toegang krijgen, dan kan je dus nog steeds niet je eigen app voor je eigen platform maken. Je zal dan alsnog eerst toegang moeten vragen, en die gaan ze (hoop ik toch) niet aan iedere al dan niet integere developer verstrekken.

Overigens werken package signing en appstores ook op basis van geheimhouding. Denk alleen al aan de geheime sleutels om de packages mee te signen.

Inloggen met een smart card wordt overigens ook door DigID ondersteund. En ook in Begie en Estland kan niet iedereen zomaar een authenticatie-app bouwen om in te loggen op overheidsdiensten. Die smart card neemt hooguit de functie van je gebruikersnaam en wachtwoord over. En die waren al platformneutraal.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[barbarbar]

Heb hier zo'n smartcard en reader van luxtrust voor zaken met luxemburg. Wat een gedoe is dat elke keer. Elke keer een stukje software van hun wil updaten, werkt maar met een beperkt aantal browsers, beperkt aantal readers, en zittwn flinke kosten aan om die elke drie naar te vernieuwen. Doe mij maar digid. Als je het niet vertrouwd koop je een goedkope smartphone voor alleen de digid app, ben je goedkoper uit.

[supersnathan94]

De vraag is dan wel: wat doe je dan aan de onvermijdelijke wildgroei aan nep-DigID-apps die prima werken om mee in te loggen op overheidswebsites maar onzichtbaar ook requests van de ontwikkelaar accepteren om op jouw belastingdienstportaal in te kunnen loggen?

De manier waarop de app werkt staat dit absoluut niet toe. Kompleet uitgesloten. De koppelcode is maar 1 keer te gebruiken en de gebruiker moet een QR code scannen.

Challenge-response mechaniek die dit soort zaken in principe compleet uitsluit.

[HooksForFeet]

De ontwikkelaar gaat naar jouw belastingdienst portal, vraagt op afstand (onzichtbaar) aan jouw app om een koppelcode, vult die in, stuurt de QR code (of althans, de string die daarin zit) naar jouw versie van de app, de app geeft de juiste response aan de belastingdienst en de ontwikkelaar is ingelogd op jouw belastingdienst portal.

Challenge & Response sluit het herhaald gebruiken van dezelfde code uit ja, maar dat is niet het scenario dat ik beschreef.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[supersnathan94]

De app moet dan echter wel exact hetzelfde nog een keer doen voor de originele app waar je zou willen inloggen. Want anders kan de gebruiker niks.

En als je dat dan toch in zijn geheel kan faken heb je eigenlijk alleen nog maar de pincode van de gebruiker nodig. Want de rest van het proces heb je volledig in handen.

Het valt alleen heel erg op als uitgerekend jouw app (die gewoon identificeerbaar is aan de kant van Logius) altijd 2 sets aan requests maakt.

Ik denk dat je hier met een redelijke audit gewoon achter gaat komen op een manier dat het echt niet houdbaar is om het op die manier te doen.

[HooksForFeet]

Dan begrijp je me niet helemaal. Ik heb het er niet over dat iemand mee kan inloggen als jij inlogt op bijvoorbeeld de belastingdienst, ik heb het erover dat iemand op afstand jouw gekoppelde DigID-app kan gebruiken om op jouw dingen in te loggen, ook als je bijvoorbeeld slaapt. Zie het als volgt:

- De gebruiker downloadt de malafide app en koppelt die met zijn DigID. Vervolgens raakt deze de app niet meer aan.
- De ontwikkelaar krijgt een seintje van de app dat deze gekoppeld is.
- De ontwikkelaar gaat op zijn eigen PC naar mijn.belastingdienst.nl. De site vraagt om een koppelcode.
- De ontwikkelaar stuurt onzichtbaar een bericht naar de malafide app op de telefoon van de gebruiker. De app vraagt - onzichtbaar voor de gebruiker - een koppelcode op en stuurt deze naar de ontwikkelaar.
- De ontwikkelaar vult de koppelcode in op de belastingdienst-site en krijgt een QR-code. Deze stuurt hij weer naar de malafide app, zonder dat de gebruiker dat kan zien. De app gebruikt op de achtergrond de QR code om een response te genereren en stuurt deze vervolgens naar de backend van de belastingdienst.
- De belastingdienst-backend keurt de authorisatie goed, en stuurt een seintje naar de browser waar deze begon - namelijk de browser van de ontwikkelaar.
- De ontwikkelaar zit nu op jouw belastingdienst portal zonder dat de gebruiker de app zelf heeft gebruikt om in te loggen.

Logius en overheid kunnen hier ook niks van zien: zij zien puur normale requests binnenkomen voor een koppelcode en een response. De browser zit wel op een ander IP-adres dan de app, maar dat is bij de normale DigID-app vaak ook zo, bijvoorbeeld als je PC gewoon op je thuisnetwerk zit en je telefoon op mobiele data. Daar kan je dus ook niet op filteren.

DigID zal erop moeten kunnen vertrouwen dat de requests door de eigenaar zelf zijn geïnitieerd. Dat kan niet als je ook apps van derden gaat toestaan waar je geen controle over hebt.

En als je dat dan toch in zijn geheel kan faken heb je eigenlijk alleen nog maar de pincode van de gebruiker nodig. Want de rest van het proces heb je volledig in handen.

Dat is niet zo, want de gebruiker zal eerst zelf zijn DigID app moeten koppelen met DigID. De DigID backend weet overigens niks van die pincode en zal er ook nooit om vragen, die is puur om de app lokaal te kunnen ontgrendelen.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[dimdek]

Als ik even snel kijk bij de app in Android dan staat erbij dat GSF vereist is. Er wordt dus toch gebruik gemaakt van obscure Google code en het gebruik van de app is dus altijd bekend bij Google. Waarom willen we dat in Nederland? Of sterker nog: waarom eisen we dat van Nederlandse burgers?
Wat mij betreft zou de app dus eerst moeten worden herschreven naar code die geen GSF vereist.

[Brent]

Zaken zoals IPv4 opnemen in de lijst van open standaarden die men respecteert, is natuurlijk niet wat iemand bedoelt wanneer die dit punt opbrengt: dat gaat om direct gerelateerde bestands- of communicatieformaten. Of daar API's onder vallen is al te bediscussiëren: ik kan me voorstellen dat er heel wat custom API worden gemaakt en gebruikt waarvoor geen open standaard is. Die zou de ontwikkelaar dan tegelijkertijd moeten ontwikkelen, en dat lijkt me typisch wel buiten de scope van zo'n contract vallen.
Maar dat die over IPv4 benaderbaar zijn is een evidentie, elk ander protocol zou een onnodige complicatie zijn. Je zou de scope van de standaarden kunnen vaststellen mbv reimplentatie: welke dingen moet je weten om een alternatieve client te bouwen? (Of deze dan geautoriseerd is om toegang tot backends te krijgen is een tweede. Op zich ook interessant: https://stackoverflow.com...y-other-unauthorised-apps)

Helaas is er geen overheid (in NL) die er gebruik van maakt, maar e2ee zou bijvoorbeeld zo'n standaard zijn die het vermelden waard is. Kan ik mijn PGP public key afgeven bijv.? Dan kan ik opeens met een scala aan software toegang krijgen tot mijn communicatie met de overheid. Nu moet je inloggen op een custom stuk software, of diverse stukken software. In bijv. Duitsland kan dit wel bij sommige overheden, evenals Matrix, en wordt dat ook gepusht (de Duitse overheid financiert deels enkele PGP-implementaties). Dat zou ik een meer open standaarden gebruikende benadering noemen. U2F tokens lijken me nog zo'n open standaard die in de tabel thuishoort, en helaas niet geïmplementeerd wordt momenteel.

De tabel in de link zou dus idealiter vastgesteld worden door experts die niets met de implementatie te maken hebben (het wij-van-wc-eend risico is dan wat groot).

[Reactie gewijzigd door Brent op 22 juli 2024 16:00]

[HooksForFeet]

Het is natuurlijk niet helemaal eerlijk om te doen alsof er alleen zaken als IPv4 in die lijst staan als er nog zat andere open standaarden in staan. Mogen er meer open standaarden gebruikt worden? Tuurlijk. Maar de originele opmerking was dat er helemaal geen gebruik gemaakt werd van open standaarden terwijl er uit makkelijk te vinden informatie overduidelijk blijkt dat dat helemaal niet waar is.

De tabel in de link zou dus idealiter vastgesteld worden door experts die niets met de implementatie te maken hebben (het wij-van-wc-eend risico is dan wat groot).

Dan heb je geluk, want die tabel wordt dus niet vastgesteld door Logius zelf maar door het Forum Standaardisatie, dat bestaat uit vertegenwoordigers uit overheid, bedrijfsleven en de wetenschap.

[Brent]

Je argument gaat iets teveel in de richting van deze quote naar mijn smaak: relevantie moet een criterium zijn, want anders, zoals het citaat grapt, kan elke procedure, info (of standaard) technisch gezien als open aangevoerd worden terwijl de zeer relevante praktische problemen daarbij niet genoemd worden Dat is het doel van open standaarden: de burger en de overheid zelf niet opsluiten in technologische silo's. IPv4/6 is geen praktisch bezwaar voor derden, de vraag is: welke protocollen/standaarden (of gebrek daaraan) zijn dat wel?

Ik heb het Forum gemaild trouwens!

[HooksForFeet]

de vraag is: welke protocollen/standaarden (of gebrek daaraan) zijn dat wel?

Dat lijkt mij een vraag voor Freeaqingme, die claimde dat er helemaal geen open standaarden werden gebruikt. Hij/zij zal ongetwijfeld duidelijke en goed onderbouwde ideeën hebben over welke standaarden ontbreken in die lijst.

[wildhagen]

Wat ik begreep is dat het vooral commentaar in de code is, met namen van medewerkers die weggehaald zijn en van een "S" (Security) tag zijn voorzien. Ik zie ook de toegevoegde waarde niet van het publiceren van die namen, met alle (veiligheids)risico's vandien voor die mensen (en hun gezinnen).

Daarnaast vermoed ik dat je zaken als API-keys etc ook niet openbaar op straat wil hebben liggen, als overheid/Logius zijnde.

[PolarBear]

Het zijn, wat ik nu tegen ben gekomen links naar de appstore:

CrossStoreReview.Current.OpenStoreReviewPage("SSSSSSSSSSSSSSSSSSSSSSSSSS");
await Launcher.OpenAsync(new System.Uri("SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS"));

[CurlyMo]

Ook in SigningServices.cs komt het terug:

internal class SigningService : ISigningService
{
private const string Key = "SSSSSS";
private const string TestKey = "SSSSSSS";

https://github.com/MinBZK...ervices/SigningService.cs
https://github.com/MinBZK...OS/Services/NFCService.cs

[Not Pingu]

In de aanroep naar KeyStoreHelper.CreateKeyPairForSigning() zie je dat dit eigenlijk key names zijn waaronder gegenereerde keys worden opgeslagen, en geen concrete keys.

[citegrene]

Gaat dit er op neer komen dat wanneer de app decompiled, je strings gaat vinden die je niet mag weten...

[webkiller71]

Daarnaast vermoed ik dat je zaken als API-keys etc ook niet openbaar op straat wil hebben liggen, als overheid/Logius zeinde.

Ik heb geen ervaringen met apps bouwen, maar wat mij betreft horen dat soort dingen horen ook niet in de source code. In alle server side software die ik schrijf/onderhoud probeer ik dat soort dingen te scheiden. Eigenlijk is dat al een vereiste als je met testomgevingen wil werken waar die anders horen te zijn dan productieomgevingen.

[wildhagen]

Dat het er niet in hoort ben ik met je eens, maar ik denk dat we allemaal weten dat het toch regelmatig gebeurt.

Heb al regelmatig code van apps gezien (niet DigiD ofzo, maar algemeen) waar gewoon API-keys in staan, en zelfs 'gewoon' hard-coded passwords en andere zaken van dat niveau.

Ik snap het wel dat Logius die informatie van een S-tag (Security) voorziet en weghaalt, als dat er in zou staan. Doe je dat niet, heb je binnen een paar uur tig fake DigiD-apps in de playstore/appstore staan, en kan de fraudehelpdesk weer wat extra telefoontjes verwachten van slachtoffers van deze apps.

[CAPSLOCK2000]

Dat zijn dan wel het soort dingen die ik juist wil zien in de code, als ik een audit zou doen. Ik hoef de geheime code niet te kennen maar ik wil wel weten dat er dergelijke codes inzitten want meestal wijst dat op een slecht ontwerp.

[Schway]

Is deze github pagina bedoelt om een audit op te doen?

[CAPSLOCK2000]

Is deze github pagina bedoelt om een audit op te doen?

Ja, uit het artikel: "Het ministerie zegt hiermee de werking van de app transparant te willen maken."
Dat proces van controleren hoe een applicatie werkt is een audit.

[HooksForFeet]

De werking van een app transparant maken is onder andere een manier om audits mogelijk te maken. Maar het transparant maken van een de werking is niet per sé enkel bedoeld voor audits.

[WoutervOorschot]

Je zet het zelf al, server side code. Een app moet standalone werken en heeft dus bijna altijd een bepaalde hoeveelheid identifiers nodig. Je beheert de environment niet (op server zou je bijv je tokens/keys in environment variables kunnen zetten) dus het moet in je app. Of je dat in de broncode doet of tijdens compilen maakt bij closed source code niet uit.

Bij open source is het gangbaar dat compile time te doen zodat je de code zelf open kunt houden. Hier hebben ze het weggehaald bij het openbaren omdat het waarschijnlijk nooit een designcriterium is geweest.

[webkiller71]

Bij open source is het gangbaar dat compile time te doen zodat je de code zelf open kunt houden. Hier hebben ze het weggehaald bij het openbaren omdat het waarschijnlijk nooit een designcriterium is geweest.

Mee eens en ik denk ook dat ze daarop doelen bij dit deel:

"Daarnaast moet de organisatie klaar zijn om deze andere manier van werken te ondersteunen", schrijft de staatssecretaris. "Het kost tijd om dit zorgvuldig te kunnen doen, naast de dagelijkse werkzaamheden om te zorgen dat DigiD veilig en betrouwbaar blijft werken."

Je ziet dit heel duidelijk in https://github.com/MinBZK..._Mobile-ProjectConfig.yml. Aan de ene kant goed dat het bestand er in zit, maar secrets en open code gaan niet goed samen. Je hoort eigenlijk dit tijdens je build proces the injecteren. Dat voorkomt ook dat als een keer de code uitlekt je niet ook meteen al je secrets uitlekt. Daarom alleen al denk ik dat je zelfs bij closed source software het een designcriterium moet maken.

[CAPSLOCK2000]

Wat ik begreep is dat het vooral commentaar in de code is, met namen van medewerkers die weggehaald zijn en van een "S" (Security) tag zijn voorzien.

Ik las dat ze de tag "P" gebruikt hebben voor namen en ander privacy-gevoelige dingen.
De tag "S" is voor security.

Ik zie ook de toegevoegde waarde niet van het publiceren van die namen, met alle (veiligheids)risico's vandien voor die mensen (en hun gezinnen).

Daarnaast vermoed ik dat je zaken als API-keys etc ook niet openbaar op straat wil hebben liggen, als overheid/Logius zijnde.

Eens, maar die moeten dan ook niet in de source zitten.

[Blokker_1999]

In principe hoor je de app te kunnen bouwen, je zal alleen geen verbinding kunnen maken met de achterliggende infrastructuur. Zo lees ik het tenminste. Maar zelfs dat is eigenlijk al spijtig te noemen. Daarnaast ontbreekt ook elke vorm van documentatie voor de code. Iemand is er goed doorgegaan om zeker te zijn dat er geen comments zijn blijven staan en dat je alsnog alles zelf maar weer bij elkaar mag gaan analyseren.

Dat het niet gebasseerd is op open standaarden, tot daar aan toe. Maar dat de code zelf standaard niet openbaar is, dat is pas van de zotte. Security through obscurity is no security at all. En de code is geschreven met belastinggeld.

[HooksForFeet]

Security through obscurity is no security at all.

Beetje een dooddoener natuurlijk. Gooi jij je API-keys en je wallet-codes ook gewoon in het openbaar? Obscurity is wel degelijk een onderdeel van security. Het gaat erom dat je niet alleen op obscurity vertrouwt.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[RobertMe]

API keys horen niet in de source code. Dat hoort input tijdens de build te zijn (dus bv een automatisch gegenereerde source file door de builder op basis van een YAML / ini / ... dile). Dat "configuratie" bestand met secrets ga je dan uiteraard niet publiceren. Maar als het open source is/wordt gemaakt kun je de broncode dan wel "as is" publiceren.

Daarnaast zijn API keys überhaupt nooit secret. Als de app een API key nodig heeft zal die toch echt ergens in de gebuilde source code zitten en dus kun je deze achterhalen door de binary te decompilen.

[HooksForFeet]

Security is meer dan programmeren he? Dit gaat niet over of iets in source code hoort, dit gaat over of obscurity een valide manier van beveiliging is. En dat is het, we gebruiken niet voor niets secrets in security.

Dat een API key nooit geheim is omdat hij ergens in de binary zit, is een beetje onzin. Zo'n key kan prima encrypted zijn bijvoorbeeld. Is met veel decompile-werk en analyse de decryptiemethode te achterhalen? Ja. Maar dat maakt encryptie nog niet onbruikbaar voor security, evenmin als obscurity dat doet.

API keys horen niet in de source code. Dat hoort input tijdens de build te zijn (dus bv een automatisch gegenereerde source file door de builder op basis van een YAML / ini / ... dile). Dat "configuratie" bestand met secrets ga je dan uiteraard niet publiceren. Maar als het open source is/wordt gemaakt kun je de broncode dan wel "as is" publiceren.

Door dat bestand met geheimen achter te houden ben je dus aan het vertrouwen op obscurity. Anders had je dat bestand ook openbaar moeten maken. Dat is het hele punt: je moet er niet op vertrouwen dat je de - manier waarop iets werkt - obscuur kan houden. Maar dat wil niet zeggen dat je helemaal geen geheime gegevens kan gebruiken. Je zou bijvoorbeeld prima moeten kunnen laten zien welke encryptiemethode je gebruikt, maar je hoeft er dan niet ook meteen al je keys te publiceren.

Daarom is dat citaat over security by obscurity zo'n dooddoener. Het ligt veel genuanceerder dan een populair citaat zou kunnen overbrengen.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 16:00]

[Ricko1]

Wachtwoorden, encryptie sleutels en api keys vallen niet onder 'obscurity' maar onder authenticatie. Bewijzen dat je recht hebt op toegang tot gevoelige informatie is wat anders dan de manier waarop iets is beveiligd.

Je reactie is een beetje ping pong. Het wordt uitgelegd en vervolgens zeg je

Door dat bestand met geheimen achter te houden ben je dus aan het vertrouwen op obscurity.

Nee, dat bestand is authenticatie, niet 'obscurity'

[HooksForFeet]

Authenticatie is een proces, een actie. Obscurity is een beveiligingsmethode, net als encryptie. Je bent nu twee verschillende dingen aan het vergelijken.

Authenticatie kan op verschillende manieren beveiligd worden, waaronder encryptie en - door het geheim houden van bijvoorbeeld wachtwoorden - door obscurity.

[WoutervOorschot]

Dat maakt voor closed source software nauwelijks uit. Bij open source is het belangrijk dat je het goed gescheiden houdt zodat je keys niet op github oid belanden. Als ze van begin af aan open source waren geweest was het vast zo gedaan, maar niet gek dat het nu niet zo is.

Volgens mij hebben ze meer het zekere voor het onzekere genomen, voornaamste wat overal weg is gehaald zijn URLs (callbacks, appstore links, logius-digid urls etc). Ook de URLs van de eigen testing environment en tokens voor de tests op die environment zijn weggehaald.

Die toegang is verplicht bij Apple en Google, de test env moet dus openbaar bereikbaar zijn. Ik snap wel dat ze dat soort dingen uit deze code halen, al is het maar om grapjassen met DDOS op een minder hoge capaciteit service tegen te gaan.

[kakanox]

Ik ben nog zeker geen C# expert, code tot nu toe met name in andere talen... maar is het in C# gebruikelijk om comments toe te voegen?
>> Ik probeer m'n code zo op te bouwen dat comments niet noodzakelijk zijn. Duidelijke namen voor functies en variabelen houdt het geheel meestal meer dan voldoende leesbaar.

[Caayn]

Commentaar is niet enkel om iets begrijpbaar te maken, iedereen kan wel een for loopje lezen, het kan ook helpen met uitleggen waarom destijds voor X gekozen is ipv Y, waar Y mogelijk een niet direct zichtbaar neveneffect/performance hit/etc heeft.

Zelf vindt ik wat commentaar wel fijn maar uiteraard is dat geen vrij brief om onleesbare code te schrijven. Zeker bij grote complexe systemen.

[Reactie gewijzigd door Caayn op 22 juli 2024 16:00]

[kakanox]

Hm, zit zeker wat in, maar ik ben eigenlijk van mening dat het ontwerp niet in de code moet zitten maar in technische documentatie.

[sanderv]

Het is heel moeilijk om documentatie up-to-date te houden, en je moet er over nadenken hoe je dat het beste kunt doen in de verschillende abstractielagen van je applicatie. Het documenteren van de architectuur, en van basis-concepten die door je hele applicatie terugkomen, is prima in opzichzelfstaande documentatie. Maar het documenteren van detailed design of kleine nuances kan vaker beter heel dicht bij de code blijven. Dit vergroot de kans dat het uptodate gehouden wordt als de code verandert. En zelfs dan is het vaak nog een uitdaging, zeker met IDEs (of simpelweg search-and-replace) die automatisch de code aanpassen, maar niet de comments. Daarom is het goed om voor low level details te zoeken naar manieren om de code zelfdocumenterd te maken, bijvoorbeeld met goede namen voor variabelen, functies en classes, of een API die zichzelf documenteert (zoals OpenAPI).

[zwartpet]

Comments in code lopen anders vaak ook achter, hebben totaal geen relevantie meer tot de code omdat hij is aangepast maar de comment niet, en word soms zelf mee gekopieerd naar andere plekken (duplication is ook niet goed maar gebeurt alsnog).

Nee, als code niet duidelijk genoeg is dan moet het gewoon herschreven worden. Opgeknipt in stukjes in functies en classes met beschrijvende namen. Blijft een kwestie van smaak natuurlijk maar heleboel developers zijn het op dat vlak wel met elkaar eens.

Als het echt, echt, echt niet anders kan dan maar een comment.

[johnbetonschaar]

Comments in code lopen anders vaak ook achter, hebben totaal geen relevantie meer tot de code omdat hij is aangepast maar de comment niet

De enige reden waarom dit vaak gebeurt is luiheid, en omdat mensen het schrijven van nuttig commentaar en documentatie niet even serieus nemen als het schrijven van de code en de tests zelf.

Nee, als code niet duidelijk genoeg is dan moet het gewoon herschreven worden. Opgeknipt in stukjes in functies en classes met beschrijvende namen. Blijft een kwestie van smaak natuurlijk maar heleboel developers zijn het op dat vlak wel met elkaar eens.

Ik vind dit altijd zo'n eigenaardig visie op het documenteren van code. Het lijkt me toch wel duidelijk dat het commentaar er primair niet toe dient om uit te leggen *wat* een stuk code doet, maar *waarom*? Hoe gaat het opknippen van de code en het hernoemen van variabelen daar ooit mee helpen? Voor complexe algoritmes maakt dat het probleem alleen maar erger door de logica over de hele codebase uit te smeren?

De code die ik nu schrijf doet bijvoorbeeld geometry processing, een hele library van functionaliteit die in veel gevallen door tientallen stappen gaat en daarbij third-party geometry kernels aanroept met allerhande parameters en transformaties etc. die voor iemand niet met de logica of de algoritmes bekend is, volkomen onduidelijk is. Waarom moet alle interne edges eerst worden opgeschoond voordat je de shape kan fusen? Waarom worden in dit loopje alle coordinaten eerst op een grid gezet? Waarom roepen we hier functie A van de library aan en niet functie B? Waarom gebruiken we hier een N^2 loopje in plaats van een O(N) loopje, terwijl je meestal precies andersom zou doen? Echt op bijna elke 10 regels code die ik schrijf kan ik wel een nuttig stuk informatie toevoegen van het 'waarom', en als ik code teruglees die ik zelf een jaar geleden geschreven heb ben ik super blij dat ik het destijds opgeschreven heb, want dat scheelt me gewoon bergen tijd en voorkomt bugs door aanpassingen door mijzelf of door anderen.

Ik ben er persoonlijk echt van overtuigd dat de instelling van 'veel programmeurs' die 'het erover eens zijn' dat 'code zichzelf documenteert' en dus 'niet of nauwelijks commentaar nodig heeft' gewoon luiheid en gemakzucht is. Er is echt geen enkele reden om je code niet te documenteren en de comments up-to-date te houden, je bewijst er je toekomstige zelf en je collega's echt geen dienst mee door te claimen dat commentaar over het vertalen van de syntax gaat en daarom nutteloos is of wat dan ook. Als wij mensen interviewen voor een developer vacature en ze laten duidelijk merken dat ze goed commentaar in de code niet belangrijk vinden dan is dat een hele dikke min, en dus grote kans dat we ze niet in het team aannemen.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 16:00]

[zwartpet]

Ik zeg niet dat code niet gedocumenteerd moet zijn, maar een 'waarom' is in principe architectuur en hoort bijvoorbeeld in een Confluence en niet in de code.

Vind het een stuk eenvoudiger lezen als er gewoon een goeie pagina is over geometry processing en hoe dat in de code in z'n werking gaat, eventueel met stukjes pseudo code als het echt ingewikkeld is. Met eventuele bijzondere design keuzes verder toegelicht.

Lijkt me dat je hier namelijk een heel boekwerk over kunt schrijven als je echt op elke 10 regels een nuttig stuk informatie kwijt kan.

[Reactie gewijzigd door zwartpet op 22 juli 2024 16:00]

[johnbetonschaar]

Ik zeg niet dat code niet gedocumenteerd moet zijn, maar een 'waarom' is in principe architectuur en hoort bijvoorbeeld in een Confluence en niet in de code.

High-level documentatie over het design wel ja, of de theorie achter de implementatie. Dat is iets totaal anders dan code commentaar over waarom een stukje implementatie op manier A werkt en niet op manier B, of waarom een implementatiedetail relevant is. Je gaat echt niet op confluence op schrijven dat 'op regel 300-320 van mesh.cpp eerst functie A van een third-party library wordt aangeroepen voordat functie B wordt gebruikt, omdat functie B anders voor bepaalde inputs er 2x zo lang over doet'. Geen enkele programmeur gaat die documentatie ooit opzoeken en nalezen terwijl je door de code gaat. Het spreekt ook je eigen argument tegen dat code en commentaar het risico hebben uit elkaar te gaan lopen (wat een valide argument is). Als je ze gaat scheiden en dit soort commentaar op Confluence gaat zetten dan weet je 100% zeker dat niemand het ooit up to date gaat houden, want terwijl je naar de code kijkt weet je niet eens of en wat er ergens op een Confluence page over te vinden zou kunnen zijn.

[zwartpet]

Je gaat echt niet op confluence op schrijven dat 'op regel 300-320 van mesh.cpp eerst functie A van een third-party library wordt aangeroepen voordat functie B wordt gebruikt, omdat functie B anders voor bepaalde inputs er 2x zo lang over doet'

Ik zou dit afvangen in een test om er zeker van te zijn dat het niet veranderd. Aan de naamgeving van de test is dan eventueel af te leiden waarom. Zou er zeker geen docblock aan besteden. Maar smaken verschillen.

Denk niet dat het uitmaakt waar je iets documenteert, in de code of op confluence. Als je te lui bent om documentatie te updaten gebeurt het op beide plekken niet. En invalide comments leiden nou eenmaal meer af dan een of andere invalide pagina ergens waar je momenteel niet naar kijkt. Waar overigens ook in 1 oogopslag te zien is welke pagina's nog een beetje up-to-date zijn en waar periodiek goedkeuring aan pagina's gegeven kan worden om ze aan te merken als nog relevant.

[Anoniem: 80910]

Je zult de links naar de documentatie boven de functies moeten zetten. Houd je code en documentatie gescheiden en op de juiste plek.

[Kriekel]

Daarnaast:

// Re-use is permitted under the EUPL-license, with the exception
// of source files that contain a different license.

Ik zie zo snel geen bestanden met een andere licentie, maar toch.

[Terr-E]

Ik denk dat dat meer een juridische achtervang is, voor het geval er nu of later wél files in komen met een andere licentie. Je wilt natuurlijk voorkomen dat je een geschil over je uitroept omdat je bent vergeten dit zinnetje toe te voegen.

[gooos]

Inderdaad - ook ik ben voor open standaarden in deze. Dan kan je gewoon een van de grote auth apps gebruiken die je waarschijnlijk al op je telefoon hebt staan in plaats dat je voor elke dienst een eigen auth app moet installeren.

[Rolfie]

Kan ook met een stukje ondersteuning te maken hebben.

3de partijen hoeven het niet veiliger te maken.

[Not Pingu]

Dat betekent dat derden dus nog steeds niet in staat zijn om de app zelf ook te bouwen. Bijvoorbeeld als ze niet Android of iOS willen draaien. Zolang dat geen mogelijkheid is wens ik de app niet te gebruiken.

Dat maak ik niet op uit het bericht, en tot nu toe vind ik in de broncode ook niks dat erop wijst dat je het niet gewoon zelf kunt builden en draaien.
Bij eerste start van de DigiD app doe je een enrollment met privégegevens. Op dat moment wordt er een key gegenereerd die op je device wordt opgeslagen. Er is dus geen reden om hardcoded keys te gebruiken.

[webhalla]

Sinds het digi-notar debacle van het Nederlandse Rijk (Iran kon certificaten van de Rijksoverheid uitgeven) is het voor deze autorisatie toepassing van belang dat de hele stack van cliënt tot en met de server openbaar en inspecteerbaar is om het vertrouwen een beetje terug te kunnen winnen.

[Mushroomician]

Het ministerie houdt nog steeds cruciale informatie geheim, zoals informatie over de infrastructuur, en het doet alsof ze hun verantwoordelijkheid nemen terwijl ze in feite hun eigen achterdeur verbergen. Dit is een gevaarlijke praktijk, "security by obscurity" is niet alleen onbetrouwbaar maar ook onverantwoord. De Nederlandse overheid moet eerlijk zijn over de beveiligingsrisico's en de nodige maatregelen nemen om deze op te lossen in plaats van deze te verbergen voor de publieke inspectie.

[Reactie gewijzigd door Mushroomician op 22 juli 2024 16:00]

[BugBlauw]

De backend code komt eind maart is de planning. Dus nog even geduld.

[HooksForFeet]

Het ministerie houdt nog steeds cruciale informatie geheim, zoals informatie over de infrastructuur

Welke informatie ontbreekt er dan precies, en waarom is die cruciaal?

[Mushroomician]

Het “geheim” houden van informatie over de infrastructuur, zoals beschreven in het artikel, is "security by obscurity", een praktijk waarbij er vertrouwd wordt op het feit dat aanvallers niet weten hoe een systeem werkt of waar zijn zwakke plekken zijn. Dit is echter een onbetrouwbare manier van beveiliging omdat aanvallers uiteindelijk de informatie kunnen achterhalen of raden. Het is veel veiliger en effectiever om de infrastructuur openbaar te maken en de zwakke plekken te identificeren en te versterken. Het verbergen van de infrastructuur kan een illusie van veiligheid creëren, maar kan in werkelijkheid gevaarlijke beveiligingslekken verbergen.

[HooksForFeet]

Dat vroeg ik echter niet. “Informatie over de infrastructuur” is nogal een ruim begrip. Je hebt je hier duidelijk in verdiept, aangezien je de ontbrekende informatie “cruciaal” noemt. Welke informatie over de infrastructuur ontbreekt er dan precies, en waarom beschouw je die informatie als cruciaal?

[Mushroomician]

Ik zou zeggen dat elk stuk van de broncode cruciaal is. Immers kan zich overal een lek voordoen.

Maar juist omdat dit nu met S voor security is bestempeld wekt dat de indruk dat het dus cruciaal is omdat daar de risico’s zitten zoals zij zelf al aangeven. M.a.w., ze zijn niet zeker van de veiligheid en verhullen potentiele kwetsbaarheden om te voorkomen dat de informatie publiek is. En daarmee los je niet het probleem op.

[Reactie gewijzigd door Mushroomician op 22 juli 2024 16:00]

[HooksForFeet]

Maar welk stuk is het dan? Want tot nu toe zie ik alleen keys die met S zijn vervangen. Je kan toch niet argumenteren dat de precieze key cruciaal is om te kunnen zien of het systeem veilig is. Welke details ontbreken er verder nog?

[Mushroomician]

Ik heb de stukken niet bekeken maar ik heb dit uit het artikel opgemaakt:

Enkele fragmenten blijven geheim, omdat ze bijvoorbeeld een beveiligingsrisico kunnen vormen. Deze fragmenten zijn vervangen door de letter S, voor security.

Het zijn dus geen fragmenten maar ‘keys’ ? Is dat wat je zegt?

[HooksForFeet]

Wat ik tot nu toe zie ja. Maar het is toch op z’n minst opmerkelijk dat je het over cruciale informatie hebt maar tegelijkertijd niet weet om welke informatie het gaat?

[Mushroomician]

Het kan bijna niet anders als ik het artikel mag geloven.

Het gaat volgens het artikel om informatie over de infrastructuur. Waarom zou het anders weggehaald zijn als het insignificant is?

[HooksForFeet]

Omdat het puur om specifieke API keys en AppStore urls gaat, meer niet.

[Mushroomician]

Dan is de het artikel onjuist. Ik citeer:

Alleen bepaalde gevoelige informatie, zoals informatie over de infrastructuur, blijft geheim.

Los daarvan kun je die keys natuurlijk zo uit de apk vissen of met een mitm…

[Reactie gewijzigd door Mushroomician op 22 juli 2024 16:00]

[HooksForFeet]

Technisch gezien kan je die keys en urls ook beschouwen als informatie over de infrastructuur. Ik denk eerder dat jouw interpretatie van het artikel onjuist was.

Of je die keys uit de apk kan halen ligt helemaal aan hoe de app gecompileerd wordt, dat kan je hier niet op baseren. Voor MITM aanvallen zijn natuurlijk ook verschillende beveiligingsmechanismen.

[kabelmannetje]

Gelukkig gooiden ministries waar ik security voor deed, niet hun infra op internet. Moet niet gekker worden zeg. Als je al een vector van een 0day krijgt, ligt meteen de complete security van een netwerk open. Netwerken zijn bewust onbekend, zodat indringers fouten maken en ze te ontdekken zijn.

[MSteverink]

...Enkele fragmenten blijven geheim, omdat ze bijvoorbeeld een beveiligingsrisico kunnen vormen. Deze fragmenten zijn vervangen door de letter S, voor security. Andere fragmenten waaruit persoonsgegevens van ontwikkelaars te herleiden zijn, zijn vervangen door de letter P, voor privacy...

De zelf-gecompileerde versie van app kan dus nooit gelijk zijn aan de gedownloade versie. hoe kun je dan vaststellen dat de app daadwerkelijk is gebaseerd op die broncode?

[Herko_ter_Horst]

Dat kun je toch al niet, zelfs al was de code 1-op-1 gelijk. Om van de broncode een werkende binary te maken zijn heel veel stappen nodig en als er ook maar ergens een dynamisch dingetje wordt toegevoegd aan de binary (een timestamp, een build-nummer, o.i.d.) ga jij dat nooit kunnen reproduceren.

[laurxp]

Het is in de open source wereld langzaam maar zeker steeds gebruikelijker om deterministische builds te gebruiken.

Als de build niet reproduceerbaar is, kan je ook niet garanderen dat een aanvaller stiekem een binary met een backdoor online zet. Dit is een vrij serieus gat in de supplychainbeveiliging. Distros zoals Debian laten inmiddels al zo'n 90% van de packages op een reproduceerbare manier compileren.

[MSteverink]

Je hebt gelijk. Maar als je de broncode kunt omzetten in een werkende app weet je precies, of zou je precies kunnen weten, hoe de app werkt. Daar zit de winst.
Maar je kunt nu nooit controleren of de app niet minder of meer functionaliteit heeft dan de broncode. Dus, tenzij ik iets over het hoofd zie, dit is schijn-openheid.

[Herko_ter_Horst]

Zolang je geen 100% inzicht heb in *alle* fases van het bouw- en deploymentproces, kun je nooit garanderen dan de binary die je uit de app store haalt, hetzelfde functioneert als een door jezelf gebouwde binary. En zelfs als je dat voor de app wel zou kunnen, dan kun je dat voor back-end nog niet.

Dat geldt voor dit geval en in het algemeen voor alle open source projecten.

[Reactie gewijzigd door Herko_ter_Horst op 22 juli 2024 16:00]

[GertMenkel]

Ik heb er kort doorheen gebladerd en de geheime componenten lijken API-keys van externe services, een stel URL's en een wachtwoord te zijn.

Aangezien het project in C# geschreven is, verwacht ik dat iemand die zelf zo'n versie wil bouwen niet te veel moeite zal hebben met het vinden van die gegevens in de binary die je uit je app store haalt. Er zal vast een laag obfucatie overheen gaan maar samen met de code zal het geen buitengewone kunst vereisen om de keys te vinden. Desnoods hang je Frida aan de app, kost wat meer moeite maar dan kom je er ook.

Of de broncode de app matcht is dan niet zo'n probleem, iedereen kan de versie gebouwd uit de open source versie pakken en gebruiken. Logius kan heel moeilijk doen over de code die ze met ons belastinggeld hebben geschreven maar op deze manier kun je een aardig eind komen als je de overheidsapp wantrouwt.

[HooksForFeet]

Dat kan je sowieso niet, ook al heb je exact dezelfde broncode en compiler.

[Krystman]

Haha Logius "wou" dit helemaal niet. Bugblue heeft dit moeten forceren via een woo verzoek..

[Rembert]

Staat inderdaad in de broncode zelf:

// De openbaarmaking van dit bestand is in het kader van de WOO geschied en
// dus gericht op transparantie en niet op hergebruik. In het geval dat dit
// bestand hergebruikt wordt, is de EUPL licentie van toepassing, met
// uitzondering van broncode waarvoor een andere licentie is aangegeven

[Reactie gewijzigd door Rembert op 22 juli 2024 16:00]

[CAPSLOCK2000]

"Meestribbelen" noemen ze dat bij mij op het werk. Doen alsof je meewerkt maar ondertussen de hakken in het zand zetten.
Nu geef ik ze wel gelijk dat transparantie in dit geval belangrijker is dan hergebruik maar dat zou geen keuze moeten zijn.

[RobertMe]

Maar hoe transparant zijn ze nu? Deze gepubliceerde broncode kan ook nep zijn. Of bewust andere algoritmes bevatten die niet werken met de echte server. Al dan niet in de zin van dat Digid oude als onveilig bestempele dingen gebruikt en dat deze gepubliceerde broncode de moderne wel nog als veilig beschouwde opvolgers gebruikt.

Bv als voorbeeld dat de echte app vol staat met het gebruik van md5 maar deze gepubliceerde broncode overal netjes sha256 of sha512 gebruikt.

Beetje vergelijkbaar met de situatie bij LastPass die pronken met hoe veilig alles is maar als je al 10 jaar klant worden je wachtwoorden alsnog onveilig opgeslagen, naar huidige standaarden, omdat de data nooit "geüpgrade" is.

[CAPSLOCK2000]

Maar hoe transparant zijn ze nu?

Meer dan voorheen, en meer moet je ook niet in mijn opmerking lezen.

Deze gepubliceerde broncode kan ook nep zijn. Of bewust andere algoritmes bevatten die niet werken met de echte server. Al dan niet in de zin van dat Digid oude als onveilig bestempele dingen gebruikt en dat deze gepubliceerde broncode de moderne wel nog als veilig beschouwde opvolgers gebruikt.

Zeker, dat is een van de redenen waarom hergebruik ook belangrijk is.
Maar als er /moet/ worden gekozen dan heb ik liever dat ze focussen op transparantie dan op er iets van maken wat ik in mijn eigen projecten kan gebruiken.

Een van de redenen waarom ik schreef "hergebruik (...) zou geen keuze moeten zijn" is juist zodat mensen het zelf kunnen compileren en niet hoeven te vertrouwen op precompiled versie. Het mooist zou het zijn als het een 'reproducible build' is zodat je bit-voor-bit dezelfde uitkomst krijgt en je bv checksums kan maken en controleren.

[Soldaatje]

Er zal wel wat werk voor nodig zijn geweest voordat het openbaar kon. En een paar audits erbij. Het is niet om te lachen als digid hierdoor gehackt zou kunnen worden.

[Schway]

Tuurlijk niet, als je al FTE te kort komt om je dagelijkse dingen te doen, en er komt nog meer bij op je bord, dan wil je dat extra spul niet doen als het niets oplevert.

Helaas voor Logius maakt het niet uit of het nut heeft of niet, met een woo verzoek moeten ze het doen en nu ze al dat werk in hebben gestoken hoop ik maar dat ze er iets aan gaan hebben behalve een kop op wat sites.

[BugBlauw]

Dat klopt.

[bonyuri]

Twee interessante code fragments:

https://github.com/MinBZK...mmon/Helpers/UrlHelper.cs

Als een URL start met "https://mijn." en eindigt met "digid.nl" dan wordt dat als een valide URL gezien?!
Het is gelukkig enkel om built-in URLs te controleren, maar toch

https://github.com/MinBZK...OS/Services/NFCService.cs

[HooksForFeet]

Op zich is het valide om bij interne gegevens (zoals ingebouwde URLs) lichtere validatie toe te passen dan bij externe gegevens.

[DigitalBrains]

Maar alsnog hadden ze moeten controleren dat het eindigt op ".digid.nl", die extra punt is nogal belangrijk en triviaal om toe te voegen. Anders matcht dus ook "https://mijn.ditisduszekernietdigid.nl/". Vreemd stukje code. Wel de punt op het end van mijn, maar waar-ie ertoe doet ontbreekt-ie.

[P1nGu1n]

Zo te zien is het een Xamarin app, volledig geschreven in C#. Hiermee kunnen ze code delen tussen de Android en iOS app, op wat platformspecifieke zaken na.

[NKR]

Klopt, Digid wordt ook in development presentaties gebruikt om te laten zien dat MAUI (wat de opvolger is van Xamarin) geschikt is voor productie

[CAPSLOCK2000]

Op dit moment is de gepubliceerde broncode een momentopname, schrijft staatssecretaris van Digitalisering Alexandra van Huffelen. DigiD-agentschap Logius wil later ook nieuwe versies openbaar kunnen maken, maar hiervoor moet de software eerst geschikt worden gemaakt. "Daarnaast moet de organisatie klaar zijn om deze andere manier van werken te ondersteunen", schrijft de staatssecretaris. "Het kost tijd om dit zorgvuldig te kunnen doen, naast de dagelijkse werkzaamheden om te zorgen dat DigiD veilig en betrouwbaar blijft werken."

Ik snap dat lastig is om dit met een bestaand stuk software te moeten doen. Ik ben een beetje te bang dat het wel eens lastig en duur zou kunnen zijn om dit herhaaldelijk te blijven doen als er steeds opnieuw stukken moeten worden weggelakt. Ik vind dat overheidssoftware altijd open zou moeten zijn. Zowel uit het principe dat de overheid transparant moet zijn, als het principe dat het belastinggeld betaald is en dus van ons allemaal, als uit het principe dat alle software transparant en aanpasbaar zou moeten zijn.
Ik hoop dus dat toekomstige projecten vanaf het begin zo worden opgezet.

[laurxp]

In de praktijk valt het wel mee.

Op dit moment zie je dat ze bijvoorbeeld logintokens moeten uitlakken omdat ze midden in de sourcecode staan. Het niet héél veel werk om dat te verplaatsen naar een compile-time environment variable, of wellicht een specifiek sourcebestand dat alléén gevoelige code bevat.

Het lastigste is vaak het vinden van de dingen die je moet weglakken, en dat hebben ze nu al een keertje gedaan, waardoor aanpassingen die toekomstig weglakken overbodig maken eenvoudig te doen zijn.

[w3news]

Het moet in je proces komen, eerste keer is het vooral een ding, daarna wordt het steeds makkelijker, je houdt er rekening mee.
Als je dingen moet blijven weg halen doe je denk ik iets structureel fout.

[jesha]

Ben ik de enige die dit amateur werk vind?
Static httphelper.
Navigation service die elke viewmodel zelf moet registreren.
DependancyService? Hoe bedoel je DI?
Leert niemand meer wat SOLID is?

Of deze app is alweer jaren oud of ik twijfel echt aan de competentie van de mensen die hieraan werkten en het geld wat erbij gemoeid is gegaan…

[Reactie gewijzigd door jesha op 22 juli 2024 16:00]

[GertMenkel]

De app is een jaar of zes uit, als dit nog steeds dezelfde code base is dan snap ik het wel.

Op zich vind ik het wel meevallen, het ding hoeft niet zoveel te doen. Het is een QR-codescanner met een keypad, de daadwerkelijke security (sleutels genereren en ondertekenen) kan de hardware van je telefoon namelijk al.

Mijn ervaring met Xamarin Forms is dat dit soort dingen nou eenmaal niet uit de doos meekomen en dat je een hoop zelf moet doen. Misschien dat een nieuwere versie dit wel allemaal kan, maar ik zie ook niet echt waarom ze een hoop moeite moeten steken in een rewrite van het ding als de app prima werkt. Ja, ze kunnen het hele ding naar MAUI herschrijven maar waarom zou de overheid daar geld voor uittrekken?

[jesha]

Heeft niks met xamarin te maken. Omschrijven naar MAUI zou dan niks veranderen.
Tevens is MAUI ook een gedrocht… maar dat is een ander onderwerp.

Ik zie hier veel ontwikkelprincipes niet in terug dat baart zorgen. Er is een reden waarom men zegt dat voor de staat werken is als met pensioen gaan.

[KaleKabel]

En flink grote functies met diep geneste control statements. Drama om te onderhouden deze code..

[Harm_H]

Goede eerste stap. C# gebeuren en zeer beperkte functionaliteit?