vrijdag 15 juni 2012

Software ontwikkelen met de cloud in mind

Cloud computing betekent verschillende dingen afhankelijk van het perspectief waaruit je dit bekijkt. Een CFO ziet een mogelijk kostenbesparing, de business manager een mogelijkheid om sneller te schakelen en flexibel te zijn. Een IT manager ziet het wellicht als een bedreiging en de directeur ziet een mogelijkheid om een niet primair process uit te besteden aan een partij waarbij het thuis hoort.

Door de grote verschillen in SaaS, PaaS en IaaS is een discussie over cloud computing vaak al iets wat uitmond in het vaststellen van definities en voor en tegenstanders in verband met veiligheid.

De scope van mijn betoog is die van de softwareontwikkelaar. In Nederland zie ik enerzijds dat veel bedrijven wel software maken en deze aanbieden als SaaS over het internet (cloud als synoniem van internet), maar niet goed bekend zijn met cloud computing; een verregaande vorm van automatisering en virtualisatie waarbij je niet een fysieke server centraal stelt, maar het gebruiken van bronnen zoals data, geheugen en processor kracht.

Hier zijn een aantal tips over het ontwikkelen van software die geconsumeerd wordt over het internet.

Tip 1: Zelfbediening
Maak software as a service altijd op een manier dat klanten zichzelf kunnen helpen. Dat ze dus klant kunnen worden zonder dat er menselijk handelen nodig is voor jou als leverancier. Het klinkt als een open deur, maar ik kom zeer vaak tegen dat je eerst een contact formulier invult of iets dergelijks en dat je dus niet meteen aan de slag kan. Maar zelfbediening gaat veel verder. Veel diensten moeten worden ingericht voordat ze goed gebruikt kunnen worden, zorg ook dat een klant die wijsheid via jouw product op kan doen. Dus met instructie filmpjes of slimme pop-ups en tooltips. Soms gaat het om producten die ook beheer moeten worden. Als je bijvoorbeeld een Google Apps account aanmaakt, kun je ook e-mail adressen voor werknemers aanmaken en beheren. Het beheren van gebruikers en het domein dient dus ook te gaan op basis van zelfbediening. In feite moet je klant de tools kunnen gebruiken die je zelf ook gebruikt als beheerder.

Tip 2: Integratie
Eén van de grootste nadelen van SaaS is dat het vaak eilanden zijn. De dienst doet één ding heel erg goed, maar klanten willen meer. Nu kun je als een dolle al dat “meer” gaan maken, maar vroeg of laat verlaat je dan je comfortzone; het gebied waarop je deskundig bent. Je wilt een product in de regel niet te alomvattend maken omdat het dan snel zo complex word dat je in een spagaat terecht komt. Dit probleem los je op door integratie mogelijk te maken. De beste manier om dit te doen is door toegang te geven tot je product door middel van een Application Programming Interface (API) en deze te ontsluiten over het internet bijvoorbeeld met een webservice. Met een “CreateOrder” API kun je een bestelling plaatsen. Met “GetHours” haal je gewerkte uren van een medewerker op. Nu geef je andere bedrijven mogelijkheden om koppelingen te maken met jou product. Nog beter word het als het eigen product ook middels deze API’s met de database communiceert. Dit geeft meer vrijheid en leidt in de regel tot meer veiligheid en eenduidigheid. Je houdt je aan dezelfde regels waar anderen zich aan moeten houden en door je eigen product verder te ontwikkelen creëer je ook meer mogelijkheden voor andere partijen. Ook zorgt dit voor een “separation of concerns” (SoC); de presentatielaag en de businesslaag zijn zo mooi gescheiden en daardoor beter te onderhouden of onafhankelijk van elkaar door te ontwikkelen. In feite creëer je hiermee een platform en een platform kan leiden tot een hefboom. Een cliché voorbeeld is Amazon S3. Dropbox is een tool die data opslaat in S3 en alleen mogelijk was doordat S3 middels een API aan te sturen is. Hierdoor kan Dropbox 50 miljoen klanten bedienen met slechts 100 medewerkers. Amazon Webservices (AWS) waarvan S3 een onderdeel is laat zien hoe krachtig een platform kan zijn. Een ander voordeel van het werken met API’s is dat het platform onafhankelijk is. Een Java guru kan uitstekend een tool bouwen die gebaseerd is op een .NET API. Maar ook een Android of IOS App heeft per definitie een API nodig.

Overigens werkt integratie twee kanten op. Je kunt er ook naar toe werken dat jouw product kan communiceren met API’s van andere webdiensten. Vaak zijn dit soort koppelingen unique selling points (USP). Als je kijkt naar de universele afstandsbediening van Logitech, de Harmony serie, dan is de kracht ervan dat er een database bestaat met de koppeling en taal naar alle apparaten die met infrarood werken. Zonder die integratie is het product niets waard en snel namaken gaat niet omdat de kracht nu juist in die koppelingen zit.

Uiteraard is het een goed idee om bij integratie focus te hebben op andere cloud producten. Als dat andere cloud product succesvol is, kun je daar wellicht op meeliften.

Tip 3: Hou rekening met meertaligheid
Zeker op het gebied van cloud computing moet je jezelf niet beperken tot één taal. Dit betekent niet dat je meteen uit moet rollen naar alle landen van de wereld. Wel dat mensen graag aangesproken worden in hun eigen taal maar wees er klaar voor dat als jou idee werkt in Nederland, dit wellicht ook werkt in andere landen. Dit vergt wel wat denkwerk. Sommige data uit de database moet met meerdere talen overweg kunnen (bijvoorbeeld als je moet kiezen uit een geslacht ofwel gender), maar ook datum notaties zijn in landen verschillend. Dan heb je nog de teksten zelf en instructies. Nederlandse instructies in Nederland spreken meer aan dan Engels ondanks dat Nederlanders goed in Engels zijn. Coderen en commentaar in de code zou ik overigens wel gewoon Engels houden en zeker geen Nederlands. Ten eerste ben je dan beperkt met als je delen wilt uitbesteden, maar ook ben je minder aantrekkelijk als de software wordt overgenomen door een grotere speler in de branche.

Tip 4: Denk breder dan de organisatie
Software wordt vaak gemaakt voor interne gebruikers of voor klanten. Maar in het verlengde van tip 2 beperk je niet dat die twee soorten gebruikers. Denk ook aan bijvoorbeeld leveranciers en klanten van klanten of andere dienstverleners. Met andere woorden; iedereen heeft wel iets in de software te zoeken. Accessibility ofwel de toegang tot data is functioneel gezien het allerbelangrijkste. Heb je een HRM oplossing, dan heeft een (externe) bedrijfsarts wellicht ook wat te zoeken in de database. Of een leverancier die jouw voorraden kan bijwerken. Of een externe accountant die financiële rapporten of data zelf op kan halen. Of kijk naar Google Docs. Twee samenwerkende bedrijven kunnen een map samen delen en op zo’n manier samenwerken. Dit concept creëert een enorme hefboom en heeft veel toegevoegde waarde omdat veel andere software dit niet kan omdat het niet fundamenteel is meegenomen in het ontwerp. Ik zeg niet dat je alles zo generiek mogelijk moet maken of dat je met elk mogelijk scenario rekening hoeft te houden, maar het kan ook geen kwaad om vooruit te kijken zodat je niet ineens te beperkt bent als de wens geopperd word.

Tip 5: Ontwikkel met de Cloud in mind
Ik spreek regelmatig software ontwikkelaars. Zowel de business eigenaren als de ontwikkelaars zelf, en het verbaasd me hoe weinig kennis zij hebben van cloud computing. Een database opzetten in Microsoft Azure, een instance van een virtuele server de lucht in schieten in Amazon EC2, zelfs het consumeren van een webservice is iets wat ik te weinig tegen kom. Ik ben absoluut een voorstander om een simpel tooltje te ontwikkelen en dit uit te bouwen in plaats van direct een complex systeem neer te zetten. Maar het nadeel is dat als de basis niet gebouwd is voor schaalgrootte dit een lastige en dure transitie wordt als het gebruik van de tool groeit. Een voorbeeld van een beslissing die vroeg genomen moet worden is deze; gebruiken klanten samen één database, of krijgt iedere klant zijn eigen database. Deze keuze heeft verstrekkende gevolgen als het klantenbestand groeit. Ik zeg niet dat één van de twee keuzes de beste is, maar dat je de vanaf scratch al bouwt met het idee van schaalgrootte in je achterhoofd.

Een andere valkuil die ik vaak zie is dat er op een server ontwikkeld wordt en dat de inrichting van de server een onderdeel is van de oplossing. Voor een prototype is dit wellicht logisch, maar uiteindelijk dien je een server slechts als een leverancier van bronnen te zien. Een kort door de bocht voorbeeld: Een server wordt aangeschaft en daarop wordt een database server geïnstalleerd. Stel dat het aantal klanten snel groeit, dan voldoet de database server niet meer. Er moet een server bijkomen of naar een “dikkere” server worden gemigreerd. Door Amazon RDS of Microsoft Azure te gebruiken heb je dit probleem niet. Opslag van data is bijna onbeperkt en de beschikbaarheid is hoog. Je hoeft geen diepgaande architectuur op te zetten.

Met de cloud in mind ontwikkelen is echt wat breder dan alleen denken aan techniek, het is een filosofie. Een beetje gekscherend maar wel illustratief voorbeeld is dat er vroeger altijd gedacht werd in doosjes. Je schaft software aan op een DVD en doet deze in een computer om het te installeren. Voor de klant lastig, want die moet eerst naar een winkel, maar je moest ook als ontwikkelaar een doosje ontwerpen, DVD’s laten persen en sleutels maken voor licenties en denken aan piraterij. Dit zijn uitdagingen die je niet hebt als cloud dienst. Tien jaar geleden kwam er nog iemand van automatisering langs om je computer te updaten, dat schaalt niet. Ontwikkelen met de cloud in mind is echt automatiseren. De functie staat centraal, alles wat daaronder of daarachter zit is ballast.

zaterdag 9 juni 2012

LinkedIn faal update

We zijn nu een paar dagen verder na het uitlekken van de wachtwoorden lijst van LinkedIn. Er is op zich weinig nieuws, maar ik heb wel langer nagedacht over dit alles, en ik wil deze gedachten delen.

Laat ik zaadje planten. Misschien is LinkedIn niet gehackt. Dit is iets wat LinkedIn ook wil doen geloven in hun laatste verklaring (http://goo.gl/Q6lDn ). Als ik een lijst maak van 0000 tot en met 9999 en deze verspreid met de boodschap dat ik de Nederlandse bankpassen heb gekraakt van de ABN dan zal iedereen bevestigen dat hun pincode er tussen staat. Ik kan binnen vijf minuten een lijst produceren van wachtwoorden die gehashd zijn met SHA-1 die zo lang is als de lijst die op het internet verschenen is. Maar die zou wel willekeurig zijn. Er is ook zoiets als rainbow tables. Deze zijn door de tijd heen opgebouwd om SHA-1 wachtwoorden sneller te ontcijferen. Als je hier een slimme selectie uit haalt heb je al een grotere kans om werkelijke wachtwoorden te tonen. Mijn wachtwoord die ik uit de lijst haalde gebruikte ik inderdaad op LinkedIn. Maar ook op Twitter, Last.FM, en op Computable.nl. Het is een wachtwoord wat niet uit alleen uit letters bestaat, maar ook uit cijfers. Het is niet onmogelijk dat iemand anders dit wachtwoord ook gebruikt. Juist omdat de impact laag is was het wachtwoord niet bijzonder sterk en gebruikte ik hem voor meerdere doeleinden. Ik kan alleen mijn eigen wachtwoord valideren. Ik ben benieuwd of een gebruiker van KeePass of LastPass ook zijn wachtwoord heeft teruggevonden. Die tooltjes maken voor elke site een ander wachtwoord aan en daarmee kan daadwerkelijk gevalideerd worden dat de lijst op het internet echt van LinkedIn afkomstig is. Als dit zo is (en zo lijkt het wel te zijn), dan is het zeer waarschijnlijk dat er bij de wachtwoorden lijst ook de inlognamen bekend zijn.

De laatste verklaring van 7 Juni waar ik al de link van gaf is wederom een loze verklaring waarin ze schrijven dat er geen indicatie is dat ook de inlognamen verspreid zijn.

To the best of our knowledge, no email logins associated with the passwords have been published, nor have we received any verified reports of unauthorized access to any member’s account as a result of this event.

Er is dus ook geen ongeoorloofd toegang gedetecteerd. Right. Hoe kunnen ze dat onderscheid maken? En wat valt er te halen dan? Wat spam verspreiden? Nee, de buit zit hem in het proberen van de gebruikersnamen en wachtwoorden op andere diensten. En zoals iemand al toegaf; die gebruikte dezelfde gegevens voor LinkedIn als voor PayPal. Statistiek zal uitwijzen dat diegene niet uniek is....

In de reacties die ik kreeg op Computable.nl stond ook een rake. Ga maar eens naar LinkedIn en log uit. Inloggen gebeurt over een gewone HTTP verbinding. Dus gegevens worden niet eens versleuteld verzonden naar LinkedIn!! Als ze veiligheid serieus namen... dan zouden ze dat ook aanpassen.

Als ik het artikel op ZDnet moet geloven ( http://goo.gl/IAS70 ) dan heeft LinkedIn niet zoiets als een information officer (CIO), of een chief information security officer (CISO).

Alles bij elkaar opgeteld is dit een faal van epische proporties. Ik kan niet één goed punt vinden die in het voordeel van LinkedIn spreekt. Het enige wat het mij brengt is dat ik nu serieus een poging doe om over te stappen op een wachtwoord tool.

donderdag 7 juni 2012

LinkedIn ernstig in de fout

disclaimer: Deze post is snel gepost omwille van actualiteit. Daarnaast wees Jacques Schuurman me erop dat “hashen” en versleutelen twee verschillende dingen zijn. Ik gebruik versleutelen om aan te geven dat het wachtwoord niet herkenbaar is opgeslagen.

Zoals je wellicht gelezen hebt kun je een bestand downloaden met meer dan 6 miljoen LinkedIn wachtwoorden. Versleuteld weliswaar, maar relatief zwak versleuteld en zonder gebruik te maken van “salt”. Twee mensen met hetzelfde wachtwoord zullen dan ook maar  één keer in het bestand voorkomen.

Dit nieuws stinkt aan alle kanten en ik ben zeer teleurgesteld in LinkedIn. Laat me een paar gedachten met je delen:
Mijn wachtwoord stond in de lijst. Er komen geen dubbele records in de lijst voor. Aangezien niet iedereen een uniek wachtwoord heeft is de lijst van 6 miljoen wachtwoorden dus voor (veel) meer dan 6 miljoen gebruikers! Deze gedachte is niet uniek, op http://it.slashdot.org/comments.pl?sid=2898871&cid=40232643 lees je er meer over.

Het bestand is “oud”. Dit betekent dat de accounts al lang geleden gekraakt zijn. Er zit een zwakte in de LinkedIn App dat wachtwoorden te onderscheppen zijn. Ik gebruik de LinkedIn app niet en mijn wachtwoord zit er ook tussen, mijn wachtwoord is dus niet op die manier gevonden. De database van LinkedIn is gewoon gekraakt.

Dit is natuurlijk erg, maar LinkedIn speelt mooi weer en geef wel wat toe maar laat het overkomen alsof het niet ernstig is. Dit is *zeer* ernstig omdat A) hun database gehackt is B) wachtwoorden zwak versleuteld zijn. Voor een miljarden bedrijf die op de beurs handelt is dit een doodzonde. Vooral omdat het wat zwaarder versleutelen een eitje is. Iets wat LinkedIn binnen 24 uur nu ook heeft doorgevoerd!

Als zo’n bedrijf al zo sloppy met veiligheid omgaat, dan belooft dit niet veel goeds. Nu denken veel mensen vast; “Lekker boeiend er staat toch niets belangrijks in”. Maar met jouw account hebben ze ook jouw e-mail adres en jouw gebruikersnaam. Deze combinaties gaan geautomatiseerd uitgeprobeerd worden op andere sites om met jouw gegevens ergens anders in te loggen. Veel mensen gebruiken vaker eenzelfde wachtwoord. En dat kan leiden tot iets groters dan je LinkedIn gegevens.

Er zijn twee zaken die je goed moet beschermen met variabele sterke wachtwoorden:

1) Toegang tot email
2) Toegang tot zaken die te maken hebben met geld

Stel je e-mail account is gehackt en je bent een gebruiker van Pay-Pal. Bij Pay-Pal geeft de dief aan zijn wachtwoord vergeten te zijn, die wordt verstuurd naar je e-mail. Dit mailtje wordt direct verwijderd door de hacker en nu logt hij in op je Pay-Pal account en wijzigt daar het e-mail adres naar een “eigen” e-mail adres. Vanaf dat moment kan er geld gestolen worden van je rekening en duurt het een tijdje voordat je dat door hebt. Dit is slechts één voorbeeld.

Wil je kijken of jouw wachtwoord bij LinkedIn ook gekraakt is?

Ik heb het bestand met de hashes (versleutelde) wachtwoord gedownload (kijk voor links op http://tweakers.net/nieuws/82411/wachtwoorden-miljoenen-linkedin-gebruikers-op-straat.html) en gekeken of mijn wachtwoord erbij zit. Dit was zo. Met deze link: https://oisyn.nl/converter/#dGVzdA==;u8;sha1;0 kun je een wachtwoord vertalen naar het versleutelde wachtwoord. Het bestand bevat veel regels die met vijf nullen beginnen. Dit zijn wachtwoorden die al zijn gekraakt. Door de eerste vijf tekens van jouw wachtwoord te wijzigen in 00000 en dit in het bestand te zoeken geeft aan of jouw wachtwoord er tussen staat. 

Samenvattend:

1) LinkedIn is lang geleden gehackt en de hacker had toegang tot de database
2) LinkedIn heeft wachtwoorden slecht versleuteld
3) LinkedIn wist niets van de hack
4) LinkedIn bagataliseert de zaak
5) Grote bedrijven doen niet zomaar goed aan beveiliging
6) LinkedIn geen clue heeft en dus ook geen controle

* Diverse updates in de tekst:
** Handige site om snel uit te zoeken of jouw wachtwoord ook bemachtigt is:  http://leakedin.org/