Wachtwoorden zijn nog steeds de meest gebruikte methode om gegevens te beschermen en toegang te verlenen aan die mensen die er ook daadwerkelijk bij mogen. Het is een oeroud principe: een systeem, applicatie of misschien wel gewoon een bewaker (zeg: poortwachter), die de rechtmatige gebruikers niet kent, heeft een van tevoren afgesproken “geheim” (het wachtwoord) dat de gebruiker moet noemen als hij ergens bij wil. Dit proces heet authenticatie: de poortwachter stelt vast dat de gebruiker authentiek (echt) is en verleent de bijbehorende privileges.

Versleuteling
De makkelijkste én onveiligste manier is dat de poortwachter de geheimen zelf in een lijstje bewaart. Als deze lijst in handen van anderen valt, kan iedereen onder de identiteit van gebruiker X binnenkomen. Er is dus een volgende stap nodig: versleuteling. Het geheim wordt omgezet in een vorm die versleuteld (en opgeslagen) is. Gebruiker X toont zijn eigen geheim aan de poortwachter, waarna deze de versleutelingsmethode toepast en het resultaat vergelijkt met de opgeslagen versleutelde versie die hoort bij gebruiker X. Komen deze resultaten overeen, dan krijgt X toegang.

Combinaties afgaan
De enige manier voor een indringer om zo’n geheim te breken is dat hij alle mogelijke combinaties probeert door deze via de (gegeven) methode te versleutelen en het resultaat keer op keer te vergelijken met de opgeslagen, versleutelde versie. Als alle combinaties systematisch worden geprobeerd volgt uiteindelijk de treffer: het geheim is gebroken.

Verbeteringen
Gelukkig wordt de methode van versleutelen sterker en worden de wachtwoorden langer. Vroeger accepteerden veel systemen wachtwoorden van maximaal 8 karakters. En veel gebruikers kozen simpele woorden van alleen kleine letters. Aan combinatiemogelijkheden leverde dat 26^8, ofwel 208.827.064.576 (ruim 8 miljard) woorden op. Voor een mens lijkt dat veel, maar computers kunnen vele miljoenen combinaties per seconde proberen. Stel dat een hacker over een programma beschikt dat een miljoen wachtwoorden per seconde kan proberen, dan duurt het 200.000 seconden om 2 miljard combinaties uit te proberen (dus ook de juiste). En dat is ongeveer 55 uur. Dat klinkt al anders!

Kies uit meer dan 26 tekens
We moeten ons heil dus zoeken in het vergroten van het aantal mogelijke combinaties. U hebt veel meer keus dan 26 tekens; op veel toetsenborden zijn circa 90 verschillende tekens direct in te toetsen. Verleng ten tweede uw wachtwoord, bijvoorbeeld van 8 naar 12 tekens. Deze gegevens leveren in bovenstaand voorbeeld een heel andere rekentijd op: 8949651953 (bijna 9 miljard) jaar (!) om alle combinaties uit te proberen. Zonder overdrijven kunnen we dus stellen dat indien de aarde dan nog kosmologisch zelfstandig is, de waarde van de informatie achter het betreffende wachtwoord wel vervaagd zal zijn :-). Eerlijkheid gebiedt te zeggen dat het *gemiddelde* wachtwoord natuurlijk in minder tijd gevonden zal worden, maar dan nog is dat een stuk veiliger dan de eerder aangegeven limieten van wachtwoorden gekozen uit 26 tekens met een lengte van 8.

Wachtwoorden bij XS4ALL
Wij slaan wachtwoorden op in versleutelde vorm, volgens de op dit moment als betrouwbaar te boek staande methode MD5 hashing. Formeel gezien is MD5 hashing geen versleuteling, maar een methode om in één richting (niet omkeerbaar) een wachtwoord op te slaan zonder dat de originele versie te herleiden valt. Het is mogelijk om wachtwoorden (wachtzinnen) van willekeurige lengte te gebruiken; dit is cruciaal om het een aanvaller -die simpelweg alle mogelijkheden probeert- zo moeilijk mogelijk te maken. Een goed artikel hierover: http://nl.wikipedia.org/wiki/Brute_force.

Vernieuw uw wachtwoord
XS4ALL hanteert MD5 hashing sinds 2006. Echter, sommige klanten hebben hun wachtwoord bij ons sinds de invoering van deze methode nog niet gewijzigd. Voor hen geldt in de praktijk nog steeds de limiet van 8 tekens, waardoor hun wachtwoord aanzienlijk makkelijker te kraken valt (zie boven). Deze gebruikers raden wij dus aan om eenmalig hun wachtwoord te vernieuwen, waardoor zij vanaf dat moment automatisch meeliften met de nieuwe methode.

Steekproef onder klanten: 8% achterhaald
Onlangs hebben wij een wachtwoordbreekprogramma -zoals er vele vrijelijk beschikbaar zijn- uitgeprobeerd op een steekproef van onze klanten. In feite precies zoals een hacker te werk zou gaan. In korte tijd (een volle dag) konden we circa 8% van de gebruikte wachtwoorden achterhalen zonder enige insider-kennis. Lees onderstaande tips dus goed door!

Andere valkuilen
Het is dus niet zo moeilijk om een veilig wachtwoord te kiezen dat niet snel gekraakt wordt door het uitproberen van alle combinaties. Maar er zijn uiteraard meer valkuilen. Moeilijke wachtwoorden zijn moeilijk te onthouden, dus worden ze vaak, al dan niet op slinkse wijze, opgeschreven. Slecht ingerichte programma’s kunnen de wachtwoorden onversleuteld ergens op het systeem opslaan (‘plain text’). Ook een veilig wachtwoord kan dan op straat komen te liggen. Kies daarom per omgeving een geschikt wachtwoord. Een website waar een internetter op geen enkele wijze eigen gegevens achterlaat (bv een nieuwssite) is van een heel andere orde dan de site van de bank waarop hij zijn rekeningen beheert.

Tips en trucs
1. Kies verschillende wachtwoorden, of tenminste categorieën van wachtwoorden, bij de verschillende omgevingen waar u wachtwoorden voor moet gebruiken.
2. Bedenk een manier waarbij het wachtwoord (liever: een wacht*zin*) complex blijft, maar die voor uzelf inzichtelijk en dus makkelijk te onthouden is.
3. Gebruik een wachtwoordmanager die wachtwoorden kan administreren en herkent wanneer een specifiek wachtwoord moet worden ingevuld. Met een zorgvuldig gekozen eigen centraal wachtwoord beschermt u de “private” lijst wachtwoorden. Programma’s die dit uitstekend kunnen zijn bijvoorbeeld 1Password (https://agilebits.com/) of Keepass (http://keepass.com).

Toekomst
Een van de zwakke punten van de klassieke wachtwoordbescherming is dat deze alleen maar bestaat uit dat concrete wachtwoord, dat geheim moet worden gehouden. We noemen dit ook wel 1-factorauthenticatie. In de toekomst zullen we steeds vaker een extra factor willen toevoegen aan het geheim dat iemand weet, namelijk iets dat iemand ook *heeft*. Vrijwel alle bancaire diensten werken al zo: de rechtmatige gebruiker *weet* zijn geheim, en *heeft* iets waarmee dat geheim gebruikt kan worden, zoals een bankpasje, of in het geval van electronisch bankieren, een apart apparaatje (token, identifier, challenge-response, mobiele telefoon). Deze benadering lost twee fundamentele problemen op die bestaan in de klassieke benadering van 1-factor:
1. De indringer heeft niet genoeg aan alleen het geheime wachtwoord; hij zal ook de tweede factor in handen moeten krijgen.
2. De combinatie van de 2 factoren produceert elke keer dat ingelogd wordt, een andere code.
Bij electronisch bankieren moet bij elke authenticatie de methode opnieuw worden toegepast, en resulteert deze steeds weer in een andere, voor die sessie unieke combinatie. Dat betekent dat het voor een indringer geen zin heeft om het verkeer van het netwerk af te luisteren, en de conversatie tussen gebruiker en systeem op een ander moment exact na te spelen. De verwachting is dat steeds meer diensten die voor de gebruiker belangrijk zijn, via 2-factorauthenticatie zullen worden ontsloten.

Jacques Schuurman

Jacques is Security Officer bij XS4ALL

Deel dit:

Reacties

  1. geenwiskundige says:

    “Aan combinatiemogelijkheden leverde dat 26^8, ofwel 208.827.064.576 (ruim 8 miljard) woorden op.”

    Moet dat niet “ruim 208 miljard” woorden zijn?

  2. chat says:

    Een medewerker kan immers van binnenuit ook iets verkeerd doen, bewust of onbewust.

  3. Franck says:

    Een eenvoudige methode tegen brute force aanvallen is een extra vertraging inbouwen aan de kant van XS4ALL. Dus bijv. als 2x het verkeerde wachtwoord wordt opgegeven het account voor 5 minuten blokkeren (geen logins accepteren voor dat account).

    • Addi says:

      HOE blokkeer je het account voor b.v. 5 minuten als twee keer een verkeerd wachtwoord wordt opgegeven ?

  4. Robert says:

    Wat nauwelijks aan bod is gekomen in deze discussie is de vraag hoe XS4all omgaat met Brute Force attacks. Het zou toch wel vreemd zijn als het mogelijk is om miljoenen malen een inlogpoging op een account te doen. Zoals iemand al suggereerde kan je na elke foute inlog de wachttijd langer maken. je zou ook het IP-adres kunnen blokkeren, of simpelweg het account kunnen blokkeren, of na 10 ongeldige ionlogpogingen het (gehasde) password kunnen recetten, en de gebruiker daarvan op de hoogte stellen. Hoe gaat Xs4all om met brute force hackpogingen?

  5. Cor Bosman says:

    Je kan bij XS4ALL een 2factor/ One Time Password systeem gebruiken. Dit is nog een beetje experimenteel, maar veel XS4ALL beheerders gebruiken het al, dus het wordt vermoedelijk snel gefixt als het stuk is :)

    Dit is alleen nog niet overal bruikbaar, maar in elk geval wel op https://mail.xs4all.nl.

    Je kan dit aanzetten via https://mail.xs4all.nl, onder instellingen -> calculator.

    Als je dan inlogt vanuit een onveilige plek, kunnen ze hooguit je OTP afluisteren, maar die werkt daarna niet meer.

  6. pbe says:

    Wat ik nog steeds mis bij XS4ALL is dat voor de verschillende diensten een apart wachtwoord (en evt. ook user) aan te maken valt.

    Als je nu gebruik maakt van KPN hotspots, dan ben je verplicht in te loggen met 1 en hetzelfde gebruiker/wachtwoord. Je hoeft maar 1 fake KPN hotspot tegen te komen en als je (automatisch) daarop inlogt, ligt direct je hele xs4all account open voor de misbruiker.
    Zelfde geldt voor de webdisk. 1x een man-in-the-middle-attack en alles ligt open voor misbruik.

    Wat mij betreft moet er de keuze komen dat er voor de DSL verbinding, de hoofdmailbox, selfservice centre, hotspots etc etc elk andere inloggegevens te maken.

    • Niels Huijbregts Niels Huijbregts says:

      Op Hotspots kun je inloggen met de gegevens van elke willekeurige POPbox. Als je speciaal voor Hotspots een POPbox aanmaakt die je verder nergens voor gebruikt, is de schade uiterst klein als iemand het wachtwoord zou onderscheppen.

  7. Fred says:

    Ik zou vooral graag een two-factor authentication zien bij webmail, in combinatie met “app-specific passwords” (eg voor je POP/IMAP client).

    Lees bijvoorbeeld eens wat er gebeurt wanneer je password ‘publiek geheim’ geworden is:

  8. Rob says:

    Wat te doen….?
    Als leek raak ik de draad een beetje kwijt en vraag me af of het nu wel of niet zin heeft om mijn paswoord (nu 8 karakters) te veranderen in een van 12 karakters zoals in het artikel wordt aanbevolen.
    Is het gebruik van een andere hash-methode of crypt-methode relevant indien xs4all alleen MD5 ter beschikking stelt?

    • Jacques Schuurman says:

      Ja, het heeft altijd zin om de lengte van een geheim langer te maken. Lengte is tezamen met de variatie van gekozen tekens in een geheim bij uitstek datgene wat de gebruiker zelf beïnvloedt om de sterkte van een geheim te bepalen. Bij een keuze uit 90 tekens neemt de factor waarmee zo’n geheim moeilijker te kraken is (ongeacht de onderliggende methode van hashing) met 90^4 toe, ofwel 65.610.000. In plaats van (bijvoorbeeld) 10 seconden met een supersnelle computer wordt dat ruim 20 jaar. De boodschap is en blijft: Size Does Matter.

    • OM says:

      Wat voor systeem xs4all ook gebruikt, het valt altijd aan te raden een langer wachtwoord te kiezen.

  9. Tristan says:

    Waarom nog steeds een cryptografische hash gebruiken (MD5) en geen wachtwoord hash zoals bijvoorbeeld Bcrypt?

  10. j.v.koeverden says:

    Wat is u mening betreffende het gebruik door de overheid van het door DigiD verstrekte wachtwoord in combinatie met uw BSN (dat op straat ligt) dat geschikt is voor tig overheidsinstanties van EPD tot belastingdienst en van SVB tot gemeentelijke instanties!

    • Hans says:

      @ j.v.koeverden

      (Het is me niet duidelijk hoe ik de reactie bij de originele post toevoeg. Als ik klik op de “reageer”-link van die post gebeurt er niets.)

      Het door DigiD verstrekte wachtwoord moet je meteen na ontvangst wijzigen in een zelfgekozen wachtwoord, daar zit geen probleem.

      Hoe DigiD die wachtwoorden op hun site beheert, en hoe de overheidsdiensten er toegang toe hebben, daar gaat het om. Toen het werd opgezet ging de fiscus er amateuristisch mee om: de helpdesk adviseerde, als je DigiD het niet deed, om dat van de buren te gebruiken voor het insturen van je aangifte! Hopelijk zijn de ontwerpers minder naief geweest dan de helpdesk. In elk geval zouden ze nu wakker moeten zijn, want dit heeft een paar jaar geleden in de krant gestaan.

      Potentieel is dit natuurlijk een tijdbom. De overheid /verplicht/ je om DigiD te gebruiken. Als ze het niet goed beveiligen, kan de elektronische identiteit van miljoenen burgers gestolen worden met één kraak. Dit gaat wel iets verder dan phishing naar je bankcode. De advocaten bij mijn accountant hebben de modellen voor claimbrieven al klaarliggen.

      Xs4all heeft trouwens iets vergelijkbaars. KPN hotspots heeft de inlogcodes van alle Xs4all-abonnees. Hoe kan Xs4all zekerstellen dat die codes bij hun zakenpartners veilig zijn? Als er daar een chantabele medewerker rondloopt, of iemand een domme fout maakt, kan het in een zucht gepiept zijn.

      • Jacques Schuurman says:

        KPN Hotspots beschikt niet over de credentials (inlogcodes) van onze abonnees. Wat er gebeurt is dat op het moment een abonnee van ons associeert aan een KPN Hotspot, hij of zij een https webpagina krijgt waarop gekozen kan worden voor “XS4ALL” als identiteitsprovider, en vervolgens login en wachtwoord kunnen worden opgegeven. Deze worden in versleutelde vorm door KPN rechtstreeks doorgestuurd via een proxy naar een authenticatieserver die in ons eigen domein staat, die als enige de credentials eruit kan halen, en een JA of NEE antwoordt aan de hotspot in kwestie. Die zet dan bij een “JA” toegang open tot commodity internet.

      • Hans says:

        Dit neemt een zorg weg die ik al een tijdje had. Bedankt voor deze toelichting!
        Blijft een feit dat ik mijn xs4all-wachtwoord invoer in een webpagina van KPN. Voelt nog steeds niet kosher, ook al is het secure http.

  11. Marcel says:

    @Antje, ik heb ze op een usb stick :) Ja, in een SHA512 truecrypt container, met daarin de files van mijn password manager.

    XS4ALL biedt shell access en daarmee staat toch alweer een extra gaatje open naar de infrastructuur. Ik weet niet of het nu nog zo is, maar in het verleden werden hackers uitgedaagd om in te breken. Je moet je afvragen of reputatieschade opgeteld met evt claims in verhouding is met een evt upgrade naar een beter algoritme. Ga er immers vanuit dat ieder systeem hackbaar is. Een medewerker kan immers van binnenuit ook iets verkeerd doen, bewust of onbewust.

    Als er bij een inbraak dergelijke data gestolen wordt (Er kan ook een tape gestolen worden!) en iedereen kan rustig slapen omdat het afdoende veilig is, dan heb je het goed gedaan. Lig je wakker omdat MD5 niet veilig genoeg is in de handen van onverlaten, dan heb je wat werk te doen. Bepaal op basis van dit scenario wat voldoende is.

    Terugkomend op mijn usb stick; als die gestolen wordt, dan haal ik mijn schouders op, zet de files op een nieuwe stick en blijf lekker mijn passwords gebruiken.

  12. Nettie says:

    Al die vaktaal, ik kan het als eenvoudige alpha (HBS-A) niet meer volgen………

  13. Angela S. says:

    OK, dus XS4ALL gebruikt een MD5 hash voor alle paswords…. Dan ga ik nu toch heel erg hopen dat de database van XS4ALL nooit op het Internet gaat komen te liggen, net als een weekje terug bij LinkedIn gebeurde..
    Voor MD5 is er nl. al een rainbow table waar dus gewoon in te vinden is wat er ingevoerd moet worden voor elke MD5 hash welke er in de password database gevonden wordt……
    Sorry XS4ALL, maar dit is dus een beveiliging van …….
    Ik zou toch inmiddels minimaal een salted SHA-1 hash verwachten van XS4ALL voor de password beveiliging!!!
    Mag ik dit toch wel een ‘klein beetje’ een afgang vinden voor XS4ALL???

    • Jacques Schuurman says:

      Bedankt voor de reactie. Ik wil daar graag wat kanttekeningen bij plaatsen. Ik zal in mijn reactie het woord geheim hanteren ter vervanging van wachtwoord, password, pass phrase, en wat dies meer zij.

      De gebruikte hashfunctie (in ons geval MD5) heeft een bepaalde breedte, waarbinnen de hash zal vallen. De omvang van die verzameling van potentiele hashes is, in het geval van MD5, 2^128 groot, Dat zou betekenen dat een rainbow table die een volledige opsomming zou geven van iedere mogelijke MD5 hash,

      340.282.366.920.938.463.463.374.607.431.768.211.456

      ingangen zou moeten bevaten. Ik kan verzekeren dat zo’n rainbow table niet bestaat en er geen aanwijzingen zijn dat die er snel gaat komen.

      Dat is echter de discussie niet. Wat belangrijk is, is dat er wel degelijk rainbow tables bestaan die van een (in omvang veel kleinere) verzameling aan mogelijke geheimen de bijbehorende hashes hebben opgeslagen. De omgekeerde opzoekactie is dan de wijze waarop bij een gegeven (en dus gelekte) hash, een (niet: het) bijpassend geheim kan worden gevonden. Het punt is echter dat in deze aanpak er geen enkel verschil is tussen MD5 en (bijvoorbeeld) SHA-1. Net zoals potentiele indringers ervoor kunnen kiezen om een rainbow table te bouwen met MD5, kunnen zij dat ook voor willekeurig ander hashmethode. In die zin is MD5 niet “veiliger” dan bijvoorbeeld SHA-1. De werkelijke kwetsbaarheid die ook gedemonstreerd is in MD5 is de gevoeligheid voor het ontstaan of construeren van zogenaamde collisions: twee of meer bestanden die onderling verschillend zijn, maar dezelfde hash produceren. Dit is nu bij uitstek een probleem dat niet speelt bij het hashen van geheimen. Waarom zou ik een collision (lees: tweede geheim) proberen te vinden als ik al een eerste geheim heb om ergens binnen te komen?

      Is MD5 dan een veilige methode? Het juiste antwoord is dat MD5 als hashmethode voor korte karakterreeksen niet aanwijsbaar onveiliger is dan enige andere hashmethode. De algemene kwestbaarheid zit ‘m er momenteel in dat MD5, net als ieder andere hashmethode, generiek is en standaard. Dat betekent dus dat op het moment dat ik een hashwaarde in handen krijg van een geheim dat ik nog niet ken, ik alle beschikbare rainbow tables kan afzoeken om er een passend geheim bij te vinden.

      Dit valt te voorkomen door er een zogenaamde salt aan toe te voegen. Dat is een -in ons geval toevallig bepaalde- extra combinatie van bits die ervoor zorgt dat de hashwaarde die bij het gegeven geheim hoort, niet te vergelijken valt met de waarde zonder toevoeging. Een aanval via een omgekeerde opzoekactie op rainbow tables is daarmee zinloos geworden.

      Een ander probleem, en dat hangt samen met het gedrag van de gebruikers, is de keuze van en de omgang met geheimen. Zoals hierboven al door iemand gesuggereerd is ligt het voor de hand dat mensen de complexiteit van hun gekozen geheim in relatie brengen tot datgene wat er (van henzelf) achter dat geheim beveiligd moet worden. In mijn eerdere reactie heb ik ook proberen aan te geven dat de lengte van het geheim nog meer van invloed is op de sterkte daarvan dan de variatie van de tekens waaruit het geheim is opgebouwd.

      Maar goed: ik betaal een etentje voor twee personen in een fatsoenlijk restaurant voor de eerste die een geheim publiceert korter dan 80 tekens waarvan de hash 7b6cd3491a8347b28aa1d193a88ecbe8 is. Merk op: ik heb natuurlijk een bepaald geheim ingevoerd om deze hash te berekenen, maar ik accepteer ieder ander geheim korter dan 80 karakters dat dezelfde hashwaarde produceert. En mocht je een lange collision vinden, wel, dan betaal ik een lunch.

      • Peter Lebbing says:

        U heeft het over de lengte van de waarde die de collision oplevert, en zegt daarbij dat wachtwoorden in de praktijk kort zijn. Daar gaan echter twee begrippen door elkaar lopen, in mijn ogen.

        Er zijn 2 manieren om collisions te genereren. Ik weet dat bij MD5 het mogelijk is 2 verschillende documenten te produceren met dezelfde hash; redelijk lange documenten inderdaad. En deze vorm van collision is helemaal niet interessant, want het betekent dat de aanvaller ook al het oorspronkelijke wachtwoord kiest (het eerste van de 2 documenten).

        De andere manier is om gegeven een hash, een tweede document te produceren met dezelfde hash. Dat is waar we het hier over hebben. En dan doet de lengte van dit tweede document er alleen toe als er een limiet zit op de lengte van een wachtwoord (en het document overschrijdt die limiet). De lengte van het oorspronkelijke geheim is niet interessant meer; we zijn slechts geïnteresseerd in het creëren van een tweede document dat geaccepteerd wordt en tot dezelfde waarde hasht.

        Ik heb de literatuur er niet op nageslagen, maar ik geloof dat het nog niet erg haalbaar is om gegeven een hash, een document te produceren dat dezelfde hash oplevert. Maar je moet jezelf ernstig de vraag stellen: hoe lang is de “vijand” al op de hoogte van een manier om dat te doen, voor je er zelf van op de hoogte raakt? Het is algemeen bekend dat MD5 zwakheden bevat. Ga je wachten tot je weet dat je het bokje bent?

        Het lijkt mij verstandiger om, zodra een gebruiker zijn wachtwoord verandert, dit dan maar gelijk met bijvoorbeeld een hash uit de SHA-2 familie op te slaan. Als de wachtwoordbackend niet meerdere hashalgoritmen tegelijkertijd in dezelfde database ondersteunt, is het wellicht tijd daar wat aan te doen. Zelfs crypt() uit glibc2 ondersteunt dit.

        Moraal van het verhaal: op het moment dat het duidelijk is dat een cryptografisch algoritme ernstige zwakheden bevat, kun je het beter uitfaseren, ook als de specifieke manier waarop je het gebruikt nu nog niet te kraken valt. Want je bent vast niet de eerste die te weten komt hoe het wel te kraken valt!

      • OM says:

        Kan je nog ingaan op het argument dat md5 te weinig rekenkracht vergt? phk zelf zegt dat dat de belangrijkste reden is om van md5 af te stappen: brute forcen van hashes wordt te makkelijk: http://phk.freebsd.dk/sagas/md5crypt_eol.html

        Een voordeell van bv crypt is dat ie geparametriseerd is: het aantal ronden kan je in de loop van de tijd laten groeien.

      • OM says:

        Ik bedoel natuurlijk bcrypt.

      • Jacques Schuurman says:

        Wat je zegt over bcrypt klopt. Daar zit de essentiële parameter in waarmee je de kosten (tijd dat een slag om uit te rekenen duurt) exponentieel langer kunt maken (als macht van 2). Dat moet dan wel aan de beheerkant worden gedaan, dat is niet iets dat de gebruiker zelf in de hand heeft. Zie verder ook mijn reactie van 13 juni 2012 om 05:39 op de opmerking van Marcel.

        We houden zoals gezegd dit wel degelijk in de gaten, en ik kan me goed voorstellen dat we binnen afzienbare termijn overgaan op een andere (verzwaarde) methode van wachtwoordopslag. MD5, en iedere andere enkelvoudige hashmethode wordt inderdaad snel “goedkoper” om te brute-forcen, maar met wachtwoordlengtes van 12+ is het nog steeds niet goedkoop.

    • Tristan says:

      Beide cryptografische hashes, dus niet enorm veel veiliger dan MD5, salted of niet.

  14. Hans says:

    Wat ik mis in het artikel en de reacties tot nu toe is de relatie tussen de waarde van de beveiligde informatie en de zwaarte van het wachtwoord. Voor mijn internetbetalingen heeft de bank terecht een zware methode: ik moet mijn bankpas in een doosje steken, mijn pincode invoeren, en krijg dan een eenmalige code. Voor mijn email is het al minder spannend, al wil ik natuurlijk niet dat een hacker/spammer mijn account overneemt. Daar is een middelzwaar wachtwoord genoeg, omdat de hacker niet meer dan een bepaalde inspanning zal willen doen. MD5 met wachtwoorden van 10 of 12 tekens zou daar best genoeg kunnen zijn. Maar voor al die abonnementen en simpele sites? Hoeveel tijd heeft een hacker er voor over om op mijn NRC-account de pdf-krant op te halen? Geen seconde toch zeker? Daar is een wachtwoord van 6 tot 8 posities ruim voldoende. Voor die laatste categorie heb ik een heel eenvoudig systeem: een wachtwoord van 9 posities bestaand uit drie delen, (1) een letterverhaspeling (omkering, rot-x e.d.) van de kern (4 posities) van de sitenaam + (2) een cijfercode van 4 posities met een vergelijkbaar simpel algoritme, gescheiden door (3) een leesteken dat ook door iets dergelijks wordt bepaald. Ik hoef alleen het recept te onthouden, en genereer zonder nadenken het wachtwoord. Echter… mijn systeem wordt doorkruist door eigenwijze sites die tegenstrijdige eisen stellen: de een *eist* een niet-alfanumeriek teken in het wachtwoord, de ander *verbiedt* het. De een eist minstens 8 tekens, de ander verbiedt meer dan 7. Zo loop ik inderdaad met een lijstje van wachtwoorden in mijn agenda, namelijk van de sites die zonodig beperkingen moeten opleggen aan mijn wachtwoord.
    Waarmee ik maar wil zeggen: de webmasters kunnen hun klanten plezieren door de mogelijkheden niet in te perken. Weet iemand of er al een richtlijn is voor webmasters voor een wachtwoordregime dat niet alleen kijkt naar (a) de veiligheid, maar ook naar (b) het feitelijke risico en (c) de gebruikersvriendelijkheid?

  15. Martin says:

    @Wim
    Dit is een gebruikelijke methode (niet overal echter ). Echter zijn er veel hackers die gebruik maken van bot netwerken. hierdoor zijn er vele duizenden verbindingen beschikbaar. hierdoor word het effect minder.
    daarnaast als ze de database in handen krijgen dan kunnen ze toch vrij hun gang gaan.

  16. Antje says:

    Grappig, al die pen-pushende betweters die niet onwaarschijnlijk een briefje met hun wachtwoorden aan hun beeldscherm hebben geplakt.

  17. Wim says:

    Gebruik naast het versleutel-algorithme nog een EXTRA veiligheid tegen Brute-Force kraken, bekend uit de unix-hoek:

    Na de 1e keer fout wachtwoord 1 seconde wachten,
    na elke volgende foute poging VERDUBBELT de wachttijd op dezelfde (ADSL)-lijn.

    Dus:

    Bij de 7e poging kan de PC van de hacker dus pas na 1 minuut weer een poging doen, na de 13e poging moet hij een UUR wachten!

    Dan duurt het wel erg lang voordat je alles hebt uitgeprobeerd.

  18. Louis says:

    Geweldig wat de heer of mevrouw Hiemstra schrijft. Want is dit wel zo off-topic. Wel het onderwerp waarop gereageerd wordt Iedereen heeft het over md-5, maar Hiemstra legt wel de vinger op de zere plek. Soms zijn mensen zo dom om al de gegevens voor iedereen zichtbaar te maken en dan heeft welke versleuteling waar dan ook geen enkel nut. Ik ga ervan uit dat deze persoon ons met onze neus op de feiten wilde drukken en toch niet zo dom is.

    • Hans says:

      Het is eveneens geweldig wat Louis schrijft: “Soms zijn mensen zo dom om…”. Dit is typisch redeneren vanuit eigen bekwaamheden, en iedereen die er minder van weet niet voor vol aanzien.
      Mensen worden geconfronteerd met de noodzaak om deze technologie te gebruiken, en als je er geen affiniteit mee hebt dan is het traag leren, ook als je intelligent bent.
      Ik herinner me een cartoon over iemand die ontvoerd is door marsmannetjes. Hij ligt op een onderzoekstafel in een vliegende schotel, krijgt een ingeving en zegt: “Kunnen jullie me soms vertellen hoe ik mijn videorecorder moet programmeren?”
      Ikzelf heb 25 jaar in de software business gewerkt, maar kan met een hoop van die apparaten niet omgaan. Ik heb veel gebruikersinterfaces ontworpen en gebouwd, waaronder een flink aantal goede, en krijg vaak de rillingen als ik zie wat de mensen wordt voorgeschoteld.
      Je zou zeggen, niet gebruiken als je het niet snapt. Maar je hebt geen keus, je /moet/ het gebruiken.
      Een van de eisen aan een goede software-ontwerper is dat je je moet kunnen verplaatsen in mensen die er minder van weten dan jezelf, en daar niet op neerkijken.

  19. S.R.G.M. HIEMSTRA says:

    Ik probeerde te reageren op uw aanbieding
    Spotify Premium. Het is mij tot nu toe nog steeds niet gelukt. Mijn gegevens:
    (zie ook uw schrijven van mevr. Brigitte Voskuyl dd 07.06.2012):
    loginnaam bij XS4all: hiemstr5, het door u opgegeven wachtwoord: 9149-9708-4643-0681.
    Wat moet ik verder doen? S. Hiemstra.

    • Antje says:

      Evident lollig pesterijtje. Eens zien wie er hapt.

    • ReemZ says:

      Geachte heer of mevrouw Hiemstra,

      Om uw aanvraag in behandeling te kunnen nemen, verzoeken wij u uw creditcardnummer+beveiligingscode en verloopdatum, uw bankrekeningnummer en uw BSN (voorheen SoFi-nummer) te vermelden.
      Gelieve tevens uw volledige adres te vermelden, alsmede de locatie van de reservesleutel en de vertrek- en terugkomstdatum van uw eerstvolgende vakantiereis.
      Daarnaast worden ook paspoort- en rijbewijsnummer op prijs gesteld.

      Om geleden schade recht te zetten, sturen wij u gratis een Clue-By-Four™ op, indien u binnen een week reageert onder vermelding van kenmerk ID-10-T.

    • Erik Jan says:

      Wat moet ik verder doen?
      Contact opnemen met de helpdesk en niet hier off-topic op een blog-posting reageren met een loginnaam, wachtwoord en andere persoonlijke gegevens ‘en plein public’…

  20. Henri Koppen says:

    Grappig dat de discussie zo richt op wiskundige techniek, maar dat het concept erachter vergeten wordt.

    Zelfs lichte vorm van hashen kan volstrekt veilig zijn. Als je niet meer dan 10 keer per minuut een wachtwoord mag proberen en de hash zelf niet ziet (en die zie je in principe nooit) is er niets aan de hand. De kracht en veiligheid van hashen komt pas in het geding als de hash bekend is.

    Praktisch gezien is dit op het moment dat er al toegang is tot je database en je dus in feite al de Sjaak bent.

    Als iemand de hash waarden uit je database haalt dan ben je gewoonweg al gehackt.

    Als iedereen voor elke website en dienst een ander wachtwoord zou hebben zou het laten lekken van de hashwaarden je minste probleem zijn en is de buit de toegang tot de database.

    In de echte wereld in het zo dat een groot % van de mensen geen unieke wachtwoorden bezit en het e-mailadres ook nog eens vaak de gebruikersnaam en daarin zit het venijn.

    Daarnaast vind ik het nog zacht uitgedrukt dat ik de hack eng vind aangezien LinkedIn geen clue lijkt te hebben.

    Er is ook geen policy te vinden waarin staat hoe men om gaat met ontwikkelaars en toegang tot de data. Een dump van een medewerker kan dus al voldoende zijn…

    Maar waar het op lijkt is dat beveiliging nooit de volledige aandacht heeft gehad en dat voor een beursgenoteerd miljardenbedrijf….

    • Jacques Schuurman says:

      Hij (niet de MD5 ontwikkelaar, maar iemand die MD5 gebruikt als basis in een tool) schrijft er zelf over, concreet op http://phk.freebsd.dk/sagas/md5crypt_eol.html .

      Zijn eerste zin luidt, niet voor niets, “Please note: If you don’t know the difference between MD5 and md5crypt, you should figure it out before reading any further.”

      Samengevat zegt hij dat zijn implementatie waar hij MD5 gebruikt als basis voor het hashen van wachtwoorden, niet meer veilig acht. Dat zegt hij nadrukkelijk omdat hij de snelheid waarmee brute force kan worden toegepast zo hoog vindt dat zijn methode herhaald kan worden in een tempo van “enkele dagen” voor ieder willekeurig wachtword ter lengte van acht tekens.

      Verderop in zijn eigen artikel zegt hij nadrukkelijk dat MD5 als algorithme gebruikt kan worden voor het hashen van wachtwoorden, zij het in combinatie met andere methodes, liefst ook lokaal specifiek (dus niet herhaalbaar over verschillende omgevingen).

      • OM says:

        En dan volgt de vraag: gebruikt xxs4all op dit moment md5crypt of een ander methode?

  21. OM says:

    Toch zegt US-CERT dat md5 niet meer gebruikt moet worden, zonder verdere qualificatie.

    http://www.kb.cert.org/vuls/id/836068

    “Do not use the MD5 algorithm
    Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use.”

    Dat xs4all het beter denkt te weten geeft me niet veel vertrouwen.

    • OM says:

      nader uitgelegd: dat md5 voor lange strings een lagere collision weerstand heeft dan eerder gedacht zou best wel eens kunnen betekenen, dat er ook voor korte strings snellere dan brute force methoden zijn om gegeven een hash het wachtwoord te construeren. Alleen al dat gegeven is genoeg om van md5 af te stappen.

      • vincent says:

        Natuurlijk adviseert CERT ertegen zonder qualificatie, waar zouden ze de grens moeten leggen? md5 is veilig tot 2000 tekens ofzo? :-)

        Terug in de praktijk; md5 is in 1991 bedacht en het heeft tot 2004 geduurd voordat er echte collissions zijn gevonden. Intussen zijn we weer bijna tien jaar verder en er is nog geen manier om md5 hashes doelgericht te decoderen, al het werk gebeurt nog met rainbowlijsten en brute-force. Dus om het nou onveilig te noemen…

        Los van dat wordt er bij hash meestal een salt toegevoegd zodat de string die je vindt bij het decoderen niet de originele string meer is. Zolang je niet weet hoe de string is gesalt heb je dus niets aan de gedecodeerde string, ook niet als je hem “eenvoudig” uit een md5 hebt gehaald.

      • OM says:

        In sommige gevallen worden er wel gequalificeerde richtlijnen gegegeven. Bijvoorbeeld voor de lengte van RSA keys. Daarbij wordt meegewogen hoe lang de data beveiligd moet blijven of waarvoor een certificaat en key gebruikt worden. Een ongequalificeerde richtlijn betekent gewoon: doe het niet, stop ermee.

        Verder worden bij veel password files de salts opgeslagen bij de hash…

        Maar om even terug te komen op het originele onderwerp: ik vind het nog steeds merkwaardig dat xs4all vasthoudt aan md5, terwijl er genoeg tekenen zijn dat md5 zwakheden vertoont. Misschien nog geen zwakheden die NU uitgebuit kunnen worden, maar dat is slechts een kwestie van tijd,
        hoewel, misschien hebben onderzoekers md5 al afgeschreven en spenderen er geen tijd meer aan ;-)

        Nu overgaan naar een ander type hash is verstandig denk ik. Er zijn genoeg candidaten.

  22. vincent says:

    “maar om MD5 een ‘als betrouwbaar te boek staande methode’ te noemen lijkt me niet echt juist?”

    Toch wel. Waar dat artikel over gaat is de hype van de collissions. Er bestaan strings van meer dan 2000 tekens, die wel verschillen van elkaar, maar toch dezelfde hash opleveren. Dat is opzich natuurlijk logisch, in een string van 32 hexadecimale tekens kun je nu eenmaal niet oneindig veel codes genereren dus dubbelen zijn gegarandeerd. Dat geldt ook voor SHA en elke vorm van hashing waarbij de uitkomst korter is dan de invoer.

    Jouw wachtwoord is korter dan 2000 tekens dus op basis daarvan is het al een non-issue, maar voor aanloggen maakt het ook niet uit of er twee strings zijn die hetzelfde opleveren; je moet nog steeds een van de twee strings weten.

  23. Jacques Schuurman says:

    In lijn met de bovenstaande reacties, waarvoor dank, is het zeker zo dat de functie die MD5 biedt om de integriteit van andere bestanden te toetsen bewijsbaar kwetsbaar is, of simpelweg stuk. Het gaat daarbij echter om het vinden (of construeren) van identieke MD5 uitkomsten van zelfgemaakte bestanden om deze te laten doorgaan voor authentieke bestanden, ook wel “collisions” genoemd. Dat is bijvoorbeeld het geval voor certificaten. Dat is dan ook een security-toepassing waarin de gebruikte methode, in dit geval MD5, bestand moet zijn tegen collisions, of in ieder geval het gemak waarmee deze geconstrueerd worden. Zie RFC6151 (http://tools.ietf.org/html/rfc6151) voor een uitgebreidere beschrijving van dit aspect.

    Vanuit de getaltheorie is dit relevant als er voldoende “ruimte” is om dergelijke constructies te maken, zoals in het in de reactie van Jona aangehaalde artikel wordt beschreven. De werkelijk gebruikte wachtwoorden (of zo je wil, wachtzinnen), zullen in vrijwel alle gevallen onder de grens van 512 bits blijven – de lengte van een enkel blok in het hashmechanisme van MD5.

    Lezen we http://eprint.iacr.org/2010/643.pdf erop na, dan zien we dat er tot nu toe een enkele collision is gepubliceerd die binnen die lengte blijft, en wel in het 49e karakter, om precies te zijn. Beide (onderling verschillende) “wachtzinnen” produceren een identieke MD5 hash. In dezelfde publicatie loven de auteurs een beloning uit van 10.000 Amerikaanse dollar voor de eerste die ook een collision-kwetsbaarheid publiceert die binnen 1 blok blijft, dus binnen 512 bits. De auteurs gaan in de publicatie niet in op de methode die zij hebben gebruikt om deze collision te construeren, maar de suggestie wordt gewekt dat ze er een methodiek voor gebruikt hebben die algemener toepasbaar zou zijn. Details geven ze echter niet om “redenen van veiligheid”.

    Dit zijn echter allemaal zwaar theoretische bespiegelingen. Lezers die hier enthousiast van worden kunnen beslist eens beginnen aan ftp://cm.bell-labs.com/who/akl/key_lengths.pdf, over de theoretische achtergronden achter sleutellengtes (van cryptografische functies).

    Als we naar de praktijk kijken, kunnen we tot nu toe vaststellen dat MD5 voldoet aan de eisen die gesteld kunnen worden aan het opslaan van wachtwoorden in een vorm die niet omkeerbaar is. Omdat (algemeen genomen) de ruimte die gebruikt wordt voor wachtwoorden te klein is kan het construeren van een collision (hetgeen een pseudo-wachtwoord zou opleveren dat het systeem bij de neus neemt) als een ondergeschikte manier van aanval worden beschouwd dan -nog steeds- de simpele brute force methode. Omdat MD5 als methode met een mooi woord “deterministisch” is, dat wil zeggen bij dezelfde invoer altijd dezelfde uitvoer produceert, kan gebruik worden gemaakt van het feit dat vele wachtwoorden al eens via MD5 gehasht zijn, en dat deze resultaten beschikbaar zijn om de “omgekeerde” opzoekactie te doen. Dergelijke tabellen worden “rainbow tables” genoemd en zijn in veel soorten en maten publiekelijk beschikbaar. Een overzicht vind je op

    http://www.stottmeister.com/blog/2009/04/14/how-to-crack-md5-passwords/

    en een voorbeeld genoemd in dat concrete artikel vind je op

    http://www.tmto.org/pages/passwordtools/hashcracker/

    Een tool die gebaseerd is op de collectieve inspanningen op het internet om MD5 hashes te “kraken” (feitelijk het gedistribueerd opbouwen van een rainbow table) wordt gehost achter

    http://www.md5decrypter.co.uk/

    en claimt “We have a total of just over 8.7 billion unique decrypted MD5 hashes since August 2007”. Nu lijkt dat veel, maar op een totale ruimte van 2^128 is dat een verwaarloosbare kleine fractie. Als een aanvaller een volledige dekking nastreeft (alle combinaties) dan is, uitgaande van 90 mogelijke tekens per positie, een lengte van “slechts” 90log(8700000000) = 5,09 volledig uitgerekend. Experimenteer zelf eens met deze machine als volgt:

    1. Ga naar http://scriptserver.mainframe8.com/md5.php
    2. Voer daar een woord of zin in
    3. Kopieer het resultaat in je lokale buffer
    4. Ga naar http://www.md5decrypter.co.uk/
    5. Plak het resultaat uit je buffer in het bovenste veld
    6. Geef de anti-automaatcode in, rechtsonder
    7. Start “Decrypt Hashes”
    8. Verbaas je over het resultaat (of niet)

    Uiteindelijk gaat het erom dat gebruikers beseffen wat de werkelijke technologie achter wachtwoordbescherming is en kan (en wat zij vooral niet kan), en dat de mate waarin een wachtwoord sterk en bestand is tegen wiskundige, algorithmische of brute force aanvallen, veel meer samenhangt met de (door de gebruiker bepaalde) lengte en variatie, en minder met de (door de dienstleverancier bepaalde) methode.

    Vanzelfsprekend houden wij deze ontwikkelingen in de gaten, en zullen, als daar gerede aanleiding voor ontstaat, zeker overstappen naar een andere methode van wachtwoord-“versleuteling”.

    Jacques Schuurman
    XS4ALL

  24. Jasper says:

    @Bart zonder onderbouwing kun je dit soort stelingen niet hard maken aangezien de “man in de browser”niet beschikt over het token.

    • Luc says:

      @Jasper Naturlijk kan de man in de browser het token verkrijgen: Hij vraagt simpelweg aan de gebruiker om het in te voeren. Of the man in the browser wacht tot ergens een token ingevoerd moet worden, en gebruikt het vervolgens voor eigen doeleinden.

      De enige (matige) beveiliging hiertegen is om in de tweede factor (bijvoorbeeld een SMS) te zetten waar het token toegang tot geeft; bijvoorbeeld het bedrag.

  25. Bart says:

    “1. De indringer heeft niet genoeg aan alleen het geheime wachtwoord; hij zal ook de tweede factor in handen moeten krijgen.”

    Ook dit is te omzeilen. We kennen allemaal de berichten over banking trojan’s. Ook bekend als: “The man in the browser attack” (Dit als varaiant op de: “Man in de middle attack”

    2-factorauthenticatie, of inloggen met met een token wat een steeds wisselende code genereert, is dus, als er gericht energie ingestoken wordt, gewoon te omzeilen en beidt niet meer de hoge veiligheid die je graag zou willen hebben.

  26. OM says:

    Inderdaad. Erg jammer van een verder informatief en relevant artikel.

  27. Jona says:

    MD5 komt me inderdaad ook enigzins vreemd voor? Van http://en.wikipedia.org/wiki/MD5:

    In 1996, a flaw was found with the design of MD5, and while it was not a clearly fatal weakness, cryptographers began recommending the use of other algorithms, such as SHA-1—which has since been found also to be vulnerable. In 2004, more serious flaws were discovered in MD5, making further use of the algorithm for security purposes questionable—specifically, a group of researchers described how to create a pair of files that share the same MD5 checksum. Further advances were made in breaking MD5 in 2005, 2006, and 2007. In December 2008, a group of researchers used this technique to fake SSL certificate validity, and US-CERT now says that MD5 “should be considered cryptographically broken and unsuitable for further use.” and most U.S. government applications now require the SHA-2 family of hash functions.

    Misschien dat het platform dat XS4ALL gebruikt dit nog niet ondersteund voor wat voor reden dan ook, maar om MD5 een ‘als betrouwbaar te boek staande methode’ te noemen lijkt me niet echt juist?

  28. egdk says:

    volgens de op dit moment als betrouwbaar te boek staande methode MD5 hashing

    MD5 wordt tegenwoordig afgeraden aangezien deze te weinig computer kracht kocht en erg snel te kraken valt. Met een redelijke PC met grafische kaart is het mogelijk om 200 miljoen “pogingen” per seconde te doen, waardoor het wachtwoord met 8 tekens zelfs al binnen 40 seconden geraden kan worden. Wanneer (en niet als) XS4ALL’s database gekraakt wordt en alle MD5 hashes naar buiten komen is het zeer waarschijnlijk dat minstens de helft van alle hashes binnen een week gekraakt kan worden door 1 moderne pc. Niet echt wat je noemt veilig.

    Ik vind het raar dat een bedrijf dat in veel opzichten zo voorop loopt met de telecommunicatie (ipv6 bijvoorbeeld) nog MD5 als hashing methode gebruikt!

    • Tommoch says:

      @egdk

      Wat heeft de grafische kaart met de rekensnelheid te maken?

      • Dennis says:

        MD5 hashes zijn ooit ontworpen om validatiehashes/signatures te maken, dus om te kijken of een bestand niet stiekem gewijzigd is. Daardoor is het algoritme ook geoptimaliseerd om snel te zijn. Daarnaast zijn MD5 hashes heel goed te parallel te berekenen, vandaar de grafische kaart, die juist bij uitstek geschikt is voor parallele berekeningen.

        Ik zou liever zien dat xs4all transparant overschakelt naar bcrypt, of het minder bewezen (maar theoretisch sterkere) scrypt. bcrypt heeft overigens al veel nette implementaties die de work-factor + salt in 1 string opslaan. Zo kun je over de jaren ook de work factor opvoeren, dat gaat dan automatisch zodra een gebruiker zijn wachtwoord wijzigt.

        ps. het verschil tussen bcrypt en md5/sha/etc is niet een factor 10 maar eerder 10^5. Dan is je wachtwoord niet alleen veilig tot het einde van de wereld maar ook het einde van het heelal ;)

        Aardig artikel over het veilig hashen van wachtwoorden en waarom md5/sha hashes niet heel geschikt zijn