Tweakers test wachtwoorden gebruikers, mag dat?

strong-password.pngUit onderzoek van Tweakers.net blijkt dat veel geregistreerde gebruikers in de praktijk een relatief zwak wachtwoord hebben ingesteld, rapporteerde de techsite gisteren. In minder dan een half uur bleek de helft van de versleutelde wachtwoorden eenvoudig te kraken met standaardtools. Leuk, alleen vroegen diverse mensen zich per mail af of dit eigenlijk wel mag, wachtwoorden gaan kraken van je gebruikers.

De analyse van Tweakers lijkt me in alle oprechtheid opgezet, maar dat is natuurlijk geen argument dat je dús binnen de wettelijke grenzen zit. Maar als je alleen intern test of wachtwoorden wel veilig zijn, en er voor zorgt dat niemand (ook de redactie die erover gaat schrijven niet) toegang krijgt tot de wachtwoorden zelf, dan zie ik eerlijk gezegd het probleem niet.

Het testen van wachtwoorden is een volstrekt gebruikelijke handeling, hoewel deze normaal alleen gebeurt bij het inschrijven. De bekende rood/geel/groene indicatoren zijn het bekendste voorbeeld, maar periodieke controles op wachtwoorden zijn niet ongebruikelijk. Verstandig ook, want kwaadwillenden kunnen óók zulke kraaksoftware draaien en zo proberen binnen te komen. Je kunt dus zelfs betogen dat Tweakers verplicht is sterke wachtwoorden af te dwingen omdat zij (de persoonsgegevens van) haar gebruikers moet beschermen.

Natuurlijk áls het misgaat en een derde bij het wachtwoord kan, dan is Tweakers de pineut. De voorwaarden met hun aansprakelijkheidsbeperking helpen dan niets: wie zelf wachtwoorden gaat kraken en dan deze lekt of laat misbruiken, handelt “grof nalatig” en is hoe dan ook aansprakelijk voor alle schade die mensen lijden.

Journalistiek heel interessant maar juridisch echt problematisch zou zijn om te kijken of diezelfde gebruikersnamen en wachtwoorden ook werken bij andere forums.

Meelezende sysadmins: hoe testen jullie wachtwoorden van gebruikers?

Arnoud<br/> Afbeelding: Strongpasswordgenerator.com

39 reacties

  1. Deze quote van de Tweakers pagina zette mij toch wel aan het denken: Nota bene: zoals ook in de uitgebreidere .plan is vermeld, is dit onderzoek uitsluitend door medewerkers van Tweakers.net verricht Het zegt namelijk niets over het omvang van de groep laat staan de kwalificaties.

  2. Subtiel verschil is dat de indicatoren die jij noemt een stukje javascript zijn, waarmee (strikt gesproken) de gebruiker zijn eigen wachtwoord test. In dit geval poogt tweakers de wachtwoorden de achterhalen nadat ze beveiligd zijn. Ik ben het met je eens dat het geen probleem is, gegeven de voorwaarden die je noemt, maar het is wel een verschil :-).

  3. Ik test ze niet, en kan dat ook niet. Ik bewaar alleen een hash van het wachtwoord (met wat random data erdoor gemengd), en omdat theoretisch meerdere wachtwoorden naar dezelfde hash kunnen wijzen, kan ik nooit meer vaststellen welk wachtwoord echt gebruikt is.

    Ik laat de hash nu nog berekenen op de server, maar ben van plan dat te verschuiven naar de client (browser), zodat op die manier ook een potentiële “bewaarplicht” omzeilt kan worden, en het wachtwoord helemaal niet meer over de lijn hoeft te gaan.

    Te complexe wachtwoorden vereisen is op zichzelf een veiligheidsrisico, omdat het mensen ertoe verleidt ze toch maar op te schrijven.

  4. @Jeroen: op het internet is een opgeschreven, complex wachtwoord veelal veiliger dan een te simpel wachtwoord. Voor lokale login account is een opgeschreven wachtwoord een risico omdat iemand het briefje kan vinden. Maar als je die dan weer goed opbergt.

    Maar een hacker zal niet snel bij jou inbreken om je opgeschreven wachtwoord voor bijvoorbeeld Tweakers te vinden. Dus of opgeschreven wachtwoord een risico is hangt van de situatie af, met name waar het wachtwoord voor is, en waar het opgeschreven wachtwoord ligt.

  5. @Jeroen Hellingman: “omdat theoretisch meerdere wachtwoorden naar dezelfde hash kunnen wijzen, kan ik nooit meer vaststellen welk wachtwoord echt gebruikt is.” Correct maar als zowel “hallo” als “Ekne4_oe45tiine.rutk*TDk” naar dezelfde hash leiden, kan de gebruiker wel de laatste ingevoerd hebben, maar met beide kun je inloggen. Dus er hoeft maar een simpel wachtwoord naar de hash te leiden. Daarnaast geldt dat de kans op zgn collisions wel groot is maar of dat beide als wachtwoord zijn te gebruiken lijkt me uitgesloten. Sterker nog als de wachtwoorden beperkt zijn is lengte (bijv nooit langer zijn dan een character of 16) dan is de kans of collisions al een flink stuk kleiner.

  6. @3 Ook bij tweakers ging het om hashes. Wel om simpele MD5 hashes. Die bleken dus in zeker de helft van de gevallen zeer snel gekraakt te kunnen worden.

    Het was eigenlijk vooral verontrustend dat een dergelijke grote ICT site nog zulke zwakke wachtwoordencryptie gebruikte. MD5 is echt niet meer van deze tijd en zou je inmiddels kunnen zien als een teken van zeer zwakke beveiliging.

  7. @Jeroen:

    Ik test ze niet, en kan dat ook niet. Ik bewaar alleen een hash van het wachtwoord (met wat random data erdoor gemengd), en omdat theoretisch meerdere wachtwoorden naar dezelfde hash kunnen wijzen, kan ik nooit meer vaststellen welk wachtwoord echt gebruikt is.

    Dat is onzin (althans, in praktische zin). Als je ze niet zou kunnen testen, zou dat ook betekenen dat je de login van je eigen gebruikers niet kunt valideren tegen je eigen database. Het ís te testen. Dat je het echte wachtwoord niet per definitie terugvind is waar, maar beschermt je eerder alleen in theoretische zin. Collissions bestaan zeker, maar je moet wel een erg slecht algoritme gebruiken wil je hier veel van tegenkomen.

    De hash berekening verschuiven naar de client heeft overigens ook zeker niet alleen voordelen. Je moet je dan wel behoorlijk beschermen tegen replay attacks. Zie ook: http://stackoverflow.com/questions/1380168/does-it-make-security-sense-to-hash-password-on-client-end.

  8. Inmiddels is Tweakers overgestapt op een andere manier van opslag. Via PBKDF2. http://tweakers.net/plan/587/development-round-up-augustus-2011-iteratie-4.html

    Ik test wachtwoorden altijd via een simpele regex. In de toekomst wil ik gebruik gaan maken van: http://rumkin.com/tools/password/passchk.php

    “Ik laat de hash nu nog berekenen op de server, maar ben van plan dat te verschuiven naar de client (browser), zodat op die manier ook een potentiële ???bewaarplicht??? omzeilt kan worden, en het wachtwoord helemaal niet meer over de lijn hoeft te gaan.”

    Je bedoeld via SHA1 met JavaScript? Deze is techniek is al langer bekend en werkt voor geen meter, een hash versturen is niet veel anders een wachtwoord. Alleen dat het wachtwoord niet zichtbaar is, maar het is net zo, al dan niet makkelijker om te kraken.

    Een PBKDF2 via de client-side gaat niet werken omdat je de salt waarde nodig hebt om een goede hash te kunnen maken. EN DIE WIL JE ECHT NIET VRIJGEVEN VOOR CONTROLE!!

    De enigste veilige manier is via een goed password hashing systeem als PBKDF2 of bCrypt (crypt() met Blowfish). password hashing is anders dan ergens een hash-waarde (checksum) van berekenen.

    Een password hashing systeem levert elke keer een ander resultaat op en is waardeloos zonder de salt. Dus je kan niet vergelijken hash==hash, als je de salt niet hebt, je kan alleen de juiste match vinden. En dat gaat langggg duren.

    http://security.stackexch…rypt-for-password-storage

    En voor de verbinding, SSL/TLS. Maar dat is alleen als het echt veilig moet zijn.

  9. Met je conclusie dat deze test juridisch riskant is ben ik het oneens gezien de redenering die er aan ten grondslag ligt. Allereerst is het zo dat als een wachtwoord al zo eenvoudig te kraken is met standaard tools, dat een aanvaller dat ook kan. Je maakt het een aanvaller nog net even iets makkelijker, maar praktisch maakt dat niet veel uit. Daar komt bij dat je als website eigenaar voor een adequate verhaspeling (hashing) van de wachtwoorden dient te zorgen. Door bijvoorbeeld geen MD5 voor de hashing te gebruiken, maar SHA-256 en natuurlijk een salt (nog beter als de salt per wachtwoord willekeurig en uniek is). Het onveilig opslaan is juridisch riskant, niet het testen of het onveilig opgeslagen is. Als derde punt is de gebruiker er zelf ook voor verantwoordelijk om een sterk wachtwoord te kiezen en deze niet te recyclen op verschillende websites. Als laatste punt worden wachtwoorden continue op eenzelfde wijze verwerkt, namelijk op het moment dat de gebruiker probeert in te loggen. Dan komt ook vast te staan wat het wachtwoord van de gebruiker is. Waar het om gaat is dat je dat wachtwoord niet opslaat bij die verwerking, maar enkel het resultaat (correct of niet correct) bewaart en wordt gebruikt voor verdere verwerking, bij het inloggen om te kijken of dat gelukt is en bij deze test of dat een wachtwoord (eenvoudig) te kraken is.

    Resumerend is de test die Tweakers.net heeft gedaan juridisch helemaal niet riskant. Het niet (veilig genoeg) verhaspeld opslaan van de wachtwoorden van je gebruikers in je database is dat wel, maar dat is een ander verhaal.

  10. Ik laat de hash nu nog berekenen op de server, maar ben van plan dat te verschuiven naar de client (browser), zodat op die manier ook een potentiële ???bewaarplicht??? omzeilt kan worden, en het wachtwoord helemaal niet meer over de lijn hoeft te gaan.
    Dat is wel een tikje naief. De gedachte achter een hash is dat er een bewerking buiten het bereik van de gebruiker/aanvaller plaatsvindt, of met een parameter die buiten het bereik van de gebruiker/aanvaller is (een zgn. salt of secret).

    Het gebruik van een client-side berekende hash is niet veel veiliger dan het gebruik van wachtwoorden en deze plain-text op de server opslaan. – vatbaar voor sniffing, man-in-the-middle en reply attacks; – als je database op straat komt beschikt men over de hashes en daarmee kan men rechtstreeks inloggen;

    Voor bijna alle zaken met betrekking tot hashing geldt: probeer nou niet zelf een nieuw of mooier wiel uit te vinden. Ik lees ook regelmatig verhalen van ‘briljante’ mensen die bijvoorbeeld hash functies gaan nesten. Het enige wat je doet is het algoritme of het proces zwakker maken.

  11. @Arnout: Ik vind de test van Tweakers niet riskant. Dat zeg ik ook niet.

    Het enige dat me riskant zou lijken is als T.net met een gekraakt wachtwoord gaat proberen of die user/pass combinatie ook werkt bij andere sites, zeg Fok! of GeenStijl. Dat is journalistiek interessant – inderdaad, mensen gebruiken hetzelfde wachtwoord op meerdere sites – maar je breekt dan volgens mij wel in op iemands account ergens anders.

  12. @Arnoud: Ik reageerde op deze passage, niet die er onder staat: “Natuurlijk áls het misgaat en een derde bij het wachtwoord kan, dan is Tweakers de pineut. De voorwaarden met hun aansprakelijkheidsbeperking helpen dan niets: wie zelf wachtwoorden gaat kraken en dan deze lekt of laat misbruiken, handelt ???grof nalatig??? en is hoe dan ook aansprakelijk voor alle schade die mensen lijden.”.

  13. Naar aanleiding van mijn eerdere opmerkingen over wachtwoorden en het feit dat ik wat wachtwoorden aan het wijzigen was kwam ik dit tegen: http://www.baekdal.com/tips/usable-security-reply-to-security-now/

    Voor mij een eye-opener. Er staan bovenaan nog wat links naar andere artikelen van dezelfde auteur.

    Overigens ook handig en interessant: https://www.grc.com/haystack.htm

    Dit slaat zoals de auteur al aangeeft vooral op internet wachtwoorden, niet op root wachtwoorden van servers. Maar ook daar gaat voor een deel hetzelfde op.

  14. De grond van de zaak lijkt mij toch niet zo moeilijk. Als het bedrijfsbeleid sterke paswoorden vraagt kan een algemene routinecontrole die kijkt of ze sterk zijn m.i. zonder probleem. Zodra de test meer doet moet je opletten. Wie vertel je wat? “10% van onze gebruikers heeft een goed paswoord”. Hm. “Jip en Janneke hebben een zwak paswoord”. Hm. Hm. @arnoud: Interessanter: als het bedrijfsbeleid zegt: geen paswoorden delen met diensten op het internet en je wil dat testen, mag dat? Ik zoek een paswoord, vind er één en kijk of het werkt op google, ms, twitter… Ik rapporteer alleen dat het hetzelfde is, niet het paswoord, niet de gebruiker.

    Beetje buiten topic: je ziet vaak voorstellen om authenticatie algorithmen te verbeteren. Moeilijk en gevaarlijk werkje. Voorbeeld 1: de hash/md5/sha1 client side berekenen lijkt geweldig: het paswoord gaat niet meer over de lijn, de server ziet het nooit! Maaaar ook niet nodig: de hash kennen is voldoende (wordt het “nieuwe” paswoord) dus de server kent alle paswoorden en ze staan er open en bloot. voorbeeld 2: versleutelen ipv hash. Daarvoor heb je de sleutel nodig op de server, en de sleutel met de db samen lekt alle paswoorden ineens, wat een groter risico is dan een db met hashes die je nog moet kraken. voorbeeld 3: hashes worden best niet “naakt” gebruikt. Dus niet de hash(paswoord), maar hash(salt+paswoord) waarbij salt willekeurig bepaald is per gebruiker. Zelfde voor versleutelde paswoorden, trouwens.

  15. @André: Het testen van zo’n wachtwoord bij een externe site is riskant, je weet niet of zo’n site te vertrouwen is. Deze vind ik nog steeds een hele mooie:

    In de praktijk zal niemand erover vallen zolang het niet tot een inbraak leidt. Het lijkt me ondenkbaar dat je geschorst (of zelfs ontslagen) zou kunnen worden door het enkele gebruik van zo’n externe dienst. Komt er wél een probleem van, dan is die overtreding van het reglement reden om de werknemer aan te kijken over de schade.

  16. Ik test de wachtwoorden van mijn gebruikers helemaal niet, omdat ik dacht dat het proberen te kraken ervan illegaal zou zijn. Misschien toch maar eens doen, nu ik weet dat het binnen bepaalde grenzen best mag.

    Overigens heb ik liever dat mensen met een key inloggen dan met een wachtwoord. Dat is praktisch onmogelijk te bruteforcen, zelfs als je de public key is handen zou krijgen. Wie op andermans account wil inloggen met een key zal toch eerst echt de key zelf (een bestandje) moeten stelen. Het is erg jammer dat je niet gemakkelijk zulke op authenticatie kunt toevoegen aan e-mail- en webdiensten; het blijft beperkt tot SSH.

  17. @Juerd +1. Waarom kan ik niet met mijn public key inloggen op webdiensten? Liefst met de secret key ergens veilig in de hardware van mijn computer, waar ie niet gestolen kan worden door nare trojans.

    Het kraken van een wachtwoord is an sich niet verboden. Het gebruik van een gekraakt/geraden wachtwoord om in te loggen is dat wel. Ook het voorhanden hebben van een wachtwoord is strafbaar (art. 139f Strafrecht) maar dan moet wel bewezen worden dat je opzet had dat daarmee ingebroken wordt – door jou of door een ander.

  18. Wat ik weet is dat diverse sites de tekens voor wachtwoorden beperken tot letters en cijfers en speciale tekens zoals !@#$%^&* erin weigeren. Erg dom!! Maar mede ook veroorzaakt door de kortzichtigheid van programmeurs en bijbehorende managers die dergelijke regels soms opleggen. Verder komt het soms voor dat wachtwoord niet hoofdletter-gevoelig is zodat ‘appel’, ‘Appel’ en ‘APPEL’ allen hetzelfde wachtwoord vormen. En dan zijn er nog genoeg sites die encryptie toepassen op een wachtwoord, zodat het wachtwoord altijd weer gedecrypt kan worden. Handig als een gebruiker een wachtwoord is vergeten want dan kan hij zijn wachtwoord ook gewoon opvragen. Handiger nog voor hackers die gewoon de database met wachtwoorden decrypten en dan overal bij kunnen.

    Ook leuk: sites die wachtwoorden beperken tot een maximale lengte! Zelfs Windows heeft moeite met extreem lange wachtwoorden, terwijl je in principe alleen een hash-waarde over een wachtwoord hoeft te bewaren en die hash heeft altijd een vaste lengte. Betekent dat mijn favoriete wachtwoord ‘Osewiesewosewiesewallakristalla’ meestal niet geaccepteerd wordt! 🙂 Gelukkig hebben veel bedrijven het goed begrepen en hanteren ze een minimum lengte van 6 tot 8 tekens, waarbij hoofdletters en kleine letters, nummers en speciale tekens gebruikt kunnen worden.

    Overigens kun je wachtwoorden eenvoudig testen, ook al als je alleen maar een hash ervan opslaat. Hiervoor pas je een ‘dictionary’ methode toe, waarbij je de meest populaire wachtwoorden (123abc, abc456, qwerty1) en kleine varianten hierop door je hash-functie haalt en vervolgens zoek je in je wachtwoorden tabel naar hashes die overeen komen met de hashes die je uit je dictionary hebt berekend. Grappig genoeg bestaat er altijd de kans dat een gebruiker in werkelijkheid een ander wachtwoord heeft, maar dat de hash-functie voor de twee verschillende wachtwoorden domweg dezelfde waarde genereert. Zo kan je wachtwoord ’42#$%WPF69′ overeen komen met het wachtwoord ‘abcdef’ domweg omdat de hash-formule ermee rekent en voor beiden de waarde 0x123456 genereert. (Zomaar een voorbeeld.) Want een hash-functie is in principe meer beperkt dan een wachtwoord van oneindig veel tekens. Als de hash-waarde een 32-bits getal is, dan heb je ruim 4 miljard mogelijkheden. Dus ook een kans van 1 op 4 miljard op een “false positive”. Een kleine kans, maar niet verwaarloosbaar! Echter, sommige hash-functies doen nog een “Result MOD Priemgetal” waardoor het resultaat een nog kleiner bereik heeft maar de hash wel lastiger terug te rekenen is. De kans op false positives wordt dan wel weer groter!

    Zoveel moeilijker zijn hashed wachtwoorden dus ook weer niet. Immers, in geval van een hash hoef je niet het originele wachtwoord te kennen. Je moet alleen een wachtwoord kennen dat na hashing de betreffende hash-waarde oplevert.

    Beveiliging is altijd lastig. Het helpt als je uit gaat van de “Worst case” scenario’s. Bijvoorbeeld dat een hacker je complete gebruikers-database in handen heeft en deze probeert te ontcijferen. Of dat de “man-in-the-middle” aanval wordt uitgevoerd. Deze mogelijkheden moet je vervolgens afwegen tegen de kosten die je moet maken om de beveiliging op te voeren. En je moet berekenen hoeveel het de hacker uiteindelijk gaat kostem om de boel te kraken. Want die hacker moet ook een baten/kosten analyse maken. Als het de hacker meer kost om een wachtwoord te kraken dan het hem potentieel oplevert dan gaat hij wel elders heen. Of als de hacker een verhoogd risico heeft om getraceerd te worden gaat hij ook elders proberen. Ze zoeken immers de zwakste schakels. Het is alsof je met Professor Challenger in de Lost World aan het wandelen bent. Plotseling duikt er een T-Rex op. Je hoeft dan niet harder te rennen dan die dinosaurus. Je moet alleen harder rennen dan de professor… 🙂

  19. @arnoud, 20: Dat trojan voorbeeld is nog lastiger dan je zou denken. Beetje het DRM verhaal, erg lastig om dat betaalbaar te maken (voor CAs is het wel betaalbaar… behalve bij ‘die ene’ Nederlandse blijkbaar;) ).

    @andre, 16: Hash client-side berekenen beschermt vooral tegen aanvallen (en domheden) van de (kant van de) server. Voor aanvallers tussen jou en de server heeft het inderdaad weinig zin.

    Een nadeel van voorbeeld 2 is ook nog dat encryptie duur is (in rekenkracht).

    Volgensmij hoort voorbeeld 3 al een aantal jaren tot het minimum niveau van wat je veilig kan noemen.

  20. Arnoud, Het SSL protocol biedt de mogelijkheid voor “client authentication”, waarbij de gebruiker van een “secure” website een certificaat aan de server presenteert (het spiegelbeeld van server authentication waar een gebruiker kan controleren of zij met de juiste server praat.) Het grote probleem is dat de meeste gebruikers niet over een certificaat beschikken en dat betekent dat je als website zelf aan certificaatuitgifte moet gaan doen, met alle complicaties die daar bijkomen. Als het er alleen om gaat om de beheermodule van een website te beschermen is het certificaatbeheer nog wel handmatig te doen.

  21. Met dit soort testen is het belangrijk te realiseren dat er niet geprobeerd wordt het wachtwoord van gebruiker “Jan” te kraken, maar dat er een aanname gedaan wordt dat er vast wel iemand het wachtwoord “12345678” of “tw3akers” gebruikt heeft (om maar even twee voorbeelden te noemen die er geheid tussen zitten). Vervolgens kijk je in een (geanonimiseerde) lijst met pasword hashes of er een identieke hash in staat. Met zo’n test is krijg je dus eigenlijk de omgekeerde wereld; je weet wel het wachtwoord, maar je weet niet welke gebruikersnaam erbij hoort.

  22. @MathFox Client Authentication certificaten worden desondanks toch af en toe gebruikt. Het nadeel is alleen dat je het certificaat moet meeverhuizen indien de gebruiker naar een andere PC verhuist. Toch kan het binnen een bedrijfs-netwerk goed gebruikt worden voor interne applicaties omdat de systeembeheerders met het opleveren van nieuwe laptops, computers en software ook de nieuwe client-certificaten kunnen opleveren. Toch wordt het te weinig gebruikt, terwijl het wel goed wordt ondersteund door webbrowsers, besturings-systemen en ontwikkel-software. De reden? Gebrek aan kennis over SSL, certificaten en beveiliging in het algemeen. Het is een techniek die eigenlijk geen geld oplevert voor de meeste programmeurs en dus veel te weinig aandacht krijgt. Dat is tevens het grootste probleem met beveiliging: er is geen klant die erom vraagt! Klanten willen nieuwe functionaliteit en daarnaast alleen het gevoel dat het veilig is. Schijnveiligheid is daarom ook goedkoper dan een robuuste beveiliging…

  23. @Jeroen Hellingman Hashes aan de client-zijde berekenen is inderdaad onverstandig. Zoals al gezegd is het dan niet meer nodig om de hash te kraken, je hoeft ‘m alleen maar te kennen. Bovendien is Javascript ongeschikt om cryptografische- en hashingfuncties uit te voeren. E.e.a. is enerzijds niet erg efficient en anderzijds mist het voor cryptografie benodigde zekerheden in de programmeertaal.

    @Spearhead De kans op collisions is dusdanig klein dat ik daar niet al te veel aandacht aan zou besteden.

    @Sebastiaan De per-wachtwoord salt delen met de rest van de wereld kan weinig kwaad. De salt is niet bedoeld om een moeilijker encryptie/hashing-procedure te geven. De salt is bedoeld om te voorkomen dat je meerdere wachtwoordhashes in een keer kan testen, ofwel door batch-operaties ofwel door rainbow tables.

    Een hashing-algoritme levert per definitie dezelfde hash bij dezelfde invoer op. Dus alleen als de salt verandert zal de hash ook veranderen. Om die reden is het dan uiteraard ook verstandig een willekeurige salt te gebruiken en die bij een nieuw wachtwoord voor een gebruiker ook weer opnieuw te bereken.

    @Richard “Ik lees ook regelmatig verhalen van ???briljante??? mensen die bijvoorbeeld hash functies gaan nesten. Het enige wat je doet is het algoritme of het proces zwakker maken.” Het afwisselen van hash-functies (bijv sha1(md5(wachtwoord))) is niet per se handig. Maar het is wel een vorm van “key stretching”, het proces waarbij je de operatie een aantal keren herhaald. Normaliter is een hash-functie namelijk geschreven om naast onomkeerbaar ook heel snel te zijn. Door het proces van key strechting zorg je er voor dat je bijvoorbeeld dezelfde hash-functie meerdere malen hergebruikt. De precieze manier waarop kan er inderdaad voor zorgen dat je de uiteindelijke waarde wat verzwakt en daardoor een cryptanalysis-aanval op je opslag eenvoudiger maakt, voor het brute-forcen is dat een aspect dat niet echt bruikbaar is, tenzij er uiteindelijk daardoor collisions ontstaan. De moderne varianten van unix crypt, bcrypt en ook het PBKDF1 en PBKDF2-algoritme hebben allemaal een vorm van key stretching. Het door tweakers.net gebruikte PBKDF2 doet het door middel van XOR van steeds verschillende uitkomsten van de gebruikte interne hash-functie (bijv sha256 of sha512). Het is dus vanuit cryptografisch oogpunt bezien juist verstandig om meerdere keren een hash-functie aan te roepen. Door ook hier te vertrouwen op cryptografische kennis van experts (zoals bij bcrypt, unix crypt en pbkdf1/2) kan je er voor zorgen dat het op een slimme manier gebeurt en daardoor het kraken van je wachtwoord juist langer duurt. Met X hash-calls zorg je er tenslotte voor dat het kraakproces ook X keer langer duurt, X is bij PBKDF2 aanbevolen om minstens 1000 te zijn (die aanbeveling komt uit 2000) en ik persoonlijk zou je adviseren met 10.000 te werken.

  24. @ACM: Kan je me vertellen/naar een bron wijzen waarom het versturen van hashes (over een beveiligde verbinding) minder veilig is dan het versturen van het wachtwoord (over een beveiligde verbinding)? Als je het in plain stuurt, maakt het niet uit, omdat beiden voldoen voor het binnenkomen van de account.

    Ik vraag me ook af waar je precies op doelt met je opmerking over de geschiktheid van javascript. Ik kan me goed voorstellen dat iets als PBKDF2 een probleem is, maar een enkele salt genereren en een hash als SHA1 toepassen zou toch goed moeten gaan (het enige echte probleem dat ik kan bedenken is slechte randomness). Of heeft dit met iets totaal anders te maken?

  25. @Rens Als de beveiligde verbinding betrouwbaar is, dan is het minder veilig om twee redenen: – De javascript-based encryptie is niet automatisch betrouwbaar – Als de wachtwoordhashes bij de opslag achterhaald worden, is er geen kraakproces nodig, de opgeslagen hashes zelf werken dan als wachtwoord

    Voor waarom javascript onveilig is, wil je ik je graag doorverwijzen naar dit verhaal daarover. Een punt dat die auteur niet noemt is nog: Javascript is traag, daardoor dwingt het vrij zwakke encryptie af, terwijl aanvallers doorgaans hele efficiente methodes hebben om e.e.a. te kraken. Zoals ik eerder al aangaf, je wil juist iets als key-strechting gebruiken om de wachtwoordopslag sterk te maken. Om een voorbeeld te geven; met mijn toenmalige firefox 5 was het secondewerk om 5000 iteraties sha256 uit te rekenen met PBKDF2. Met php is het iets van 0.1 seconde om er 10.000 te doen met sha512 en php staat dan niet eens bekend als bijzonder snelle taal. Waar de auteur van dat stuk vooral op ingaat is dat er in beginsel geen betrouwbare levering van Javascript is en dat er tevens geen betrouwbare runtime is – je kan nota bene (delen van) de functies van de VM zelf overschrijven… En mocht je met dat doel een beveiligde verbinding opzetten, dan heeft het weer geen toegevoegde waarde om de encryptie uberhaupt te doen. De slechte randomness is inderdaad ook nog een probleem dat hij aanhaalt.

  26. @ACM ik doelde ook specifiek op de niet-experts die hash-algoritmes op zo’n (onhandige) wijze combineren dat er sprake is van een verslechtering, met name door het ongewilde beperken van de keyspace en/of het veroorzaken van collisions.

  27. @Rens vd Heijden, het uitvoeren van een hash op de client is pas veilig als je deze weer op zijn beurt gehashed opslaat op de server. Een dubbele hash, dus. Ook hier weer het worst-case scenario waarbij de gebruikers-database is “gestolen” door een hacker. Als de hashes onbeschermd zijn opgeslagen weet de hacker wat hij vanaf een client/browser moet doorgeven om binnen de applicatie te komen en de data verder te ontfutselen. Het enige wat een hacker daarna moet doen is de broncode van de webpagina aanpassen zodat hij een hash kan invoeren i.p.v. het wachtwoord en hij is klaar. En omdat we hier praten over JavaScript is dat eigenlijk enorm eenvoudig uit te voeren… Waar het om gaat zijn aanvals-vectoren, ofwel het detecteren en aanvallen van de zwakke plekken binnen een systeem. In principe zijn er generiek gezien drie locaties om een aanval in te zetten: 1) Op de client computer in de vorm van een keylogger en andere spionage-software. 2) In de communicatie tussen client en server, ofwel de “man-in-the-middle” aanval. 3) Op de server door deze te kraken of door gewoon een medewerker om te kopen om de database aan te leveren. Feit is dat bedrijven vaak toegang geven tot de database aan meerdere werknemers binnen hun bedrijf. Dat betekent dat kwaadwillende medewerkers ervoor kunnen zorgen dat de server-data in verkeerde handen kan vallen. Wat je als bedrijf eigenlijk wilt is dat niemand binnen het bedrijf iets met die wachtwoorden kan doen, behalve dan het eventueel resetten ervan. Vandaar dat de server-side hash gewoon noodzakelijk is. Bij voorkeur is ook alle andere data van de betreffende gebruiker beschermd via encryptie omdat je niet wil dat iemand zonder de software de database kan uitlezen en zo gevoelige informatie kan verzamelen.

  28. @Wim, 34: De dubbele hash beschermt inderdaad tegen het gestolen-database type aanval (vector 3 verderop in je post). Als je client-side hashing aanbied is dat type aanval echter niet wat je wilt voorkomen. Client-side hashing (en salting) zorgt er enkel en alleen voor dat je plaintext password niet lekt naar een kwaadwillende server. Voor de duidelijkheid; Ik probeer niet te zeggen dat jij geen gelijk hebt, maar enkel te zeggen dat men niet slechter af is met client-side hashing (zolang het niet als vervanging dient!).

    Attack vector 2 snap ik niet. Als het goed is kan een aanvaller niet zomaar door mijn TLS heen kijken. Of gaan we hier uit van een scenario zonder TLS? Want dan heeft de hele discussie eigenlijk geen zin; de aanvaller kan dan altijd replay-achtige aanvallen uitvoeren.

    Attack vector 1 lijkt me dan ook het lastigste probleem. Aan deze vector kan je dan ook cross-site scripting aanvallen toevoegen, waar de aanvaller het script van de gebruiker aanpast (zoals het artikel dat ACM noemde beschrijft).

  29. @Rens wat men je probeert te vertellen is dat client side hashing extra aanvalsvectoren oplevert terwijl de voordelen (mij) niet echt evident zijn. Het vervangt server side hashes niet, “ervoor zorgen dat je plaintext wachtwword niet lekt naar een kwaadwillende server” lost het ook niet per se op en bovendien doen TLS/SSL dat véél beter, en hoe jij je “potentiële bewaarplicht” ermee kan”omzeilen” is me totaal niet duidelijk.

  30. @Richard: Wat ik dus juist betweer is dat het niet zo is dat client-side hashing extra vectoren met zich meebrengt. De hash is minstens zo veilig.

    Je opmerking over TLS/SSL heb ik al genoemd; maar, TLS/SSL is alleen tussen jou en de server. Als de server (dus waarschijnlijk een medewerker, bij tweakers in dit geval; no offense;) ) kwaadwillend is, dan zorgt client-side hashing dat hij niet het wachtwoord krijgt, maar enkel een hash. Hij kan dus niet automatisch andere accounts aanvallen of een (mogelijk) patroon in jou wachtwoord afleiden, omdat hij alleen de hash en de salt weet. Als men een password-generator zou gebruiken maakt dit niet uit, maar het overgrote deel van de mensen heeft hetzelfde of bijna hetzelfde wachtwoord (een patroon dus) voor de meeste websites. In het eerste geval beschermt het tegen directe aanvallen (password proberen bij het email adres), in het tweede tegen het uitvoerbaar maken van een brute-force-achtige aanval.

    Ik heb niets over een potentiële bewaarplicht gezegd; dat was Jeroen. Tegen een bewaarplicht kan je je niet echt beschermen als server, omdat je je toch aan de wet moet houden. Je zult dan ook je code moeten veranderen, mocht je client-side hashing gebruiken om te zorgen dat je de plaintext wachtwoorden niet hoeft op te slaan. Maar dat scenario is toch al onrealistisch.

  31. @Rens

    • Over de bewaarplicht: excuus, ik had ‘je’ in het algemeen moeten schrijven en niet ‘jij’ als in Rens. Desalniettemin blijft de vraag staan.

    • Client side hashing brengt extra vectoren met zich mee als gevolg van de zwakheden in het door ACM aangehaalde artikel over Javascript. Door de Javascript engine te manipuleren zou je het plaintext wachtwoord kunnen onderscheppen voordat het ge-encrypt wordt. (Indien je geen gebruik maakt van client side hashing zou het wachtwoord niet door Javascript worden geprocessed en wordt dit lastiger, i.e. er is een extra vector).

    • Je redenering over kwaadwillende servers begrijp ik niet. Allereerst beschermt TLS/SSL dat ik tegen de verkeerde server praat. Als de server klopt maar desalniettemin kwaadwillend is (bijvoorbeeld door een hack) dan kan deze evengoed een scriptbestand manipuleren en meesturen die client side het wachtwoord onderschept voordat het gehashed wordt. Zoals al in het artikel wat ACM aanhaalde wordt beschreven, zit hier een kip-en-ei probleem:

      What’s the “chicken-egg problem” with delivering Javascript cryptography?

    If you don’t trust the network to deliver a password, or, worse, don’t trust the server not to keep user secrets, you can’t trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.

    Kortom even kort door de bocht aanvalsvectoren tellen (binnen de besproken scope)

    A. geen TLS/SSL, geen client side hash: aanvalsvectoren ‘sniffing’, ‘kwaadwillende (maar juiste) server’, ‘verkeerde server’ B. wel TLS/SSL, geen client side hash: aanvalsvectoren ‘kwaadwillende (maar juiste) server’ C. geen TLS/SSL, wel client side hash: alle aanvalsvectoren in #A min sniffing plus Javascript engine problematiek/aanvalsvector D. wel TLS/SSL, wel client side hash: alle aanvalsvectoren in #B plus Javascript engine problematiek/aanvalsvector

    Scores zijn dus A:3, B:1, C:3, D:2. B wint.

  32. @Rens vd Heijden #35

    Attack vector 2 snap ik niet. Als het goed is kan een aanvaller niet zomaar door mijn TLS heen kijken.
    Klopt. Maar de DigiNotar hack maakt duidelijk dat ook een beveiligde verbinding niet veilig hoeft te zijn! Een “Man-In-The-Middle” aanval kan bovendien op diverse manieren worden opgezet zonder dat je er iets van merkt. In het ergste geval heeft de hacker via-via de private key van de server bemachtigd en is hij dus in staat om alles af te luisteren. In de DigiNotar-kwestie werd gewoon een vervalst certificaat gebruikt die niet als vals werd opgemerkt. Maar zelfs met een nepcertificaat dat wel als vals wordt herkent komt het gewoon voor dat gebruikers deze waarschuwingen negeren en dus gevoelige informatie doorspelen. Alle drie de aanvalsvectoren zijn relatief lastig maar desondanks niet onmogelijk. Zeker als je kijkt naar gebruikers binnen een bedrijfsnetwerk waarbij al het internet-verkeer over een proxy-server of gemeenschappelijke router gaat. Die proxy of router is dan een aanvalspunt voor AV2. De computer van je collega biedt je ruimte voor AV1 en als je toegang hebt tot de server-ruimte van je bedrijf heb je ook AV3 tot je beschikking. Een enkele kwaadwillende medewerker binnen een bedrijf is dan een enorm risico.

    Maar goed, ik kijk ook vaak naar beveiliging vanuit een commercieel oogpunt: hoe bescherm je een bedrijf. Dat komt omdat de informatie binnen bedrijven vaak meer waarde heeft dan de informatie over individuen. Bedrijven zijn ook eenvoudiger om aan te vallen omdat je gewoon op zoek gaat naar de zwakste medewerker. Beetje “social engineering” of gewoon een zak geld aanbieden en er is vast wel een medewerker die toegang biedt tot de jackpot.

    Een client-side hash die je verstuurt over een beveiligde verbinding en waarbij je op de server de dubbele hash uitvoert levert een systeem op dat veel moeite kost om te kraken. Het is niet onmogelijk maar er is altijd wel ergens anders een eenvoudigere prooi. Het is al wat ik in post 21 aangaf: je systeem hoeft niet het meest veilige te zijn. Je beveiligings-systeem moet alleen steviger zijn dan dat van je concurrenten.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.