Het is steeds vaker in het nieuws: beveiligingslekken of inbraken bij grote bedrijven zoals Yahoo, LinkedIn, KPN, Simpel en Last.fm. Vaak komen daarbij de wachtwoorden van klanten op straat te liggen. Vervelend voor het bedrijf, maar natuurlijk verschrikkelijk voor de getroffen klanten! Het feit dat het steeds vaker in het nieuws is, wil niet zeggen dat er vroeger veel minder aanvallen waren. Maar waarom gaat het dan toch steeds mis? Waarom worden wachtwoorden niet veiliger opgeslagen? Hoe zit het eigenlijk?
In deze driedelige reeks ga ik je alles uitleggen omtrent wachtwoorden. In dit eerste deel springen we meteen in het diepe: we bekijken de achterliggende techniek en de cryptografie. In deel twee leg ik uit wat jij als gebruiker kunt doen om de impact van een gestolen wachtwoord te verkleinen. Tenslotte beantwoorden we in deel drie de vraag “Hoe veilig is jouw website nu eigenlijk?”, hoe kan jij als website-eigenaar de wachtwoorden van je bezoekers beschermen?
De basis: hoe slaan websites wachtwoorden op?
Bijna iedere website heeft de mogelijkheid om in te loggen, zodat je persoonlijke gegevens kunt opvragen en aanpassen. Handig, maar dat betekent wel dat er ergens een lijst moet zijn waarin alle mogelijke gebruikersnamen en wachtwoorden bewaard worden. Hoe kan het systeem immers anders verifiëren dat je inderdaad toegang hebt?
Nog niet zo heel lang geleden werden gebruikersnaam-wachtwoord-combinaties opgeslagen in een verborgen bestand op de server van de website. De data werd tot overmaat van ramp ook ‘onversleuteld’ opgeslagen. Dat wil zeggen dat de gegevens voor een mens gewoon te lezen zijn. Als een wachtwoord onversleuteld opgeslagen is, dan is het bij een lek ook meteen openbaar. Een aanvaller heeft dan toegang tot al jouw gegevens en hij kan mogelijk ook nog inloggen op andere sites waar je hetzelfde wachtwoord gebruikt hebt. Tegenwoordig gebruikt bijna iedereen een database en worden de wachtwoorden gelukkig ook versleuteld opgeslagen.
Het belangrijkste aspect van het opslaan van wachtwoorden is de gebruikte manier van versleuteling. Is de versleuteling onomkeerbaar, dan maakt het eigenlijk niet uit dat de database is gelekt. Een omkeerbare versleuteling is bijvoorbeeld het volgende: stel, we gebruiken een versleuteling die alle A’s vervangt door N’s, B’s door O’s enzovoorts. Deze specifieke versleuteling is ook wel bekend als Caesarrotatie. Als mijn wachtwoord nu ‘appeltaart’ is, dan is het resultaat na Caesarrotatie-versleuteling ‘nccrygnneg’. Dit ziet er op het eerste gezicht moeilijk uit, maar als je weet hoe het wachtwoord versleuteld is, dan is vrij eenvoudig het oorspronkelijke wachtwoord weer terug te halen.
Een stap in de goede richting: Hashing
Door de jaren heen zijn er verschillende versleutelingen uitgevonden die beter zijn dan de hierboven beschreven versleuteling. Voor wachtwoorden is het het meest gebruikelijk om hashes te gebruiken. Hashes zijn onomkeerbare versleutelingen waaruit het heel moeilijk (zo niet onmogelijk) is om de oorspronkelijke tekst terug te vinden (preimage resistance). Daarnaast is het moeilijk om twee teksten te vinden die dezelfde hash opleveren en is het, gegeven een hash, moeilijk een ander bericht te vinden dat dezelfde hash oplevert (strong & weak collision resistance).
Deze eigenschappen zijn erg belangrijk voor wachtwoorden: het moet moeilijk zijn om het oorspronkelijke wachtwoord weer terug te halen en het moet moeilijk zijn om een wachtwoord te vinden dat dezelfde hash oplevert. Neem bijvoorbeeld weer het wachtwoord ‘appeltaart’: als ik hier een MD5-hash van maak (een veelgebruikte hash-methode), dan komt hier ‘6c92b35a7f13c383ef7c32a147439927’ uit. Het is wiskundig niet haalbaar om deze hash weer terug te draaien naar het oorspronkelijke wachtwoord.
Een beveiliging is zo sterk als de zwakste schakel
Er zijn in totaal 3,4×1038 verschillende MD5-hashes; oftewel 3 met 38 nullen combinaties. Dat is zoveel, dat het erg moeilijk is om zomaar het wachtwoord vinden bij een gegeven hash. Zelfs voor een computer die niets anders doet dan hashes berekenen (en een zogenaamde brute force-aanval uitvoert), is het zoeken naar een speld in een hooiberg.
Helaas zijn we er met alleen een MD5-hash niet. Het MD5-algoritme heeft zwakheden en het was — in tegenstelling tot hoe het zou horen — in 2005 al mogelijk om binnen drie kwartier het wachtwoord behorende bij een hash te vinden. Sommige algoritmes vertonen zwakheden pas jaren nadat ze zijn geïntroduceerd. Zo zijn MD4 en MD5 al de revue gepasseerd. Het verdient daarom de aanbeveling om een sterker algoritme te gebruiken, zoals SHA-256, of zelfs een hashmethode die is ontwikkeld om tegen brute force-aanvallen te kunnen, zoals bcrypt of PBKDF2. Deze methodes werken door heel vaak het wachtwoord te versleutelen, waardoor het berekenen van de hash enige tijd in beslag neemt en het niet meer haalbaar is om een brute force-aanval uit te voeren (key stretching).
Een groot probleem is ook dat hash-algoritmen voor iedereen beschikbaar zijn en door velen gebruikt worden. Op het internet zijn er lijsten van tekst-hash-combinaties te vinden. Zoek bijvoorbeeld eens op het internet naar ‘6c92b35a7f13c383ef7c32a147439927’ en je zult zien dat er tientallen resultaten zijn die vertellen dat het hier gaat om het woord appeltaart. Ook hashes als ‘a67ff0673ff2b37ffb89c5d876a53ef0af1c7e96’ en ‘188aff47c334dc19c89f85e6dceab01b’ zijn eenvoudig te herleiden. Gebruik je dus een veelvoorkomend wachtwoord, zoals ‘wachtwoord1234’, dan ben je niet beschermd met een simpele hash-functie, hoe goed die hash ook is.
Een korreltje zout toevoegen
De oplossing is het toevoegen van salt (zout) aan het wachtwoord voordat je de hash berekent. Een salt is een willekeurige tekenreeks van een vast aantal tekens die je per wachtwoord opnieuw genereert. Door de salt achter het wachtwoord te plakken worden de wachtwoorden in feite unieker gemaakt. Voeg ik bijvoorbeeld ‘o9ig4’ toe aan mijn ‘appeltaart’-wachtwoord, dan krijg ik ‘appeltaarto9ig4’. De hash hiervan is niet terug te vinden op het internet. Het toevoegen van een salt zorgt er dus voor dat ik mijn hashes moeilijker maak om terug te draaien.
Hoe langer de salt, hoe veiliger je wachtwoordhash (gebruik bijvoorbeeld 12 karakters). Als iemand écht graag wil, dan kan hij uiteraard nog steeds het wachtwoord met brute kracht gaan proberen terug te halen, zeker als ook de salt bekend is. Dit is echter een heel stuk moeilijker dan de wachtwoorden achterhalen uit een database met wachtwoorden zonder salt.
Foto: Flickr/subcircle
Waarom het misging bij LinkedIn
De meeste websites slaan hun wachtwoorden tegenwoordig beveiligd op; er zijn (gelukkig) nog maar weinig websites waar je wachtwoord zonder enige versleuteling op wordt geslagen. Helaas is het simpel versleutelen van een wachtwoord niet genoeg: veelgebruikte hashes zijn eenvoudig op het internet terug te vinden. Het toevoegen van salts is daarom noodzakelijk. Bovendien moet de versleuteling regelmatig worden herzien, net zoals software op een computer moet worden bijgewerkt.
Bij LinkedIn werden de wachtwoorden alleen versleuteld met een (SHA1-)hash. In de tijd dat LinkedIn begon was dat een algemeen geaccepteerd beveiligingsniveau, maar inmiddels is dat achterhaald. Ze hadden geen salt toegevoegd aan de wachtwoorden en daarom zijn hun hashes eenvoudig te vergelijken met grote tabellen met bekende hashes.
In het volgende artikel leg ik je uit wat jij als gebruiker kunt doen om de impact van een gestolen wachtwoord te verkleinen.
Heb je naar aanleiding van dit artikel nog vragen? Stel ze gerust hieronder in het commentaar-veld.
hallo ik heb dus ook een probleem met mijn wachtwoorden die worden opgeslagen als plaintekst, nu wil ik dit graag aangepast hebben naar sha1 maar kan eigenlijk nergens vinden hoe ik dit stapsgewijs zou moeten doen, ben namelijk nog maar een beginner.
Groetjes Simone.