Wachtwoorden met een snufje zoutWachtwoorden van miljoenen gebruikers van LinkedIn liggen op straat en hackers publiceren de gegeven van bijna een half miljoen Yahoo!-accounts. Steeds vaker lezen we dat e-mailadressen, wachtwoorden en persoonsgegevens zijn gehackt omdat websites slecht zijn beveiligd. Daar is wel iets tegen te doen. Een ‘snufje zout’ helpt.

Slecht beveiligde websites vormen een ernstig probleem. In dit artikel leggen wij u uit waarom dat zo is en hoe u kunt voorkomen dat wachtwoorden van úw gebruikers op straat komen te liggen.

Het grote gevaar van ‘gelekte’ wachtwoorden zit hem vooral in het feit dat veel mensen voor al hun beveiligingen (Hotmail, Facebook, LinkedIn, internetbankieren) hetzelfde wachtwoord gebruiken. Stelt u zich eens voor wat anderen over u te weten kan komen als hij dit wachtwoord te pakken krijgt. Hij kan zich zelfs online voor u uitgeven. Identity theft, noemen ze dat.

Er zijn verschillende manieren om wachtwoorden op te slaan. Hieronder volgt een opsomming van de meest gebruikte.

 

Plain text wachtwoorden

De meest eenvoudige manier om wachtwoorden op te slaan is als plain text (platte tekst). Dit betekent dat ergens in de database uw wachtwoord test123ab als leesbare tekst is opgeslagen. Zonder versleuteling dus. Als de database wordt gehackt, hoeft de hacker geen enkele moeite te doen de wachtwoorden te verzamelen. Het maakt niet uit hoe sterk uw wachtwoord is. Deze is simpelweg leesbaar.

 

Gecodeerde wachtwoorden

Een tweede methode om uw wachtwoord op te slaan is deze te coderen door middel van een encryptie (versleuteling). Hierbij wordt een sleutel genomen om het wachtwoord in een reeks willekeurige tekens te veranderen. Is die sleutel bekend, dan kan het wachtwoord daaruit worden herleid. Met het gecodeerde wachtwoord kan een hacker niet inloggen.

Het probleem bij encryptie is dat de geheime sleutel op de server moet worden bewaard: als tekstbestand of in de broncode zelf. Hier geldt dus ook: wordt de website gehackt dan is de sleutel bekend. Is de sleutel bekend, dan kunnen alle gecodeerde wachtwoorden worden gedecodeerd.

 

Hashed wachtwoorden

Het hashen van wachtwoorden is vrijwel gelijk aan het coderen ervan. Het wachtwoord wordt omgevormd in een lange reeks willekeurige letters en cijfers. In tegenstelling tot coderen is hashen slechts eenrichtingsverkeer. De hash is niet te herleiden tot het wachtwoord. Daarom is hashen veel veiliger.

Voorbeelden van hashfuncties en algoritmes zijn md5, sha1 en hash. In tegenstelling tot een gecodeerd wachtwoord – waarbij het wachtwoord moet worden gedecodeerd om het te kunnen valideren – wordt uw wachtwoord tijdens het inloggen omgevormd tot een hash. Die hash wordt vergeleken met de al eerder opgeslagen hash in de database. Komen die overeen, dan is het wachtwoord correct.

Er is echter één nadeel; hoewel een aanvaller de hash niet kan decoderen tot het oorspronkelijke wachtwoord, kan hij wel heel veel mogelijke wachtwoorden hashen. Net zo lang tot hij dezelfde hash heeft gevonden. Met de huidige rekenkracht van computers heeft de aanvaller dit vrij snel voor elkaar. Ook zijn de zogenaamde hash collisions mogelijk. Dat zijn meerdere wachtwoorden die – gek genoeg – dezelfde hash opleveren.

En dan zijn er nog de rainbow tables. Dat zijn lijsten met hashes en overeenkomende wachtwoorden. Een hacker hoeft zijn gevonden hash maar te vergelijken met hashes in een rainbow table om een wachtwoord te vinden dat dezelfde hash oplevert. Zoek eens in Google op e38ad214943daad1d64c102faec29de4afe9da3d en u komt al snel tot de ontdekking dat deze SHA-1 hash hoort bij het wachtwoord password1.

Gelukkig maakt de sterkte en vooral de lengte van een wachtwoord hier wél verschil. De hashes van korte en eenvoudige wachtwoorden zijn inmiddels gekraakt en publiekelijk toegankelijk. Hoe langer en sterker uw wachtwoord, hoe langer het duurt deze te kraken. U kunt veel beter drie, vier of vijf willekeurige woorden samen gebruiken als 1 wachtwoordzin (bijvoorbeeld ‘correct horse battery staple’) dan een ingewikkeld maar korter wachtwoord als kj$fsDl#.

 

Hashed wachtwoorden met een snufje zout

Een ‘gezouten hash’ (salted hash) betekent dat een willekeurige reeks karakters – genaamd een salt – is toegevoegd aan het begin of eind van het wachtwoord. Net vóór het hashen. Voor elk wachtwoord van iedere gebruiker moet een unieke salt worden gebruikt. Zelfs als de salt voor elk wachtwoord op de server is opgeslagen, is het erg lastig om de juiste salt en hash te vinden in rainbow tables. Elke hash is lang, complex én uniek.

De salt houdt u uniek door bijvoorbeeld het tijdstip van aanmelding van de gebruiker te gebruiken, of zijn naam, geboortedatum, de naam van een historische gebeurtenis op de dag van aanmelding, een willekeurige plaatsnaam, enz. Een wachtwoordhash met een snufje zout komt dus de bescherming van u en uw gebruikers ten goede.

Kan deze salted hash echt niet worden gekraakt? Helaas wel. Met de huidige rekenkracht van computer CPU’s (en even zo belangrijk: videokaarten of GPU’s) is dat niet ondenkbaar en eerder zelfs waarschijnlijk. Daarom gaan we een volgende keer in op het gebruik van zogenaamde slow hash functies.

 

Voorbeeld eenvoudige hash (PHP):

<?php
echo sha1('kj$fsDl#');
?>

geeft als resultaat: d23c75086164b6ec95136ea9efcf222453f59e7c.

 

Voorbeeld salted hash (PHP):

<?php
$salty = 'aaPn00tMies_het)Leesplankje%van$Hoogeveen';
echo sha1('kj$fsDl#' .$salty);
?>

geeft als resultaat: 8c1416bbf847877d20f1ea765c0189205f89d5c0. Maar toch hebben we hier hetzelfde wachtwoord gehasht!

 

Classic ASP:

Een tip voor ASP-gebruikers: U wilt graag sha1-hashes opslaan in plaats van de platte tekst wachtwoorden? ASP kent niet een standaard sha1-functie, maar laat het rekenwerk gewoon door de MySQL-database uitvoeren. MySQL kent deze functies wél:

<%
Option Explicit '... INSERT INTO 'Users' VALUES (default, 'Admin',
sha1(CONCAT('"&Request.Form("password")&"','salt'))); '...
%>

Deze code is ter illustratie! Uiteraard moet Request.Form (‘password’) eerst goed worden gevalideerd en beschermd tegen onder andere SQL-injection.

 

Website-ontwikkeling

De in dit artikel genoemde adviezen moeten worden meegenomen als u een website maakt. Maakt u niet zelf uw website? Vraag dan aan de ontwikkelaars of zij over de beveiliging hebben nagedacht. En hoe zij een en ander hebben geïmplementeerd.

 

Tot slot

Hebt u vragen over dit artikel of specifieke implementatie? Neemt u dan gerust contact op met onze klantenservice. U kunt ons ook een vraag stellen via het scherm Mijn vragen in MyVevida.

Hebt u zelf een goede tip, die u graag met ons wilt delen? Laat het ons weten.

Over de auteur
Jan Reilink is ruim 10-jaar in dienst bij VEVIDA als systeembeheerder. Zijn specialiteiten zijn Windows Server, IIS, PHP, websites, optimalisatie en beveiliging. Daarnaast houdt Jan al jaren een technisch blog Saotn.nl bij, met nieuws en artikelen over deze onderwerpen.