De APIs zijn ruk, ja, maar de achterliggende concepten ook. Ze werken maar heel matigjes op browsers (daar kwamen ze vandaan en daar krijgen ze de meeste aandacht), dus is het niet raar dat ze elders nog minder geweldig werken.

Wat overigens ook absoluut niet helpt is dat die niet-eenvoudig-te-gebruiken-APIs OHA worden gebruikt door mensen die er niet genoeg verstand van hebben om ze veilig te gebruiken. Niet met betere APIs, dus al helemaal niet met deze. Crypto is namelijk Niet Eenvoudig om correct te gebruiken en ongelukjes zitten in geniepige hoekjes, en je hoeft maar iets teveel los te laten of even een parameter niet helemaal begrepen te hebben en heel je encryptie kan zo omzeild worden--dan heb je dus al die moeite voor nop gedaan. Zo werkt encryptie nou eenmaal.

Wat dat betreft is het heel erg tekekend dat de APIs zo slecht zijn: De schrijvers hebben er niet voldoende over nagedacht. Dit gegeven alleen al kan verstrekkende gevolgen blijken te hebben.

Dus mensen, zelfs geen encryptiebibliotheken aanroepen vanuit je programmas voordat je toch tenminste een college "introductie tot cryptografie" hebt gevolgd en een beetje een idee hebt wat het zoal vermag en waar de beren op en de kuilen in de weg zoal te vinden zijn. Wees niet bang: Zo'n college bestaat voor de helft uit voorbeelden waarom je echt niet zelf het crypto-wiel opnieuw moet willen uitvinden. De andere helft is uitleg en voorbeeldjes kraken, en dat is best leuk.

Is er ook iets over opencart bekend? die gebruiken wij namelij

OpenCart? Dat doet me denken aan http://blog.visionsource.org/2010/01/28/opencart-csrf-vulnerability/

Volgens mij heeft OpenCart nog wel grotere problemen dan incorrect SSL-gebruik. Al weet ik niet hoe het er nu bij staat.

Ik kan niet over deze APIs meepraten omdat ik ze zelf niet gebruikt heb. Ik heb bijvoorbeeld wel te maken gehad met een webapplicatie waarin authenticatie en signing met smartcards werkte, inclusief een variant waar de digitale handtekeningen en de webpagina's over gescheiden netwerken werden getransporteerd.

Om dat soort dingen goed te doen moet je tot in den treure scenario's doorlopen, gedetailleerd stapje voor stapje nagaan wat er precies gebeurt en hoe dat eventueel misbruikt kan worden of anderszins mis kan gaan, en dan nog is het makkelijk om dingen over het hoofd te zien. Daar komt een grondigheid bij kijken die ik bij de meeste ontwikkelaars die ik mee heb gemaakt niet aantrof, die zijn vaak sterk gericht op hoe je iets aan de praat krijgt en veel minder op hoe je het stukmaakt.

Dat wordt versterkt door de krachtige ontwikkelhulpmiddelen en frameworks die er tegenwoordig zijn. Die werken de verwachting in de hand dat je de lastige details niet meer hoeft te kennen, dat het allemaal wel voor je geregeld is. In de documentatie van dotNet bijvoorbeeld is tussen een overvloed aan makkelijk te kopiëren brokjes voorbeeldcode het overzicht van hoe het geheel werkt vaak moeilijk te vinden, evenals toch niet onbelangrijke details als met welk algoritme de encrypted cookies versleuteld zijn en waar de encryptiesleutel eigenlijk vandaan komt en hoe die beveiligd is (dit kan achterhaald zijn, maar toen ik ermee werkte heb ik het gebruikte algoritme met de botte bijl achterhaald door met garbage-input een exception te forceren, in de documentatie werd er toen niet over gerept). Als een auditor me interviewt wil ik uit kunnen leggen waarom ik vertrouwen heb in de kwaliteit van de beveiliging, en ook zonder audit zou ik door de grond zakken van ellende als er door mijn nalatigheid een kapitaal verloren zou gaan. Het ontbreken van een duidelijke uitleg van hoe het is opgezet in de meegeleverde documentatie vraagt om blind vertrouwen. Blind vertrouwen is niet goed genoeg, zoals ook duidelijk uit het besproken onderzoek blijkt.

Management is in de loop van de decennia steeds meer rond gaan lopen met de indruk dat automatiseren gereduceerd is tot legoblokjes stapelen, en dat een diepgaand begrip van wat er gebeurt overbodig is geworden. Ook herkent men automatisering nog wel als kostenpost maar is men vergeten hoe groot de baten zijn. Zelfs een relatief klein bedrijf in bijvoorbeeld de financiële sector zou duizenden mensen in moeten huren om dezelfde informatie handmatig te kunnen verwerken. Dat besef lijkt niet meer te bestaan. Dat betekent in de praktijk dat je weerstand ondervindt als je grondig en degelijk probeert te zijn.

Ik ben zeker geen tegenstander van goed ontworpen APIs met veilige defaults, maar wel heb ik een sterke voorkeur voor een dunne abstractielaag die dicht op de essentie zit boven een opzet waarin abstractielaag op abstractielaag is gestapeld waardoor het moeilijk wordt te begrijpen wat er nou precies gebeurt. De "laat mij maar voor je nadenken"-mentaliteit waarmee sommige populaire producten zijn opgezet bevalt me niet, ik wil zelf nadenken en daarbij gereedschap hebben dat de uitvoering op een transparante manier makkelijk maakt. Dat nadenken kan je niet overslaan namelijk, niet grondig begrijpen wat je doet is bij dit soort onderwerpen een luxe die je je niet kan veroorloven.