Ik draag mijn steentje bij door het hele onding niet te gebruiken. Ondersteunt u mij daarin, staatssecretaris?

Hoe?

Pas op Erik; geen obstinate reacties richting hogere goden, want voordat je het weet, sta je op straat!

Klik op het slotje, en kijk of de certificate chain uitkomt bij de "Staat der Nederlanden". Is dat niet het geval, is het uiterst verdacht en zou ik niet inloggen.

- Brieven met DigiD codes die werden onderschept.
- Systemen van gemeentes die lek waren (en misschien nog steeds zijn).
- Gebrek aan strengere inlog controles (2 way authentication). Het is mogelijk maar niet verplicht en alleen via SMS.
- Zeer moeilijke procedures als er eenmaal fraude is gepleegd met jouw DigiD.
- En nog veel meer...

En dan de burger gaan vragen om de boel te controleren? Hoe kan de burger nou zorgvuldig met zijn gegevens omgaan als verschillende instanties de regels aan hun laars lappen? Er wordt teveel bij de burger gelegd als je het mij vraagt.

zolang het ncsc anoniem melden niet mogelijk maakt zal ze minder informatie binnenkrijgen
dit geldt ook voor banken
ze doen zichzelf en de maatschappij daarmee tekort

Volgens mij is het NCSC een van de eerste instanties die gebruik maakt van Non-disclosure Agreement. Even ter zijde.

Ik vind het een goed idee van mevr. Klijnsma, maar wat mij steeds verbaasd is dat we vaker burgerparticipatie verzoeken krijgen. Opzich, is dit niet vervelend maar wat we ervoor terug krijgen is af en toe kwalitatief uitermate teleurstellend! Ik meen te herinneneren dat ik ergens gelezen had dat er een nieuwe variant zou komen ipv DigID.

Anyhoe, als wij de burger, het voor het zeggen hebben, wat moeten al die duur betaalde adviseurs doen?

De burger MOET meehelpen, dat is immers de participatie samenleving waar de VVD en PvdA naartoe willen uiteraard.

Is dat niet die mevrouw die een tijdje terug ouderen adviseerde om een eigen Moestuin te beginnen ?

Ik doe m.i. exact waar Jetta Klijnsma -naar verluidt- om vraagt. De kop van het artikel luidt:
Klijnsma: burger kan meehelpen bij veilig DigiD-gebruik.
Uiteindelijk ben ook ik een burger. Mijn ouders zijn dat ook, maar die snappen niks van wat in deze pagina staat. Ik denk dat ik, vanuit mijn vakgebied, een bijdrage kan en moet leveren.

Wellicht dat de manier waarop ik dat doe niet iedereen kan bekoren. Echter, bijv. via "responsible disclosure" bereik ik geen lezers van security.nl waar ik kennis mee probeer uit te wisselen zodat zij, maar ook ik, daar wijzer van worden. En wij uiteindelijk veiliger systemen kunnen realiseren en onderhouden.

Overigens vind ik dat zaken als achterstallig onderhoud, ondoordachte ontwerpkeuzes (zoals digid.nl versus digid.overheid.nl), totaal niet testen (mixed content in https pagina's en opnemen van http links naar sites die https ondersteunen) en het niet opnemen van "O=Rijksoverheid" in het DigiD certificaat, niet onder "responsible disclosure" vallen. Ik ben geen gratis tester, consultant of puimruimer. Lekken die een beheerder/eigenaar/ontwikkelaar redelijkerwijs over het hoofd kan zien, en die ik (al dan niet toevallig) ontdek, meld ik wel via responsible disclosure.

Maar wellicht schiet ik door met mijn bijdragen, en moeten we weer eens een thread aan ethiek wijden...

En de aanvallers snappen de zwakheden van de mensen die erin tuinen weer uitstekend, die moet je ook meenemen in je begripskader. En softwaremakers moeten op een heel andere manier rekening houden met die zwakheden dan ze nu doen.

Een voorbeeld dat ik maar opnieuw blijf meemaken illustreert het uitstekend. Ik noem uit mijn hoofd de URL van een website aan iemand. Die persoon opent zijn webbrowser, heeft de Google-zoekpagina als homepage ingestelt, en tikt de URL niet in het URL-veldje van de browser maar als zoekargument bij Google in, om vervolgens op de eerste link te klikken zonder maar te kijken of het wel de gezochte website is. Als ik erop wijs dat ze dat beter in het URL-veldje van de browser in kunnen tikken krijg ik een blanco blik terug, ze snappen helemaal niet waar dat URL-veldje voor dient en vinden het makkelijker om alles altijd via Google te doen. En tot overmaat van ramp zien ze meestal ook niet in waarom ze iets lastigs erbij zouden moeten leren, ze missen het soort nieuwsgierigheid naar hoe dingen werken dat veel IT'ers volop hebben en het werkt toch?

Wat is een typische reactie van softwarebouwers, of misschien moet ik UI-ontwerpers zeggen (of die vreselijke term UX-designer)? Die concluderen dat dit te moeilijk is voor "de" gebruiker en maken het "overzichtelijker" met een gecombineerd URL- en zoekveld in de browser. Je hoeft je niet meer druk te maken over wat je waar moet intypen, dat lost de software wel voor je op. Dat zou in dit geval nog wat oplossen ook: als de software herkent dat het een URL is slaat het de zoekmachine over en gaat het rechtstreeks naar de website, wat het risico vermindert dat de gebruiker op het verkeerde zoekresultaat klikt. Maar bij het minste en geringste typefoutje slaat het om in een nadeel: je krijgt resultaten terwijl je die niet zou moeten krijgen.

Ik ben me in toenemende mate gaan ergeren aan dit soort behulpzaamheid van softwarebouwers. Door voortdurend te versluieren hoe iets eigenlijk werkt wordt die computer namelijk niet begrijpelijker voor veel mensen maar juist steeds magischer. Qua operationeel leren (welke handelingen moet je verrichten om tot een resultaat te komen) wordt het makkelijker, maar qua begripsvorming is het een achteruitgang.

Toen ik met computers leerde werken waren ze eenvoudig. Je had bestanden en directory's waar die bestanden in stonden. Je had programma's en databestanden, en de programma's dienden om databestanden te verwerken. Dat is enorm verwaterd. Wat ooit databestanden waren kunnen tegenwoordig ook een zelfstandige applicaties zijn, denk aan Word- en Excel-macro's. Allerlei programma's en acties worden automatisch gestart zonder dat je als gebruiker nog goed zicht hebt op wat er gebeurt, denk aan autorun en aan drive-by-downloads. Directorystructuren zijn welhaast onbegrijpelijk geworden door alle virtuele mappen die tegenwoordig voor van alles en nog wat worden aangemaakt. In het internet/cloud-tijdperk worden zaken nog verwarrender gemaakt doordat steeds onduidelijker is waar een applicatie eigenlijk draait en waar de data zich eigenlijk bevindt.

Maar die oude eenvoud is nog steeds de basis van hoe nu dingen werken. Er zijn alleen allemaal abstractielagen en automatismen overheen gegooid die in mijn perceptie vaak zijn ontstaan om dingen voor mensen die het niet direct snappen laagdrempeliger te maken. Maar het gevolg is dat computersystemen juist steeds magischer en moeilijker te doorgronden zijn geworden. En dat allemaal door het rare idee dat een van de meest veelzijdige machines die een mens in huis haalt met een kleinere gebruiksaanwijzing dan een nieuwe stofzuiger moet worden geleverd, omdat de norm en de mythe is dat alles intuïtief begrepen moet worden.

De aanvallers snappen de verwarring die onder veel mensen heerst over hoe computers werken waarschijnlijk aanzienlijk beter dan die mensen zelf. Het is verdomd moeilijk om die verwarring te bestrijden zolang software wordt ontworpen op een manier die de eigenlijke werking van iets verdoezelt in plaats van verduidelijkt.

Ik verwacht niet dat ik het ga meemaken, maar ik zou ontzettend graag zien dat de eenvoud weer terugkeert, dat een directory gewoon een directory is (en waarom zouden mensen dat niet kunnen snappen, ze stoppen hun sokken en onderbroeken toch ook in verschillende laden die ze terug weten te vinden zonder een virtuele lade die ze allebei bevat of juist verder scheidt), een programma gewoon een programma en een databestand gewoon een databestand. Documenten met macro's kunnen dan als bundels van programma+data gepresenteerd worden, waarbij onmiddelijk duidelijk is dat het iets anders is dan alleen een document, en waarbij het altijd eenvoudig moet zijn om alleen de data in de tekstverwerker of zo te openen.

Door de concepten eenvoudig te houden en ze in user interfaces voortdurend te benadrukken in plaats van te verdoezelen verhoog je de kans aanzienlijk dat digibeten begrip gaan opbouwen van hoe die computer eigenlijk werkt. En als dat geleidelijk aan beter verankerd raakt in het collectieve bewustzijn wordt het ook makkelijker voor de gemiddelde digibeet - die dan veel minder een digibeet is dan nu - om te herkennen wanneer er iets niet klopt. Zolang de "zal ik dit voor je doen, dat snap jij toch niet"-mentaliteit in software zit voedt die software mensen op om op "zal ik dit voor je doen"-achtige benaderingen door kwaadwilligen in te gaan.

>
En: in de headers geeft de server zelf aan: Apache/2.2.3 (CentOS). Ik hoop dat dit niet klopt: deze header zou hard-coded kunnen zijn om aanvallers voor de gek te houden. Zo niet, die header kwam je begin 2008 al tegen (zie http://articles.slicehost.com/2008/2/6/centos-installing-apache-and-php5), en Apache httpd v2.2.3 is echt oud (zie http://httpd.apache.org/security/vulnerabilities_22.html).
<
En dat apache-versie nummer zegt dus helemaal niets over de mate waarin security-updates zijn geinstalleerd. CentOS e.d. backporten security-patches naar oudere vesies. Versie 2.2.3 zegt alleen iets over de functionaliteit van de software.

Ik ben het helemaal eens met jouw bijdrage, maar haal slechts deze regel aan (ik raad iedereen aan bovenstaande bijdrage te lezen).

Inderdaad, voorbeelden te over. Waarom standaard bestandsextensies verstoppen? Waarom heeft elke webbrowser een eigen methode om een "slotje" te laten zien bij https? Waarom in vredesnaam standaard transparante vensters? (in MSIE is een URL-balk, waar vaak al niet veel van over is, soms nauwelijks leesbaar). En zo kan ik nog heel lang doorgaan.

Daarom schreef ik het met terughoudendheid. Ik weet dat dit geldt voor LTS (Long Time Support) versies van bijv. Ubuntu en Debian.

Maar of dit ook voor CentOS geldt? Is dat niet het beta kanaal van Red Hat? Is het verstandig om een dergelijk OS in te zetten voor een productieserver, notabene waar het gaat om potentieel uiterst vertrouwelijke gegevens? Zie bijv. de discussie in http://linux-beta.slashdot.org/story/11/10/30/203242/how-can-i-justify-using-red-hat-when-centos-exists. Overigens levert SSLLabs het bewijs dat de server niet bij is qua patches, want het POODLE lek is nog aanwezig (dat nog even los van de deplorabele staat van de SSL/TLS configuratie).