Integriteitoverheid.nl slaat wachtwoorden in plain text op

De website Integriteitoverheid.nl blijkt vatbaar te zijn voor sql-injectie. Hierdoor kon de hele database worden uitgelezen, waarbij ook usernames en wachtwoorden toegankelijk waren. Diverse wachtwoorden waren in plain text opgeslagen.

De website Integriteitoverheid.nl is in handen van het Bureau Integriteitsbevordering Openbare Sector. Deze overheidsinstelling is opgericht om 'het publieke domein te stimuleren en ondersteunen bij het opzetten en implementeren van integriteitsbeleid'. Volgens de eigen website werken er acht mensen bij de organisatie.

Tweakers.net ontving van hackers Thaxdevil en Goo echter de tip dat de website van het BIOS op het gebied van integriteit geen hoge ogen gooit. Via sql-injectie bleek de database van de hele website toegankelijk. De database bevat onder andere de nieuwsbriefadministratie en een tabel met gebruikersgegevens. Saillant detail is dat de wachtwoorden in deze tabel in plain text zijn opgeslagen en, op een aanpassing van o in 0 en i in 1 na, identiek zijn aan de username.

Inmiddels is het lek in de site gedicht, bevestigt een woordvoerster van de organisatie tegenover Tweakers.net. Het bureau neemt ook andere delen van de site onder de loep om zich ervan te verzekeren dat er geen kwetsbaarheden over het hoofd zijn gezien.

Update 15.20 uur - De website lijkt nu geheel offline te zijn gehaald. Mogelijk is gebleken dat nog niet alle sql-kwetsbaarheden waren verholpen, zoals in de reacties door diverse tweakers wordt ervaren.

Reacties (206)

http://www.integriteitove...ils/dilemmatraining.html'
Jaja gedicht... (dilemmatraining).

Edit: volgens mij is de site nu offline.
Maar goed was nog lek; http://img52.imageshack.us/img52/9476/overheid.png

[Reactie gewijzigd door Pieter op 4 augustus 2011 15:12]

Aan de query te zien wordt de input nu een keer of vier geëscaped. Ja, dat is ook een vorm van beveiligen.

De query zegt volgensmij niet zoveel.

Er gebeuren _hele_ rare dingen. Bij andere queries kon het voorkomen dat er een 'Unknown column dilemmatraining.html" kwam, dus er stonden helemaal geen quotejes meer om die dilemmatraining.html in de IN. Er gaat bij hun code om de query op te bouwen dus iets heel erg serieus mis.

faalhazen èn jokkebrokken dus

Nu wel zo te zien, althans, de site timed out.

hehe, alle tweakers zijn nu tegelijk aan het kijken of de sql injection nog steeds werkt

Het grote probleem is dat bedrijven (ook in het gebied van de IT) een AA status worden aangereikt door de overheid. Dit betekent dat alleen zij opdrachten kunnen vervullen voor de overheid.

Het probleem is, is dat deze bedrijven in de jaren 80 en 90 een AA status zijn aangereikt. Deze bedrijven zijn sindsdien heel rijk geworden en hebben geen enkele ambitie gehad om zichzelf te verbeteren. Hun codestandaarden liggen ver, ver onder de normale standaarden die gehanteerd worden in de industrie.

Dat blijkt maar weer eens uit de SQL-injectie mogelijkheid. Het voorkomen van deze exploit behoort toch tot een van de basisvaardigheden wanneer men met SQL databases werkt.

Wat een onzin. Alles boven een bepaald bedrag bij de overheid moet worden aanbesteed, inclusief IT-onderhoud en nieuwe websites.

helemaal correct! Zo zit de wereld in elkaar.

Wachtwoorden in plain text opslaan.

Dat is net zoiets als je pincode op je pinpas schrijven.

Integriteitoverheid.nl

Inmiddels is het lek in de site gedicht.

Was de webapplicatie lek dan? Of de database?

Mogelijk is gebleken dat nog niet alle sql-kwetsbaarheden waren verholpen

Waarschijnlijk was geen enkele kwetsbaarheid afgedekt. Waarschijnlijk lag de firewall er ook uit (want hoe anders kun je ongemerkt een database aftasten?), en was er een standaard installatie van een database applicatie en was het wachtwoord admin1.

[Reactie gewijzigd door mrlammers op 4 augustus 2011 17:17]

Waarschijnlijk lag de firewall er ook uit (want hoe anders kun je ongemerkt een database aftasten?), en was er een standaard installatie van een database applicatie en was het wachtwoord admin1.

Dit hoeft niet eens. Laat de website zelf de database connectie opzetten en wat "aangepaste" queries uitvoeren. Op wat rare requests na in het access log van de server zie je er niks van. Het is helemaal niet nodig om een remote connectie met de db server te maken (en daarbij de gebruikersnaam en het wachtwoord te weten).

Dat is net het hele punt van SQL injection. Doordat de site lek is kun je de queries zo vanuit de browser manipuleren. Een simpel voorbeeld, ik heb dit in PHP staan:
$select = "SELECT id, title, content FROM pages WHERE id = '" . $_GET['page'] . "'";
$result = mysql_query($select);
while($row = mysql_fetch_assoc($result))
{
echo '<h1>' . $row['title'] . '</h1>';
echo $row['content'];
}

De pagina wordt dan dus opgevraagd middels pagina.php?page=1. Doordat er geen validatie en escaping plaatsvind op $_GET['page'] kun je dus zo de query manipuleren. Maak je pagina.php?page=1' ervan (met quoteje), krijg je (standaard) van PHP een warning dat de param van mysql_fetch_assoc() geen resource (query resultaat) is. Dit geeft dus al een enorme hint weg voor de hacker. In sommige gevallen is het zelfs zo erg dat er controle plaatsvind of de query gelukt is, en als dat het niet geval is wordt mysql_error() (error van de database) weergegeven en soms wordt daarnaast zelfs nog de volledige query geprint (hallo... hoeveel informatie wil je kwijt geven? en een normale gebruiker heeft er niet eens iets aan).

Door bovenstaande aanvraag aan te passen naar pagina.php?page=1' OR 1=1 krijg je alle pagina's te zien (1=1 is altijd waar, dus alle rijen worden opgehaald). Maar de leuke dingen beginnen pas als je met UNION gaat spelen. Met UNION kun je de resultaten van twee SELECT queries samenvoegen. Door vervolgens een tweede SELECT te doen van de INFORMATION_SCHEMA.COLUMNS tabel is het heel eenvoudig om de volledige database structuur op te halen (SELECT TABLE_NAME, GROUP_CONCAT(COLUMN_NAME) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA=DATABASE() GROUP BY TABLE_NAME). Het enige "probleem" waar je nog tegenaan loopt is hoeveel kolommen je moet ophalen (bij UNION moeten beide SELECTs wel hetzelfde aantal kolommen hebben). Dit kun je echter gewoon proberen (UNION SELECT 1, 2, ... en op het moment dat je geen error krijgt heb je het juiste aantal kolommen te pakken, en weet je welke kolomnummers worden weergegeven en je dus moet gebruiken).

Door de aanvraag dus aan te passen naar pagina.php?page=-1' UNION SELECT 1, table_name, GROUP_CONCAT(column_name) FROM information_schema.columns WHERE table_schema = DATABASE() GROUP BY table_name krijg je dus een pagina waarop de namen van alle tabellen staan, met per tabel alle kolommen. Met deze informatie kun je vervolgens weer de UNION SELECT aanpassen naar een SELECT 1, username, password FROM users (bv.) en hoplakkee, alle gebruikersnamen met daarbij het wachtwoord.

Dit alles kan simpel worden opgelost door de $_GET['page'] te vervangen door mysql_real_escape_string($_GET['page']), daardoor voegt PHP een \ toe voor de ', leest de database de ' dus niet als "einde tekst" waardoor die hele UNION met toeters en bellen zo letterlijk in de id kolom moet staan.

[Reactie gewijzigd door RobertMe op 4 augustus 2011 19:01]

ach als je al slecht aan het programeren bent zet dan de errors uit... heeft niemand er last of baat van

Of je goed of slecht bent in programmeren, display_errors aan op de productie server is sowieso not done. Er zijn wel meer functies die een warning etc printen, ook al controleer je de return waarde. In tegenstelling tot mysql_query geeft pg_query volgensmij altijd een warning als de query mislukt. Dat geeft dan dus ook weer meteen een hint weg voor een (potentiele) hacker. Je moet (ongeacht kennisniveau) altijd zo goed mogelijk controleren op errors (mysql_query geeft niet voor niks false terug als de query mislukt). Bij een ervaren programmeur zullen dit misschien meer controles zijn dan bij een niet ervaren programmeur, maar als je (als niet ervaren) programmeur niet op fouten controleert, dan zul je dat als ervaren programmeur ook niet snel doen.

Mijn god, echt, ik zou me dood schamen.
Kom op hé, 2011 en dan nog wachtwoorden in plain text.
Dat zou echt niet moeten kunnen bij een overheidsinstantie.

Ik vind het meest beschamende eigenlijk dat de site openstaat voor SQL-injectie. Ook al sla je een hash op van wachtwoorden, dan nog is je zwakste schakel het feit dat men uberhaupt in die database komt, en dat wil je hoe dan ook voorkomen.
Als de database en de site gewoon goed dicht hadden gezeten, dan had het niet zoveel uitgemaakt dat de wachtwoorden in platte tekst zijn opgeslagen: niemand die erbij had gekund.

(Niet dat ik platte tekst als opslagvorm voor wachtwoorden wil promoten overigens.)

Er zijn dus daadwerkelijk opdrachtgevers die letterlijk zeggen dat wachtwoorden in plain text opgeslagen moeten worden zodat als de gebruiker het wilt, zij de wachtwoord kunnen opvragen...
(het is dan aan de opdrachtnemer om advies uit te brengen natuurlijk, maar als de opdrachtgever dan toch kiest voor plaintext, wat zal jij dan doen?)

Wat is er mis met een "Wachtwoord vergeten?" optie die nieuw wachtwoord instelt?

Het is in mijn ogen je plicht als webdeveloper om een veilig systeem te bouwen. Ik kan wel naar een garage gaan en zeggen dat ik de banden van een kinderfiets onder mijn auto wil, denk niet dat er veel garages zijn die dat voor me doen.

[Reactie gewijzigd door OkkE op 4 augustus 2011 16:02]

Je hebt niet gedefinieerd wat je bedoeld met "wachtwoord opvragen"

Als je bedoeld
"klant klikt op wachtwoord vergeten"
"klant vult email in"
"klant krijgt email met wachtwoord aanpassen link met unieke tag"
"unieke tag wordt zo opgebouwd"
"klant krijgt wachtwoord-aanpasscherm bij klikken link met unieke tag"
"klant moet nieuw wachtwoord invullen"


Dan is dat eventjes toch minimaal 2 schermpjes meer dan:
"klant klikt op wachtwoord vergeten"
"klant vult email in"
"klant krijgt email met wachtwoord"

Twee schermpjes welke je mee moet nemen in je offerte. En dus ook moet testen.


En klopt, een goede garage zal niet van die slechte wielen onder je auto hangen. Een beunhaas wel. En dat is dus waar je voor kiest als klant.

Omdat kinderfiets banden onder je auto niet kan, maar als jij vraagt voor een driedubelle turbo waarbij je auto een gevaarte op de weg wordt zullen er genoeg garages zijn die het met plezier erop zetten. Zeker als je genoeg betaald.

Dan maak Je een backend voor het bedrijf die de md5 kan uitlezen naar tekst. En ww opvragen kan ook gewoon met md5 hoor. Gewoon ff script schrijven die md5 omzet in tekst en deze bij uitvoeren mailen naar emailadres van opgevraagde.

Dan is jouw offerte gelijk 1000 euro duurder geworden en krijg je de opdracht niet

Als jij die code al op de plank hebt liggen, dan kost het je niets en hoef je dat ook niet door te berekenen
Hergebruik drukt de kosten! Helaas doen er niet zoveel bedrijven aan.

Al zal ik de code hebben, Dan nog zal ik moeten doorberekenen. Want het is extra functionaliteit welke getest, gedocumenteerd en ondersteund moet worden.

Mag ik de code om md5 naar plain text om te zetten?

<?php
header("Content-Type: text/plain");
echo "md5";
?>

Zoiets?

Ahum. de bedoeling van het hashen van wachtwoorden is juist.....inderdaad. Ga nou niet beweren dat je een gebruiker zijn eigen wachtwoord wil mailen. Jij geeft em een nieuwe of hij verzint zelf een nieuwe n.a.v. een link die jij hem stuurt. En that's that. Wat die gebruiker vervolgens zelf met dat ww doet (opschrijven, aan anderen mededelen et cetera) is zijn zaak; initieel correct faciliteren is het pakkie an van de bouwer van de applicatie.

Wat bedoel je precies met "md5 uitlezen naar tekst"?.

Even opzoeken in je rainbowtable? ;-)

Daarom gebruiken we ook liever geen MD5 meer maar kiezen we voor iets als SHA1, met een flinke korrel zout.

ik denk niet dat hij hashing begrijpt

md5 is nl onomkeerbaar( zonder bruteforce)
zou dat wel zo zijn is dat wereld nieuws

MD5 kan je met regenboogtabelletjes terugrekenen. SHA1 met een hashwaarde gebaseerd op een andere veld in je tabel geeft meer veiligheid, beter is om de hashwaarde op een andere mannier te generen.

MD5 uitlezen naar tekst... sorry, hier moet ik je toch echt even corrigeren hoor. In principe (brute force uitgezonderd) is MD5 en elke andere hash-techniek one way en dus niet terug te rekenen. Het is dus onmogelijk om "even" een script te schrijven om MD5 terug te rekenen naar plain-text.

Als wachtwoorden die in MD5 zijn opgeslagen worden opgevraagd via de wachtwoord vergeten knop krijg je altijd een nieuw wachtwoord. Daarom erger ik me ook altijd kapot als ik een wachtwoord krijg opgestuurd en ik krijg mijn oude password terug. Dan weet je direct dat de site niet goed met je gegevens omgaat... een dergelijke site kan ook altijd rekenen op een boze mail van mij!

Ik zou na de registratie de gebruiker zijn wachtwoord toesturen via $_POST.
En ik zou een wachtwoord vergeten systeem bouwen die een wachtwoord vervangt, in plaats van hersteld.

Ook zal ik de opdrachtgever wijzen op de risico's van het opslaan van wachtwoorden in plain text.

Ik zou na de registratie de gebruiker zijn wachtwoord toesturen via $_POST.

Uhhh wat?
$_POST heb je enkel in PHP als een variable waarin alle post-velden zitten, je kunt niet echt een post request terug gaan sturen, daar zijn browsers niet op gebouwd.
Als je erop doelt dat je het form een post waarde in het method attribuut meegeeft ben je nou ook niet bepaald per definitie veilig bezig. Goed, het wachtwoord staat dan niet in je URL geschiedenis aangegeven.. het gaat nog steeds in plain tekst over de lijn. Als je het goed wilt doen zorg je ervoor dat er gebruik gemaakt wordt van een SSL (https) verbinding.

Wie zegt dat dit stukje software is geschreven in 2010/2011? MIsschien is de website wel nieuw maar het beveiligings stuk stamt nog uit 2000 ofzo. Niet dat het dan goed te praten is, maar mensen hebben altijd zo snel hun mening klaar terwijl ze niet eens de volledige context hebben.

Er staat nergens dat ik zeg dat dit stukje software in 2011 is geschreven.
Ik geef alleen aan dat ik vind dat het niet zou moeten kunnen dat er in 2011 wachtwoorden door een overheidsinstelling worden opgeslagen in plain text.
Ook al is het stukje software geschreven in 2000, de beveiliging hoor je altijd te updaten waar mogelijk.

Als ze beveiliging in 11 jaar tijd niet eens is doorgelicht mag de verantwoordelijke zich ook dik schamen imho...

doodschamen is nog de minst erge nasleep wat je kan hebben in dit verhaal.
een kwaadwillende zou identiteitsfraude kunnen plegen en zich voordoen als jou, dat is een kwalijke zaak imho.

Kom op hé, 2011 en dan nog wachtwoorden in plain text.
Dat zou echt niet moeten kunnen bij een overheidsinstantie.

Het kan nog veel erger
http://serverfault.com/qu...-the-information-he-wants

Dit soort dingen wordt niet in huis ontwikkeld, maar "in de markt gezet", ofwel aanbesteed. Dat wil zeggen dat de overheid een aantal offertes verzamelt, en de klus aan de beste kandidaat toekent. In de praktijk betekent het dat de goedkoopste aanbieder in 99% van de gevallen de klus krijgt, zelfs als de organisatie weet dat de betreffende aanbieder totaal incompetent is. Het schamele restje ambtenaren dat nog echt iets doet, in plaats van alleen maar externe partijen aanstuurt, is over het algemeen wel degelijk competent en begaan, en gewoonlijk ook goedkoper. Maar ja, in Nederland moet er steeds ambtenaren uit (die dan vervangen worden door externen voor het dubbele tot viervoudige tarief).

Veiligheid is nog steeds een groot issue op internet. alhoewel er vele vormen van beveiliging bestaan , is blijkbaar nog niet iedere computergebruiker er van op de hoogte hoe deze toe te passen. Dit derhalve is wel erg amateuristisch.

Denk dat als je 'nog' vervangt door 'toen was' je een stuk dichter bij de waarheid zit. Tegenwoordig zullen er bijzonder weinig 'echte programmeurs' (dus niet de buurjongen die zo handig is met de computer) zijn die die geen enkele vorm van encryptie of hashing toepassen bij het opslaan van wachtwoorden. Komt het een beetje te vaak voor in het nieuws en bij elke programmeren gerelateerde opleiding wordt hier ook flink op gehamerd.

Probleem is dat er vele duizenden/miljoenen systemen al jaren draaien en waar of niemand meer aan denkt of er geen geld wordt vrij gemaakt om de boel eens een keertje op te schonen. Ik weet dat er in in ieder geval 1 grote organisatie is in Nederland is waar dit laatste het geval is, ze zijn er al op gewezen dat het in feite gewoon wachten is tot het mis gaat.. maar een "dat doet toch niemand" mening hebben.

Als ik sommige reacties in dit topic lees, dan vrees ik dat je ongelijk hebt, en dat er zelfs op tweakers genoeg beunhazen rondlopen die dergelijke maatregelen niet zullen nemen tenzij daarom expliciet gevraagd wordt.

Was het maar zo dat in opleidingen erop gehamerd wordt
Beveiliging is een ondergeschoven kindje dat bijna geen aandacht krijgt

"Inmiddels is het lek in de site gedicht"
uuh volgens mij is het niet echt een lek, maar gewoon een open deur. Ook al moet het via SQL-injectie, wachtwoorden in plain text opslaan is héél, héél erg amateuristisch.

Wel fijn om te weten dat het systeem inmiddels minder kwetsbaar is.

mjah, niet echt dus... input validatie doen ze niet aan, prepared statements snappen ze ook niet..., sql in jection werkt nog steeds prima, dus volgens mij is er helemaal niets aangepast, of ze zijn zo incapabel dat ze denken dat ze het aangepast hebben.... maar eigenlijk is er niets gefixt.

SQL Injection? SQL?

???

* Gamebuster gaat verder RoR'en

[Reactie gewijzigd door Gamebuster op 4 augustus 2011 22:35]

Dat zulke programmeurs tegenwoordig nog bestaan. Het is al zo vaak in het nieuws geweest dat je zou denken dat een zichzelf respecterend programmeur het wel goed doet... Vooral bij de overheid.

De goedkoopste offerte krijgt de opdracht he. Dat je dan een beunhaas krijgt als je je eisen niet duidelijk hebt gesteld in je contract...

De goedkoopste offerte krijgt de opdracht he. Dat je dan een beunhaas krijgt als je je eisen niet duidelijk hebt gesteld in je contract...
Nee, dat is niet zo.
Geen persoonlijke aanval, maar kap nu eens met dat non argument.
Ja, pay peanuts, get monkeys, maar in het geval van uitbesteden zijn het een hele zwik argumenten die er toe doen.
Een ervan KAN prijs zijn , maar hoeft het niet te zijn.
Wat wel zo is, is dat je inderdaad troep krijgt als je de eisen niet goed stelt, maar dat kan ook bij een heel duur contract.
Recent voorbeeld was Crisis.nl
500.000 voor hosting , maar slechte specs, dus troep.
Was niet de goedkoopste.

bij aanbestedingen is in de meeste gevallen de prijs doorslaggevend, hoe hoog de idealen ook in woorden worden gebracht...

Sterker nog, dat moet ook bij overheidsaanbestedingen. Je stelt de specs samen inclusief kwaliteitseisen, iedereen biedt in, en blind wordt de beste gekozen op prijs. Als er nog allerlei andere vage, niet gespecificeerde zaken meespelen staat de deur wagenwijd open voor vriendjespolitiek en corruptie. "Ja, jullie waren 1000 euro goedkoper, maar bedrijf XYZ van mijn broer gooide er een zak Haribo bij en jullie niet, en daar houd ik nou toevallig enorm van".

[Reactie gewijzigd door Dreamvoid op 4 augustus 2011 16:35]

Dat moet helemaal niet bij overheidsaanbestedingen.
Er bestaan meerdere mogelijkheden voor aanbestedingen en laagste prijs is er slechts eentje.
Welke criteria gelden zijn gewoon bekend bij een aanbesteding en daarnaast is het mogelijk om gunningsbeslissing (met succes) aan te vechten.
Je hebt te maken met een (groot) aantal wensen/eisen en voor elk onderdeeltje kunnen er punten gescoord worden.
Prijs telt dan bijv in totaal voor 40% mee, kwaliteit voor 60%

In dit geval zou het dus kunnen zijn dat iemand zich strikt aan de wensen/eisen heeft gehouden en niets heeft gedaan qua encryptie omdat dat simpelweg geen onderdeel was van de wensen/eisen.
Niet voldoen aan de eisen betekent over het algemeen uitsluiting van inschrijving.

[Reactie gewijzigd door ninjazx9r98 op 4 augustus 2011 20:30]

als ik me werk niet goed doet, word ik ontslagen. als een programmeur zijn/haar werk niet goed doet, is het een bug die opgelost moet worden...

Zo makkelijk is het nu ook weer niet. Een architect bepaald hoe het netwerk en/of een applicatie beveiligd moet worden. Nu kan het zijn dat een architect heeft bepaald dat bepaalde veiligheid op een ander niveau plaatsvind, en zodoende moet de programeur de goedkoopste en makkelijkste oplossing kiezen. Daarna schrapt de klant het bovenliggende veiligheidsniveau uit kostenoverweging... en dan is het de schuld van de programmeur? dat kliknt niet helemaal kies..
Daarbij is er bij de oplevering ook niet goed getest.. een database check had het oplsaan van tekst passwords toch moeten zien..
Maar wat ik zeggen wil; er zijn er meer bij betrokken dan alleen programmeurs..

Ook al komt de opdracht van een project lead, een architect of functional analyst; de developer moet dit toch opmerken en aan de alarm bel trekken? Je kan nu ook niet gaan zeggen dat hij het niet gezien heeft, want een obfuscation door o's door '0' en i's door '1' te vervangen lijkt mij niet echt slim.
Voor mij ligt de fout hier wel degelijk bij de developer, die has desnoods het probleem moeten escaleren! Het is zelfs niet kort door de bocht, maar gewoon een grove fout!

En wie zegt dat hij dat niet gedaan heeft? Lijkt me niet dat je dat uit het artikel kan halen. Het is zelfs onmogelijk om een schuldige aan te wijze, we weten niet of het de opdrachgever of de opdracht nemer deze oplossing heeft gekozen.

Ik kan het moeilijk geloven dat niemand in de volledige chain-of-command hier geen probleem met had. Ik werk zelf als technical analyst in een Belgisch bedrijf, en als je hier met zo iets afkomt dan escaleren ze dit onmiddelijk naar de juiste personen, vaak security. Je gaat mij toch niet zeggen dat security met zo'n zaken akkoord gaat?

Het is misschien cru om te zeggen dat het de developer zijn fout is, maar ik zou de implementatie gewoon niet doen, of op de correcte manier maken! Ik geloof niet dat ze je als developer op de vingers gaan tikken omdat je iets non-secure beter hebt geïmplementeerd...

Als er niet in de requirements staat: "wachtwoorden moeten gencrypt worden volgens deze algoritme:" en "alle input moet opgeschoond worden"

je hoeft mensen ook niet uit te leggen hoe ze een paraplu moeten gebruiken of hoe ze moeten lopen. het lijkt me nogal vanzelfsprekend dat er een hoge mate van veiligheid gevraagd word in zo geval als deze.

Het gaat niet om mensen iets uit leggen. het gaat om dat je waar voor je geld krijgt en hoe goed je moet specificeren.

Het is helaas in de praktijk niet "vanzelfsprekend" om van uit te gaan dat alles goed verloopt, zeker als je in zee gaat met incompetente bedrijven.

Als jij als opdrachtgever aangeeft:
"gebruiker moet kunnen inloggen na registratie"
"gebruiker moet wachtwoord kunnen opvragen"

dan moet je niet aannemen dat je dan een product koopt die dit doet
"gebruiker moet kunnen registreren"
"het gekozen wachtwoord moet voldoen aan de volgende eisen"
"het gekozen wachtwoord en personalia wordt geencrypt volgens de volgende regels..."
... etc

Je hoeft niet in een contract vast te leggen wat vanzelfsprekend is. Een eis "het password moet tenminste 8 karakters zijn" is niet vanzelfsprekend en hoort in een contract thuis. Een eis als "webserver maakt uitsluitend gebruik van legale software" is wel vanzelfsprekend en hoeft niet in een contract. Zoals de reacties hier aangeven (samengevat:prutsers!) is bescherming tegen SQL injectie wel vanzelfsprekend, en hoeft het dus niet in een contract.

Daar in tegen moet "encryptie" wel in specificaties staan. Staat het er niet in dan hoeft het ook niet. Eigenlijk hoort dit thuis in de functionele specificaties net zoals hoe je NAW gegevens opslaat bijvoorbeeld (is gestandaardiseerd in een ISO aanbeveling).

Het is heel simpel, in opdracht staat bijvoorbeeld:
Wachtwoord moet opgeslagen worden in database bij gebruikersnaam.

Dat is heel wat anders dan:
Wachtwoord moet in onomkeerbare versleuteling worden opgeslagen op basis van standaard "xyz",

Moet je niet vergeten natuurlijk dat zowel opdrachtgever als opdracht nemer zich aan de wet moeten houden, en de wet bescherming persoonsgegevens stelt dat dingen als wachtwoorden en zeker NAW gegevens op een beveiligde manier zijn opgeslagen (lees encryptie , hashing). dit hoeft niet in het contract te staan (wel hoe, of anders is het de makers keuze)

NAW gegevens hoeven niet versleuteld te zijn. Sterker nog het kan je perfromance kosten om deze te gebruiken binnen andere toepassing zoals een datawarehouse. Wat veel belangrijker is om tabel/row security toe te passen aan de ene kant en je applicatie zodanig te schrijven dat je er met sql injecties niet bij kan komen.

Daarnaast is het aan te raden om een broker te gebruiken in plaats van directe database toegang. Het voordeel van een broker tussen website en database of applicatieserver is dat je daar en extra laag beveiliging kunt leggen.

Een programmeur (of bedrijf die programmeurs tewerkstelt) verricht handelingen voor een ander tegen betaling, en is dus een 'aannemer van werken'. Deze juridische kwalificatie houdt in dat de programmeur zich niet alleen moet houden aan de opgegeven specificaties, maar ook aan de zogenaamde 'regels van de kunst'.

Je kan heel wat boompjes opzetten over wat nu precies de 'regels van de kunst' inhoudt (bvb het encrypteren van wachtwoorden vooraleer ze worden opgeslagen lijkt mij geen absolute noodzakelijkheid, zij het wel zeer nuttig), maar als een website anno 2011 niet bestand is tegen SQL-injection, dan is er geen discussie mogelijk: de regels van de kunst zijn geschonden en de programmeur gaat in de fout, niet de opdrachtgever.

Amateurisme ten top.

SQL-injection beveiliging ok. Hebben ze vergeten te doen. knuppels.
Maar versleuteling van passwords en/of persoonsgegevens is niet een vanzelfsprekend iets, vooral als het het niet in de opdracht staat. Dat is iets at erin moet staan en gespecificeerd en er moet extra voor betaald worden. zo niet, dan wordt er geen extra aandacht aan besteed.
Mensen vergeten vaak dat een programmeur niet meer / niets extra's doet / mag doen dan waarvoor hij betaald wordt. Ook al wil hij wel, hij kan en of mag het sowieso niet. Als hij meer doet krijgt hij er toch niet voor betaald. En als hij wel meer doet en er gaat iets mis of de klant heeft er op/aanmerkingen over, hij is degene die dan op z'n lazer krijgt. Dus... doe niet meer dan wat er in je opdracht staat.

Je moet zeker wel aangeven of je dit wil. Als het goed is doet de uitvoerende van het contract PRECIES wat er in het contract staat. Staat hier niet in: encrypt de wachtwoorden, dan hoeft dit niet. Want de eis is nooit gesteld. Je kan wel zeggen dat het vanzelf sprekend is, maar waarom zou je meer doen als je maar voor weinig betaald krijgt?! Veel mensen denken zo omdat het goedkoper is, en tegenwoordig is alles om de centjes.

Er moet op z'n minst instaan: encrypt de wachtwoorden. En daarna HOE. Anders heeft de programmeur zelf te keuze.

Veel mensen die hier reageren hebben schijnbaar nooit een project hoeven opleveren waarin eisen stonden over hoe en wat. Je moet zeker aangeven wat je wil, anders laat je gaten voor de uitvoerende partij, en die zullen echt niet omdat je zo aardig bent extra werk op de hals halen. Vooral niet als er tijdslimieten zijn, en die zullen er zeker geweest zijn.

Veel mensen die hier reageren hebben schijnbaar nooit een project hoeven opleveren waarin eisen stonden over hoe en wat.

En jij hebt blijkbaar geen kaas gegeten van contractenrecht. Het is niet omdat je nog nooit problemen hebt gehad met jouw werkwijze dat deze ook perfect correct is. De specificaties zijn 1 ding, de regels van de kunst een ander. De programmeur moet beiden respecteren.

Hier in België speelt er elke dag op de radio een spot met als thema 'een advocaat, beter vroeg dan laat' - ik denk dat jij (als je zelf verantwoordelijk bent voor de oplevering van programmatuur) deze raad best ook even opvolgt om zo potentiële miserie uit de weg te gaan.

Je moet zeker wel aangeven of je dit wil. Als het goed is doet de uitvoerende van het contract PRECIES wat er in het contract staat. Staat hier niet in: encrypt de wachtwoorden, dan hoeft dit niet. Want de eis is nooit gesteld. Je kan wel zeggen dat het vanzelf sprekend is, maar waarom zou je meer doen als je maar voor weinig betaald krijgt?! Veel mensen denken zo omdat het goedkoper is, en tegenwoordig is alles om de centjes.

Je kunt natuurlijk altijd aangeven dat encryptie aan te bevelen is en dat je dat best in wilt bouwen voor bedrag X. Aan de opdrachtgever de keuze wat ie met de aanbeveling doet.
Natuurlijk de keuze wel vast laten leggen.

Onzin, je moet sowieso de gebruikte blokstukken aanhalen in de analyse, anders kan een programmeur heel de persistence layer gaan programmeren terwijl het de bedoeling was om bijvoorbeeld hibernate te gebruiken.

Dit is echter NIET vanzelfsprekend, daar sommige van deze blokstukken betalend zijn en geen enkele programmeur mag in een bedrijf gewoon even omdat hij/zij het goeddunkt gebruik gaan maken van andere betalende software/blokstukken.

Dit is een fout in de analyse, niet bij de eindprogrammeur. De analyst moet hier tijd voor inboeken en er voor zorgen dat er ook security aan bod komt. Dit is niet de taak van de programmeur.

Dit heeft ook een rede: als elke programmeur zijn eigen goeddunken verwerkt in code dan is deze niet te overzien en komen er net MEER bugs voor. Ook zorgt dit er voor dat niemand nog aan de code zal uitkunnen en het kostenplaatje om een bug op te lossen zal bijgevolg een stuk hoger liggen.

De eindprogrammeur kan enkel verantwoordelijk geacht worden indien in de use case stond "encrypteer het wachtwoord" of iets in die trend.

[Reactie gewijzigd door F!SH op 4 augustus 2011 15:45]

je klinkt als een programmeur die zijn straatje wil schoonvegen...

Als jij alleen wachtwoorden gaat encrypten als dat specifiek aan je gevraagd word, dan zal ik jou nooit een opdracht gunnen...

je klinkt als een programmeur die zijn straatje wil schoonvegen...

Als jij alleen wachtwoorden gaat encrypten als dat specifiek aan je gevraagd word, dan zal ik jou nooit een opdracht gunnen...

Ik probeer duidelijk te maken dat er een groot verschil is tussen goede softwareboeren en beunhazen.

Als ik zo'n opdracht zal krijgen, zal ik de requirements van encryptie zeker aangeven. Maar als de opdrachtgever (of de sales afdeling) er expliciet voor kiest om dat niet te nemen ondanks mijn waarschuwing, dan zal ik het ook niet uitprogrammeren nee.

Uiteindelijk ligt de keuze bij de klant (sales). En het enige wat ik kan doen is advies uit brengen.

helemaal juist kmf, hoe frustrerend het soms ook is.
In mijn ervaring zijn het juist overheidsinstanties (nee ik ga niet specificeren, 3x raden waarom niet) die helaas erg onverschillig met security omgaan; meestal met het argument dat het al duur genoeg is, dat het 'niets doet' (i.e. geen zichtbare functionaliteit heeft) of dat het de gebruikers frustreert vanwege d.m.v. strenge eisen aan een wachtwoord. kai!

Ik gebruik tegenwoordig dit soort nieuwsberichten als hulpmiddel om aan te geven dat er toch echt een deel van het budget aan security moet worden gespendeerd - men schrikt even maar dan heb je eindelijk contact.

Maar omgekeerd als een programmeur zomaar op eigen houtje beslist om wachtwoorden te gaan encrypten zal hij van mij weer geen opdracht krijgen

Imho hoort de programmeur wat vraagtekens neer te zetten bij de klant / analist als hij geen encryptie moet programmeren, kan hij wat voorstellen doen over hoe hij het zou encrypten. Maar moet hij niet op eigen houtje maar gaan besluiten wat te doen.

je klinkt als een programmeur die zijn straatje wil schoonvegen...

Als jij alleen wachtwoorden gaat encrypten als dat specifiek aan je gevraagd word, dan zal ik jou nooit een opdracht gunnen...

Je zal verbaasd staan hoeveel opdrachtgevers en gebruikers het op zijn minst irritant vinden als ze niet hun wachtwoord kunnen opvragen, maar alleen kunnen resetten.

Veel eindgebruikers denken dat de beveiliging alleen op "de website" hoeft te zitten en dat je dus niet de boel in de database hoeft te encrypten. En als ze al weten wat encryptie is dan is het nog maar zeer de vraag of ze begrijpen dat encryptie in de context van een salted MD5 hash betekent dat je alleen hashes kunt vergelijken en nooit de plain text kunt terughalen met 100% zekerheid.

Zelf zou ik het altijd opmerken als er niet expliciet om gevraagd wordt, maar het zou zeker niet de eerste keer zijn dat een opdrachtgever om plain text wachtwoorden vraagt. Ik zou de kwestbaarheden uit proberen te leggen van plain text wachtwoorden. Maar aan het eind van de rit betaalt de opdrachtgever, dus die bepaalt of er plain text wachtwoorden zijn of niet.

Ja.. Wat denk je.

Bedrijfje X zegt ik doe de opdracht voor 1000 euro. Plain text wachtwoorden en simpele forgot email en geen input checks.

Jij zegt ik doe de opdracht voor 2000 euro. Een wachtwoord encrypten is geen extra tijd, maar de procedure voor het wachtwoord te resetten is wel extra werk, het bijhouden van het aantal pogingen dat er met een verkeerd wachtwoord ingelogd werd in een bepaalde periode, etc.

En als de opdrachtgever geen kaas gegeten heeft van security in IT, dan kiest hij bedrijf X voor 1000 euro.

Wat moet je doen? Ik heb ook al webapps (als zelfstandig bedrijfje) gemaakt die naar functionaliteit niet naar mijn zin waren. Maar als de klant je een budget geeft en dat is op, dan ga ik niet op mijn eigen kosten allerlei extra toeters en bellen zitten maken.

Als je auto kapot is en de garagist zegt dat het 2000 euro kost om alles te maken en jij zegt "ik geef je 1000 euro om hem rijklaar te maken", wat verwacht je dan?

Of moet je elke opdracht weigeren die niet voldoet aan je eigen hoge eisen? Dat gaat niet in de echte-grote-mensen-wereld, je moet geld binnenkrijgen.

Dit is deels eenvoudig op te lossen door van informaticus een beschermd beroep te maken. In België kun je niet zomaar een slagerij openen, daar heb je een slagerdiploma voor nodig. Dus: geen IT werk zonder IT diploma.

Verder een wettelijke regel dat de bedrijven die de website uitbaten verantwoordelijk stelt voor gegevensverlies van klanten door niet afdoende security. (zoiets bestond toch net?)

@Fastman:

Dit is deels eenvoudig op te lossen door van informaticus een beschermd beroep te maken. In België kun je niet zomaar een slagerij openen, daar heb je een slagerdiploma voor nodig. Dus: geen IT werk zonder IT diploma.

In de praktijk is er jammer genoeg geen noodzakelijk verband tussen vakbekwaamheid en een IT-diploma... (integendeel soms).

Dit is deels eenvoudig op te lossen door van informaticus een beschermd beroep te maken. In België kun je niet zomaar een slagerij openen, daar heb je een slagerdiploma voor nodig. Dus: geen IT werk zonder IT diploma.

In België hebben ze een fetisj voor diploma's en dergelijke dus van dat zal het niet afhangen. En we zijn als land minder innovatief (toch op vlak van IT) dan de landen waar zo'n fetisj niet heerst.

Ik heb een IT diploma op zak trouwens maar ik hecht er zelf weinig waarde aan. Als ik mij bedenk welke kemels ik al heb gezien door mensen met papieren dan durf ik echt niet te stellen dat een boterbriefje synoniem is voor bekwaamheid. Ik zou zelf soms durven claimen dat het recht evenredig gaat.

Maar ik vind je reacties typerend voor het Belgisch fenomeen die ons als land telkenmale nekt. Ik zie vaak echt onbekwame mensen aangeworven worden puur op papieren en mensen die hier te weinig kansen krijgen , het mooie weer maken in het buitenland.

Weet je als men op de VDAB tegen je zegt dat omwille van het feit dat je geen diploma hebt beter champignons zou plukken en tegelijkertijd men bij Phillips u een job aanbied in Aachen op een R&D afdeling dan is er iets grondig mis.

Belgische overheids sites worden bij mijn weten trouwens ook enkel en alleen gemaakt door die bedrijven die selecteren op diploma's en kwalitatief zijn die zaken allesbehalve goed. Het is trouwens nog maar sinds heel kort dat je als geen hooggeschoolde informaticus ook kan meedingen aan IT jobs bij de overheid.

Als jij alleen wachtwoorden gaat encrypten als dat specifiek aan je gevraagd word, dan zal ik jou nooit een opdracht gunnen...

Oftewel, jij vraagt altijd specifiek om encryptie, anders neem je immers het risico dat het unencrypted geprogrammeerd wordt.
In dat geval zal de persoon waarop jij reageert gewoon de opdracht kunnen krijgen, immers, je hebt specifiek gevraagd om encryptie.

Bovenstaande is nogal uitgebreide manier van omschrijven dat je zin niet klopt.

Jij doet blijkbaar ook niet zo vaak aanbestedingen
Bij een aanbesteding geldt: wat je vraagt krijg je... vraag je iets niet, dan krijg je het niet en wil je het na het aanbesteden wel, dan kost het je extra geld...

Neemt niet weg dat ik ook vind dat wachtwoorden standaard geencrypt horen te zijn.

je klinkt als een programmeur die zijn straatje wil schoonvegen...

Als jij alleen wachtwoorden gaat encrypten als dat specifiek aan je gevraagd word, dan zal ik jou nooit een opdracht gunnen...

Tja, en weet dat als opdrachtgever maar eens van te voren dat een programmeur zo te werk gaat.
Sterker nog, weet als opdrachtgever überhaupt maar van dit soort technische zaken af. Doe je dat niet dan kun je ook geen zaken laten vastleggen in een contract.
En als je al verstand van zaken hebt dan is het nog de vraag: wat hoort standaard bij het te leveren werk en wat voor dingen moeten er specifiek vastgelegd worden. Dat zal ook niet bij iedereen hetzelfde zijn. Dat blijkt wel uit de reacties hier.

@mjtdevries

Ook al geef ik graag toe dat ik zin heb mijn persoonlijke visie aan u mee te delen betreffende uw capaciteit tot inzicht zal ik mij beschaafd houden en gewoon zeggen waar het op aankomt.

Hoe sterk moet deze encryptie zijn? ik verwacht dat 1024bit encryptie net iets te veel performance zal vragen maar 128-bit dan weer te laag is ...
Zijn er andere systemen die gebruik zullen maken van deze wachtwoorden - kunnen ze met dat bepaald type encryptie overweg?
Wil je dat het een signle-sign-on archtitectuur bevat?
En ga zo maar door
Waar komt dit op neer? Wel ja dat de analist deze zaken eerst moet onderzoeken vooralleer hier zekerheid om gegeven kan worden. Verder kan het zijn dat als je voor bepaalde architecturen kiest dat je andere projecten zal moeten aanpassen en bijgevolg x aantal manweken extra zal moeten inboeken.

Maar ja ik kuis mijn straatje schoon; helaas blijken mijn redenen nét dat ietsie pitsie gefundeerder en doordachter dan wat u komt te verkondigen.

Verder komt daar nog bij kijken dat als een fout gemaakt wordt op het niveau van analyse de kost voor recovery exponentieel hoger ligt - bij deze kan ik u al vast melden dat uw inzicht in projectmanagement ondermaats is en dat ik niet zou willen werken voor een onwetend persoon als jij.

Ja hoor geef die opdracht maar aan een ander en je zal achteraf nog lekker komen huilen dat je niet inzag dat je datawarehouse niet overweg kan met bijvoorbeeld SHA512 om nu maar lukraak een voorbeeld te geven.

Security is niet voor niets een APARTE cyclus binnen de analyse van een applicatie. En daar is dan ook effectief rede toe - zoals het artikel wel aanduidt.

[Reactie gewijzigd door F!SH op 5 augustus 2011 17:00]

@F!SH, Op wie reageer je nu eigenlijk?

Er is niet zoiets als 'vanzelfsprekend' in product ontwikkeling. Als jij een offerte vraagt om rondgereden te worden in Nederland en je vervolgens voor de goedkoopste gaat, moet je niet raar staan te kijken als je wordt opgehaald door iemand met een bakfiets. Dat jij het vanzelfsprekend vind is ook gewoon een hele foute instelling, je gaat naar de klant als deze het niet zelf specificeert, deze bepaald de specs en niet jij als programmeur/ontwikkelaar.

Het is verder heel goed mogelijk dat de backend velen jaren geleden is gebouwd door een niet-programmeur, niet heel vreemd bij kleine niet-kapitaal krachtige organisaties. Daarom sta ik er ook meestal op dat dergelijke bedrijven kiezen voor bekende en goed ondersteunde frameworks/CMSen en heb ik een hekel aan die zelfbouw CMSen die een hoop bureautjes gebruiken (en zelf in elkaar hebben geflanced).

Verder is "webserver maakt uitsluitend gebruik van legale software" niet een goede vergelijking aangezien als je het niet doet je de wet overtreed. Er staat nergens in de wet dat wachtwoorden encrypted moeten zijn, wellicht dat er nu wat in staat over het veiligstellen van persoonsgegevens, maar zelfs professionals willen dergelijke wetten nog wel eens vergeten. Aangezien wetgeving niet het expertise gebied is van de meeste ITers...

[Reactie gewijzigd door Cergorach op 4 augustus 2011 15:56]

Een zelf-respecterende ICT'er geeft gewoon de klant waar hij niet om vraagt, voor zijn eigen bestwil. Weten zij veel wat een SQL injectie is! De werkgever gaat er gewoon vanuit dat hij een veilig systeem krijgt.

Een zelf-respecterende ICT'er geeft gewoon de klant waar hij niet om vraagt, voor zijn eigen bestwil. Weten zij veel wat een SQL injectie is! De werkgever gaat er gewoon vanuit dat hij een veilig systeem krijgt.

Een ICTer die niet een advies uitbrengt om wachtwoorden encrypted op te slaan, zal ook niet zelfrespecterend zijn om ook iets over sql-injectie te weten...

dat klinkt leuk, maar het heeft niet veel met zelfrespect te maken. in de echte wereld krijgt een zelf-respecterende ICT'er die allerlei extra ongevraagde functies op eigen houtje gaat toevoegen al snel het verzoek zich aan de specificatie te houden. of hij mag het in zijn eigen tijd doen, want er is geen budget voor - en dan zit de ICT'er uiteraard liever thuis te gamen.

Een zelf-respecterende ICT'er geeft aan bij de klant wat de comlicaties zijn van de keuze van de klant, maar zal nooit op eigen initiatief afwijken van het gevraagde.

Waarom focust hier iedereen zich op de programmeur in kwestie.
Ik denk eerder dat het een typisch overheidsprobleem is, namelijk dat de communicatie schort. Ongetwijfeld hebben de developers ergens in het traject aangegeven dat dit niet de ideale oplossing is.
Kan me voorstellen dat het vevolgens zo gaat:
Vervolgens is er een project manager, die weer dat probeert uit te leggen naar iets begrijpbaars wat op de een of andere manier geld kost.
Niemand die precies begrijpt waarom het nodig is en zo'n besluit erdoorheen werken kan je hele project tot stilstand brengen totdat alle 'knappe koppen' hebben besloten dat het idd nodig is en dat er dus extra budget moet worden vrijgemaakt.
Kortom, het is ergens in de communicatie tussen de lagen blijven hangen.

En hier sluit ik mij bij aan. Het zal niet de eerste keer zijn (zoals ik in een ander topic ook al eens aanhaalde) dat de hogere rangen iets beslissen wat developers allang hebben voorspeld.

Dus we hebben nu de overheid die hun eigen wetten treden. Zou het mogelijk zijn dat de degenen die mogelijk schade hebben geleden hun aan kunnen klagen? Er is wel potentie voor namelijk.

Er bestaat zoiets als WBP (Wet ter Bescherming van de Persoonsgegevens). Hierin staat kort door de bocht dat de data niet zonder meer verkregen moet kunnen worden. Als je die naar boven kunt toveren door middel van eenvoudige SQL injection, dan moet ik ze toch op zijn minst laakbaar noemen. Als daarbij wachtwoorden ook nog eens plain text worden opgeslagen, dan durf ik ze zelfs nalatig te noemen.

Als er een instantie is die zou moeten weten hoe belangrijk persoongegevens zijn (en dus ook wachtwoorden), dan zou dat toch op zijn minst Binnenlandse Zaken en Koninkrijksrelaties moeten zijn...

Ik weet niet wat voor werk je doet, maar om een voorbeeld te noemen uit een andere branche.

Stel je bent stratenmaker en je neemt een opdracht aan waarbij door de klant elke euro uitgebreid is omgedraaid zodat er (vrijwel) niets meer aan te verdienen valt. Zijn vraag was om een net straatje aan te leggen boven op een dijk die schuin af loopt.

Wat doe je dan? Inderdaad je legt een net straatje neer, maar je gaat niet uitgebreid zorgen dat het niet verzakt of iets dergelijks want daar heeft de klant niet om gevraagd en wil hij duidelijk niet voor betalen.

Waar ik met je mee kan gaan is dat je dit soort dingen aan de klant voor moet leggen en bespreken zodat er duidelijkheid is over dit soort dingen. Als de kosten afweging gemaakt wordt en dit soort dingen daarin worden meegenomen dan is het de verantwoordelijkheid van de afnemer. Het is te makkelijk om naar de ontwikkelaars te wijzen als je de manier van aanbesteden/verkrijgen van de opdracht niet kent.

En vervolgens zien anderen dat het straatje waardeloos gelegd is want het verzakt meteen en heb je je goede naam te grabbel gegooid...

Geen slim idee.

? Jij ziet nu dat deze website slecht gebouwd is, en vervolgens heeft het bedrijf wat het gemaakt heeft gelijk een slechte naam?

Als jij weet welk bedrijf dit gebouwd heeft mag je het zeggen, ik denk dat dat namelijk vrijwel nooit bekend wordt gemaakt...

Eigenlijk heb je dan wel meteen een minpunt op je reputatie ja. Je mond-op-mond reclame heeft daar direct invloed op, want zo iemand zal jou niet aanbevelen aan een ander. Je bent dan eigenlijk beter uit de klus gewoon NIET aan te nemen dan bepaalde logische voorzorgsmaatregelen niet te nemen.

En ja, dat is mij ook wel eens overkomen.

Dat het straatje niet verzakt, dat is onderdeel van de kwaliteit. Dus daar kan je als stratenmaker op aangesproken worden en heb je in je offerte meegenomen dat je zand gebruikt dat niet verzakt. Puur om jezelf in te dekken.

Een beter voorbeeld zal zijn dat dat straatje ook goed afgewaterd moet worden omdat anders mensen op zullen uitglijden tijdens regenachtige dagen.
Nou, dat is een extra eis, die niet in de opdracht stond, en waar de stratenmaker ook niet verantwoordelijk voor gehouden kan worden. Het is wel zo professioneel als hij dat even aangeeft, maar als de klant dan toch wilt besparen, dan is het jammer. Je kan er op lopen.

Dat is dus wat ik duidelijk wil maken. encryptie, beveiliging tegen sql-injection. Dat zijn extra's. De hoofdfunctionaliteit waar om gevraagd wordt "in kunnen loggen" werkt (en is getest).

Encryptie en beveiliging tegen SQL injecties zijn de basis van professioneel software ontwikkeling. Dat moet geen expliciete requirement zijn, jij als opdrachtnemer moet dat als impliciet vereist beschouwen, al is het alleen al om jouw goede eigen naam te beschermen en niet zo zeer de opdrachtgever.

Dat klinkt heel mooi. Alleen als de opdrachtgever er niet voor betaald, dan krijg jij de uren die je maakt niet betaald.
En als iets niet op papier staat, is het buiten scope en dus ongevraagd en dus gratis.
Jammer voor jou dan.

Het feit dat data ongecodeerd wordt opgeslagen vind ik niet zo zinvol. Wat ik betreuringswaardiger vind is dat een simpele SQL injection voldoende was om toegang tot de database te krijgen. Met één extra functie aanroepen is dit voorkomen.

Daarnaast is het natuurlijk best zuur dat de website over integriteit gaat. Die integriteit is dus best ter grabbel gegooid. Naar mijn idee website down houden en vergeten. Nooit meer iets mee doen.

Oorzaak ligt hem natuurlijk in het feit dat de overheid graag alles waarvoor ze betalen ook werkelijk netjes gebudgetteerd wil hebben, waarin alles beschreven moet worden. Gevolg is dat de opdrachtnemer enkel datgene maakt wat beschreven is. Immers het gaat vaak bij de overheid om goedkoopste aanbesteding in plaats van de beste oplossing.

Security kost tijd en dus geld en is dus niet vanzelfsprekend. Als een spec gaten bevat zal ik de klant daarop wijzen. Als de klant ervoor kiest om daar dan verder niets mee doet, krijgt hij inderdaad gatenkaas, want daar betaalt ie voor.

In een bouwtekening staat ook niet 'Iedereen op de werkplek moet een helm op', dat spreekt gewoon voor zich. Natuurlijk maakt het niet zoveel uit qua prijs als de bouwvakkers nu wel of niet een helm op hebben, in tegenstelling (blijkbaar) tot websites bouwen.

Precies, als er in de requirements niet staat dat een programmeur zelf moet denken, moet je dat vooral ook laten als programmeur.

Of als programmeur er niet mee instemmen, want in het ergste geval gaan ze jou verantwoordelijk stellen omdat hun geen voorzorgsmaatregelen willen nemen en omdat jij als opdrachtnemer mogelijk aansprakelijk gesteld kan worden waar vervolgens weer een heel traject aan vast komt te hangen en jij toch niet aansprakelijk bent.

Ondertussen ben je wel duizenden euro's aan juridische kosten verder.... Wie gaat dat terugbetalen?

En waar is de code review gebleven in dit verhaal?

Die werd niet geoffreerd voor de budgetprijs

dat kon ook niet, want als je het zo eens aankijkt lijkt het er op dat de budgetprijs eigenlijk een licentie Office 97, en de database is in access97 in elkaar geharkt en vervolgens heeft iemand de "publish as website" optie gebruikt.
De rest was het schrijvne van een stukje VB om de o door een 0 en de i door een 1 te laten vervangen bij de wachtwoord keuze.

als ik me werk niet goed doet, word ik ontslagen.

Arme jij, misschien moet je een werkgever zoeken die het accepteerd dat mensen fouten kunnen maken, en weet dat van fouten geleerd kan worden.

als een programmeur zijn/haar werk niet goed doet, is het een bug die opgelost moet worden...

bugs zijn overmijdelijk onder grote tijdsdruk en complexiteit.

De vraag hierbij is of je iemand kan aanrekenen dat hij die fout heeft gemaakt...

Sommige zaken mogen gewoon niet gebeuren. Wachtwoorden niet encrypten is geen bug die voor mag komen. Zoiets is een ontwerp fout, en een verdomd ernstige. Voor een dergelijke ernstige fout, zou iemand inderdaad heel hard aangepakt moeten worden. Iets dat in de IT helaas te weinig gebeurt.

Dat komt dan ook vooral omdat in de kantoorautomatiseringsomgeving programmeurs zich verschuilen achter requirements, data analisten en weet ik wie ze allemaal kunnen bedenken.
Zelf denken of initiatief nemen is slechts voor weinigen weggelegd in die wereld er is altijd wel een excuus waarom het aan de ander ligt.

Daarmee zeg ik overigens niet dat een programma in één keer foutloos geschreven kan worden, dat is een illusie.

[Reactie gewijzigd door Ghoztmaster op 4 augustus 2011 22:32]

Het is zelfs een illusie te denken dat een programma foutloos kan zijn. Het schijnt dat bij stevig doorontwikkelde programma's er nog 1 bug op de 1000 regels bestaat. Echter is de bug meestal van te weinig belang om hier iets aan te doen.

Voor een dergelijke ernstige fout, zou iemand inderdaad heel hard aangepakt moeten worden. Iets dat in de IT helaas te weinig gebeurt.

Kort door de bocht gebeurt dat in iedere branche niet... Maar een spijker verkeerd slaan heeft over het algemeen minder impact dan een database insert verkeerd opzetten. Het is daarom belangrijk dat juist in de IT er zoveel afgeschermd wordt. Je hebt te maken met mensen, en mensen maken fouten. De impact van die fouten kan enorm zijn, maar door de aansprakelijkheid te verschuiven is de omgekeerde impact verminderd. Anders had deze branche waarschijnlijk OF peperduur gebeleven (zoals vroeger) OF niet bestaan omdat het simpelweg niet haalbaar was...

Dat lijkt me heel kort door de bocht. Ieder mens maakt fouten. Daarom zijn er instanties die op dit niveaus controles uitvoeren. Het is alleen aan de opdrachtgever om dit soort instanties in te huren. Als je software ontwikkeling serieus neemt contoleer je op code quality en security!

een programma foutloos schrijven is bijna niet te doen, vandaar dat je dus ook debuggers en testers hebt. Dat heeft niks te maken met dat een programmeur zijn werk niet goed doet. Eerder heeft de gene van quality control zijn werk niet goed gedaan..

Jep.. daarom zijn 2 van onze mail relays een paar maanden geleden vol geraakt door een Exim4 exploit... -.-

Alle OS'en zijn vatbaar voor exploits als iemand maar lang genoeg er naar kijkt.

Ja, maar niet in dezelfde mate.

Bij linux moet je ook constant updates bij houden. Genoeg exploits te vinden.

Bij linux moet je ook constant updates bij houden. Genoeg exploits te vinden.

Ach het valt tot nu toe mee met linux.. Voor Windows zijn er wel ietsje meer te vinden

Hoeft niet eens een beunhaas te zijn. Ik heb ontelbaar vaak mee gemaakt dat klanten zelfs na waarschuwing bepaalde dingen onbeveiligd willen omdat het een paar uur aan kosten scheelt. Heel kortzichtig. Gelukkig is ons interne systeem zeer veilig maar als het een extern systeem is en de klant wil er niet voor betalen dan kunnen we er geen uren voor schrijven.

Maak hier vaak hetzelfde mee.

Zaken die ik zoal tegenkom:

• admin-wachtwoorden die niet worden aangepast; we blijven het zeggen, maar ze doen er gewoon niks aan.
• updates en upgrades van onderliggende frameworks wat niet van belang wordt geacht en waar dus de klant niet voor wil betalen, ook al zitten er vulnerabilities in de oude versie.
• producten die we hebben overgenomen waar de SQL-injections letterlijk overal in de applicatie voorkomen; als je dan wat functionaliteit toevoegt fix je er een paar als je toch op dat stukje bezig bent, maar het zijn er gewoon teveel om 'even' gratis te fixen.
• functionaliteiten die niet conform de webrichtlijnen zijn; vaak bieden we aan een duurdere variant te implementeren die wel conform de webrichtlijnen is, maar die meerwaarde wordt niet altijd gezien, zeker niet als de kosten voor het alternatief veel hoger zijn. Zelfs bij overheidsinstanties.
• technische verbeteringen die hard noodzakelijk zijn, wat we meerdere malen aangeven, waar niets mee wordt gedaan.
• etc.

De meeste klanten zijn alleen maar geïnteresseerd in nieuwe functionaliteit en totaal gericht op de korte termijn. In mijn optiek is onderhoudbaarheid van de applicatie (maintainability) het meest belangrijke als je op de lange termijn je applicatie niet moet willen vervangen. Alleen klanten met een technische achtergrond (meestal andere IT-bedrijven) begrijpen dat updaten, upgraden en refactoren belangrijk is.

(edit: UBB)

[Reactie gewijzigd door Ruliz op 4 augustus 2011 23:30]

nee hoor, de duurste offerte krijgt de offerte en het bedrijf met de beste relaties.

[Reactie gewijzigd door isomis op 4 augustus 2011 15:31]

De goedkoopste offerte krijgt de opdracht he. Dat je dan een beunhaas krijgt als je je eisen niet duidelijk hebt gesteld in je contract...

Bij een aanbesteding wordt niet gekeken naar 'de goedkoopste', maar naar degene die de beste prijs-kwaliteit verhouding heeft.

Ik denk dat een groot deel van de programmeurs zich helemaal niet interesseert om daadwerkelijk iets neer te zetten waar ze trots op kunnen zijn maar gewoon snelste weg oplossing implementeren. Helaas. Dat geld voor heel veel beroepen overigens.

Dat is wat kort door de bocht. Meestal zijn (te) strakke deadlines de oorzaak van concessies op het gebied van correcte programmatuur. Verkopers worden beoordeeld op de targets die ze moeten halen, die halen ze door toezeggingen te doen die niet altijd waargemaakt kunnen worden door de programmeurs in de gestelde tijd, dus werkt men minder nauwkeurig.

En als de overheid dan ook nog eens kiest voor de partij die de goedkoopste offerte aanbiedt ben je helemaal zuur, want de kans is aanwezig dat je dan direct de meest idiote verkoper te pakken hebt die je kon vinden.

En toch ehhhh Dit is gewoon dom copy en paste werk geweest ofzo.... een wachtwoord in plain tekst? dat is les 1 van een programmeur. Sommige beveiligingsgaten zijn echt niet de schuld van de programmeur maar meestal van de planning. Maar wachtwoord in plain tekst... Daar moet ik serieus extra moeite doen om dat voor elkaar te krijgen. En als het al extra werk zou zijn... dat is dat ook echt minimaal. (10 minuutjes op zn max)

Ik ben het in de meeste scenarios met je eens maar dit is toch wel heel erg basic. Een website moet minimaal passwords beveiligd zijn + geen sql injectie mogelijk. Als die 2 aanwezig zijn ben je gewoon een amateur.

[Reactie gewijzigd door mokkol op 4 augustus 2011 15:19]

Weet je wat nog mooier is ? Als deze software geoutsourced is.

Die gasten doen namelijk echt alles op functionaliteit.

Herkenbaar... dat je baas bij een potentiële klant meteen loopt te roepen "ja hoor, geen probleem, kost drie weken, max!" zonder dat er ook maar iets met de developers is besproken. Die krijgen de opdracht vervolgens in de handen gedrukt, en zien na een paar minuten al dat ze dat nooit gaan redden zonder het af te raffelen.

Zeiken dat het eerst besproken had moeten worden heeft dan al geen zin meer, want de deal is al gesloten Dus je bouwt dat dan maar zo klote mogelijk om het op tijd af te krijgen, en dan maar hopen dat je achteraf geen gezeik krijgt omdat het systeem een keer op z'n bek gaat op een onhandig moment.

Als ik ergens als developer met mijn ervaring geen enkele inspraak heb in dergelijke processen, dan werk ik niet lang voor dat bedrijf. Zeker qua tijdsschattingen en te verwachten technische problemen en mogelijkheden met de te gebruiken frameworks wil je feedback van de mensen die er daadwerkelijk mee werken.
Ik ben zelf wel fan van methodieken als scrum e.d. waarbij er korte iteraties worden gemaakt tussen gebruiksklare revisies van het eindproduct, waarbij de developers, verkoper en klant in hetzelfde team zitten en iedereen intensief bij het ontwikkelproces aanwezig is. Dan valt het e.e.a veel beter te sturen vroeg in het project als er problemen opduiken, en kan je als developer ook beter de te verwachten problemen aan iedereen overbrengen i.p.v. dat er allemaal lagen tussen zitten.

[Reactie gewijzigd door Sfynx op 5 augustus 2011 00:24]

Gelukkig hoor ik bij de groep die iets neer wil zetten waar ik trots op kan zijn. Dan duurt het maar ietsjes langer

Totdat de klant de extra gedeclareerde uren niet accepteert, en je baas je bij je volgende functioneringsgesprek vertelt dat je naar je loonsverhoging kunt fluiten omdat je te langzaam werkt.

Dat is niet zo gek iedereen is een programmeur er is geen echte opleiding of branch organisatie die mensen uit het beroep kan schoppen als ze zo ongelofelijk stom zijn. De professionaliteit is ver te zoeken bij vele kleine en grote developers.

De enige oplossing om dit soort dingen echt te voorkomen is mensen toetsen op kennis hun werk ook later in hun loopbaan in de gaten blijven houden en sancties op leggen op het moment dat het afgeleverde werk niet voldoende is en dit soort stomme fouten bevat.

De meeste mensen zijn op zoek naar een ontwikkelaar die even voor net niets een site in elkaar draait en die niets tot bijna niets rekenen voor het beheer. Het resultaat is dat dit soort beunhazen blijven bestaan. Het is niet anders dan de bouwvakker die wel even die hele verbouwing komt doen voor minder dan de helft van wat zijn concurrenten er voor bieden. Mensen trappen daar niet meer in maar helaas is het op ICT gebied nog steeds aan de orde van de dag en blijven mensen geloven dat het echt allemaal maar voor niets gedaan kan worden voor ze.

Een programmeur is zo goed als nooit verantwoordelijk voor zo iets. Misschien wel degene die het heeft gemaakt, maar daarbij waarschijnlijk niet verantwoordelijk.

Vaak zit er iemand boven als architect. Deze had dit moeten zien, eventueel de projectleider.

Als dit allemaal dezelfde persoon is dan tja, één belangrijk product door één persoon laten maken is in mijn ogen nooit slim

Daarnaast kan het zijn dat de programmeur en andere in het project team dit hebben aangekaart, maar het online moest omdat persoon X bij de overheid z'n gezicht niet wou verliezen (ook speculatie natuurlijk). er zijn dus voldoende (goede) redenen te bedenken waarom zoiets fout kan gaan. Bij de meerderheid is de programmeur niet de verantwoordelijke.

Als programmeur ben jij nog altijd degene die SQL injectie gevoelige DB-toegang programmeert, of gewoon de - veelal simpelere - parametrized query functionaliteit gebruikt die bijna alle situaties van SQL injectie voorkomen.

Evenzo voor wachtwoorden, het kost misschien een paar minuten meer de code te schrijven om het wachtwoord te hashen en de hash weg te schrijven in de DB ipv het plaintext wachtwoord.

Ik denk dat je te veel verantwoordelijkheid op de architect of projectleider afschuift en niet genoeg professioneel gedrag van de programmeur vereist.

[Reactie gewijzigd door Remus op 4 augustus 2011 17:03]

Ook leuk als je in meerdere teams moet werken, en jij gaat op eigen houtje, tegen de (niet uitgeschreven) specs in wachtwoorden hashen....

Een goede programmeur zal zoiets moeten escaleren, maar zodra dat mailtje in de mailbox van je projectleider zit, dan is jouw taak hierover afgelopen.
Het is dan de taak van de projectleider om het verder uit te zoeken (lees: de accountmanger paaien om de klant toch wat extra uren te laten betalen).

Als programmeur moet je hashing gewoon als standaard implementatie voor opslag van wachtwoorden beschouwen.

Staat er niks in de specs => Hashing met een geschikte hash (bcrypt, SHA-1), evt met een verzoek naar de requirements engineer mbt verduidelijking (te gebruiken hash).
Pas als er in de specs staat dat het plaintext moet, dan heb je een blocking issue te die naar de requirements engineer moet.

Als je als programmeur je gaat verschuilen achter 'het staat niet in de specs' mbt dergelijke basale beveilingseisen en dus willens en weten een onveilige situatie creeert, dan moet je misschien maar eens op zoek naar een baan in een andere sector.

Het grote probleem is dat de verantwoordelijke programmeur en ontwerper allebei ambtenaren zijn en dus niet (of heel moeilijk) ontslagen kunnen worden. Maar dat is wat mij betreft wel de correcte respons bij dergelijke verregaande incompetentie.

Dat zulke ontwerpers nog bestaan ...
De programmeur heeft zijn werk prima gedaan. De sql-injectie werkte immers.

Ja, SQL injectie is wel des 90'r jaren ja.
Daar mag je je inderdaad wel voor gaan schamen.
Net een vak he, dat IT

Programmeurs? Dit heeft amper nog wat met programmeren te maken, zou eerder zeggen: opdrachtnemer had ipv keuze 'a', keuze 'b' moeten nemen.. vinkje voor encryptie!

Los van het feit dat het al enorm triest is dat er anno 2011 weer een site opduikt die vatbaar is voor SQL injections en plain text passwords gebruikt, snap ik echt niet waarom er telkens voor zulke websites zelf een applicatie gebakken wordt.

Vrijwel elk willekeurig (open source) CMS pakket zou prima hebben voldaan hier maar nee hoor, men wil zelf het wiel uitvinden omdat het dan ronder wordt of zo. Pak nou gewoon iets of the shelf, waarvan het al bewezen is dat het werkt en niet zo lek is als een mandje.

Edit: ik moet mijn woorden terugnemen. De website (even uit Google's cache gevist) is gemaakt met Typo3 en daar zullen toch echt geen sql injection bugs inzitten. Het lijkt erop dat Drecomm de fout in is gegaan bij stukjes maatwerk oid. Beetje jammer van een bedrijf met toch een vrij imposant portfolio.

Wow, even Googlen op "typo3 sql injection" levert behoorlijk wat hits op. Gelukkig erg weinig core issues maar diverse extenties zijn zo lek als een mandje (of hebben ooit ernstige lekker gehad). Maar dat zou deze problemen niet verklaren aangezien dit toch core spul is lijkt me. En bovendien blijft het de verantwoordelijkheid van de bouwer om, als hij third party extensions gebruikt, deze op goede (samen)werking te testen.

[Reactie gewijzigd door sys64738 op 4 augustus 2011 16:02]

Dan moet de applicatie wel up-to-date gehouden worden door de maintainers, want ook in of-the-shelf producten zitten gewoon vulnerabilities; en het nadeel is dat als zo'n vulnerability naar buiten komt, er meteen tig-duizend applicaties kwetsbaar zijn.

Je kunt trouwens ook een web development framework als Ruby on Rails gebruiken. Dat biedt out-of-the-box bescherming tegen o.a. SQL-injections en XSS.

If you pay peanuts, you get monkeys.

En inderdaad, requirements van tevoren niet goed opgesteld of niet goed getest... dan krijg je dat. Neem maar aan dat de (project)managers weer lekker een paar ton hebben weggetikt hoor...

Kan ook nog mogelijk zijn dat een ambtenaar dat als requirement heeft opgeschreven, dat het opgeslagen dient te worden in een text bestand

De usernames, en MD5 hashes staan op PasteBin. (groep van 46 personen)

Ik zie het net ook ja. Unsalted MD5 blijkbaar, dat is bijna even erg als plain text

Ik kon het niet laten en heb de hashes even proberen te "decrypten"... grappig dat op een website van de overheid zo'n slechte wachtwoorden gebruikt worden

doemaarwat1 is inderdaad crappy

Da's nog 1 van de betere. Er zijn verschillende gebruikers die als wachtwoord hun gebruikersnaam met "123" achteraan hebben. 2 gebruikers hebben zelfs als wachtwoord "password"

Ik zie het net ook ja. Unsalted MD5 blijkbaar, dat is bijna even erg als plain text

Ik kon het niet laten en heb de hashes even proberen te "decrypten"... grappig dat op een website van de overheid zo'n slechte wachtwoorden gebruikt worden

ICT staat hoog in het vaandel van de overheid..
wie kent er een betere grap