Dat er nog steeds softwareontwikkelaars zijn die dit durven te implementeren verbaast me echt.

Deze ontwikkelaar(s) kunnen beter een baan buiten de IT gaan zoeken…..
Als je op die manier met inlog gegevens omgaat, heb je het niet begrepen.

Plain wachtwoord. Hoe kan dit? Als ze maar niet het 2fa 06 nummer te pakken krijgen. Dit is een grote plug-in, dus wel schrikken maar ik gebruik Wordfence voor security.

Het zit in een audit log, het gaat niet om de normale wachtwoord-opslag en ook niet om de implementatie van de inloglogica zelf. In die audit log wordt een complete stack trace gelogd (dus welk stukje code heeft welk stukje code aangeroepen, en dat ettelijke niveaus diep), en in die stack trace zitten waarden van variabelen, waaronder het ingevulde wachtwoord.

Jullie hebben makkelijk praten. Ik schud zo een scenario uit mijn mouw waarin het niet zo simpel is om dit soort fouten te voorkomen als op het eerste gezicht misschien lijkt. Ik weet niet of het ook zo gegaan is, laat me daar duidelijk in zijn, maar dit geeft wel een idee van op wat voor soort manieren zoiets mis kan gaan.

Hier komt 'ie (dit is dus een bedenksel van mij en, tenzij ik per ongeluk ongelooflijk raak schiet, niet wat er echt gebeurd is):
- De ontwikkelaars van de login-logica hebben hun werk goed gedaan: wachtwoorden worden gehasht met een salt opgeslagen, de code deugt.
- Er is een faciliteit ingebouwd voor een audit log. Niets aan de hand.
- Die faciliteit wordt uitgebreid met het loggen van een stack trace. Laten we aannemen dat die stack trace op dat moment niets vertrouwelijks bevat en veilig gebruikt kan worden. Nog steeds niets aan de hand.
- Ontwikkelaars hebben tijdens het debuggen veel plezier van de stack trace-functie, die ze zelf op geschikte plekken tijdelijk inbouwen, maar zien waar in de code je zit is heeft zijn beperkingen, zien wat de waarden van aanroepparameters van functies zijn op het moment van de stack trace zou veel toevoegen.
- Daar breidt men de stack trace-functie mee uit, zonder te beseffen dat een functie waarvan zij denken dat die alleen maar voor debug-doeleinden bestaat ook voortdurend in productiecode wordt aangeroepen en dan gevoelige informatie logt. En opeens worden ook in de loginlogica die dingen gelogd, inclusief het plain text password. Oeps.

En daar heb je je beveiligingslek. De wijziging heeft neveneffecten waar degene die hem aanbracht niet bij stil heeft gestaan. Het is alsof je in Baarlo een gordijn open trekt en dan maar op het idee moet zien te komen dat daardoor ook ergens in Winschoten licht valt op een plek die absoluut donker moet blijven.

Je kan proberen in je werkwijze allerlei checks en balances in te bouwen, verplichte impactanalyses (altijd verstandig), checklists, noem maar op. Maar die checklists breid je uit aan de hand van dingen die fout gaan ondanks de checklists, en dan gaan ze die ene keer dus toch fout. Je kan namelijk niet aan aan alles denken. Probeer maar: denk nu aan dingen waar je niet opkomt. Dat lukt je niet.

Ik heb niet de moeite gedaan om uit te zoeken hoe het allemaal echt zit, maar het punt is om een idee te geven van op wat voor soort manier dit soort dingen mis kunnen gaan. Het komt er eigenlijk op neer dat software inherent razend complex is en dat het menselijke bevattingsvermogen beperkt is. Dan kan je er gif op innemen dat af en toe ergens iemand iets belangrijks mist. Ik weet dat dat niet goed genoeg is, maar niet hoe je dit op kan lossen.

Dan nog mag het ingetikte wachtwoord niet zichtbaar worden. Bij een veilige login procedure word het ingevulde wachtwoord eerst lokaal met de sessie cookie gehashed en dan verstuurd. Aan de ander kant wordt het te vergelijken wachtwoord op dezelfde manier gehashed en worden alleen de hashes vergeleken.

Dus zelfs als de verbinding gecompromitteerd wordt, heb je nog weinig aan een onderschept wachtwoord.