Moet je van de wet wachtwoorden salten?

| AE 3057 | Security | 39 reacties

password-salt.jpgIk neem aan dat julie je LinkedIn-wachtwoorden ook hebben veranderd ondertussen? Wat een pijnlijke fout was dat zeg, lekken van hashes van 6,5 miljoen wachtwoorden van gebruikers. Vooral omdat die hashes niet “gesalt” waren, waardoor eenvoudig te raden was wat de werkelijke wachtwoorden waren. Maar, zo vroegen vele lezers me, is hashen dan niet wettelijk verplicht?

Het flauwe antwoord op die vraag is dat wat verplicht is vaak totaal losstaat van wat bedrijven doen. Maar een iets minder flauw antwoord is dat de wet eigenlijk helemaal niets specifiek voorschrijft omtrent beveiliging. Zo ongeveer de enige relevante wet hier is de Wet bescherming persoonsgegevens, en die bepaalt dat je “adequate” beveiliging moet hanteren voor persoonsgegevens. Een LinkedIn-profiel is een verzameling persoonsgegevens, dus daar geldt die eis zonder meer op.

Maar wat is nu adequaat? Dat staat niet in de wet. Er zijn allerlei aanbevelingen van allerlei partijen (zoals de paper van het Cbp zelf) maar die zijn formeel niet bindend. Je moet dus zelf bepalen wat adequaat is, gezien het soort gegevens en hoe kwetsbaar of aantrekkelijk die zijn. LinkedIn zou dus kunnen zeggen “ongesalte wachtwoordhashes zijn goed genoeg voor onze profielen”, maar dan ben ik héél benieuwd naar de onderbouwing daarvan.

Sterker nog, ik kan me bijna niet voorstellen dat daar een onderbouwing voor te bedenken is. Het is ondertussen algemeen bekend dat gehashte wachtwoorden eenvoudig te kraken zijn. Hoewel ze in theorie niet omkeerbaar zijn, is het ondertussen praktisch goed te doen om met brute force uit te proberen welke wachtwoorden tot welke hashes leiden. Zo goed zelfs dat ik wel durf te zeggen dat ongesalte wachtwoordhashes bewaren net zo veilig is als gewoon de wachtwoorden zelf opslaan. Bijna niet dus.

Wettelijk gezien is er dus geen harde eis en geen vast toetsingskader. Maar van concrete maatregelen is wel te zeggen of ze wel of niet verstandig zijn. Weten jullie nog meer veel gemaakte fouten omtrent beveiliging?

Arnoud<br/> Foto: Cardinal Path

Deel dit artikel

  1. “Maar we hebben adequate beveiliging rondom de database dus niemand krijgt toegang tot die database die dat niet moet hebben dus geen noodzaak tot salten.” 😉

    Het salten doe je volgens mij om aanval met rainbow tables te voorkomen. Door salt verhoog je de kosten maar nog steeds niet onmogelijk aangezien de salt ook ergens moet zijn omdat je anders zelf ook niets meer kunt doen.

  2. @ Peter van G Volgens mij doelt Arnoud op technische middelen, niet hoe die door mensen gebruikt worden.

    Over beveliging; salten van wachtwoorden is leuk en aardig. Maar vaak komen zulke lekken vanuit backups. Het is mijn eigen gebied (nog) niet. Maar ik kan me voorstellen dat backups zelf vaak nog niet geëncrypt zijn. Laat staan juist oude backups waarin wachtwoorden vaak nog minder goed beveiligd zijn.

    Hoe gaan jullie/anderen met (oude) backups om?

  3. Op zich is het feit dat de wet ‘adequate beveiliging’ vereist niet erg. Deze formulering heeft namelijk wel weer het voordeel dat nieuwe ontwikkelingen hier weer onder kunnen vallen en oude ontwikkelingen die ondertussen simpel te doorbreken zijn er niet meer onder vallen.

    Maar het zou inderdaad wel fijn zijn als er een bron was waar de minimum adequate beveiliging uitgestippeld zou worden. Dat voorkomt dat er een te lichte definitie van ‘adequaat’ door bedrijven gehanteerd wordt.

  4. Je zou dus een account-systeem kunnen bijhouden op de Raspberry Pi waarbij accountdata op in plaintext een SD-kaartje wordt bijgehouden en dit mini-computertje via een USB poort verbinden aan je web server waarbij de toegang tot de mini-computer zwaar beschermd is. Wie de web server weet te hacken heeft dus nog niet de data tot zijn beschikking. En indien de Pi een beperkte interface heeft waarmee je geen accountdata mee kunt opvragen dan komen ze ook niet bij de data, ondanks dat deze onbeschermd is opgeslagen. Wat telt is dat de data beveiligd is, niet hoe deze beveiligd is. Toch?

  5. Veel lelijker dan slordig hashen vind ik het niet juist gebruiken van SSL. Gewoon SSL aanzetten op de webserver is niet genoeg. En dat is vooral voor iedereen die openbare hotspots e.d. gebruikt: als je geen wachtwoord in hoeft te voeren om erop te komen, zoals KPN of T-Mobile hotspots, is data zonder SSL heel triviaal af te luisteren.

    Maar ik denk dat het allemaal wat academisch is. Zelfs als LinkedIn zonder enige twijfel gewoon technische blunders heeft gemaakt, en zelfs als het gewoon een Nederlands bedrijf zou zijn, zie ik niet gebeuren dat er daadwerkelijk boetes worden opgelegd, of iets dergelijks. Voor zover ik zie kan je in Nederland best ver gaan met dit soort zaken zonder serieuze risico’s voor juridische gevolgen.

  6. Je kunt je wel concentreren op het wel of niet gezouten zijn van de hash, maar dat is maar een klein deel van het beveiligingsprobleem. De eerste vraag die je je hoort te stellen is “Wat bescherm ik? (met deze login)” en bij LinkedIn is dat (voornamelijk) integriteit, dat de gegevens niet door onbevoegden gewijzigd kunnen worden. Daarbij moet de beveiliging adequaat zijn voor hetgeen beveiligd moet worden: Het gemiddelde fietsenschuurtje heeft geen alarminstallatie; een simpel slotje op de deur om de kwajongens buiten te houden is genoeg. Ik durf te stellen dat een correct geïmplementeerde login met een wachtwoord voldoende beveiliging biedt aan een sociaal netwerk.

    De eerste beveilingingsstap is wachtwoorden ontoegankelijk maken voor derden; deze stap heeft bij LinkedIn gefaald. (Wie weet waarom?) Als de wachtwoorden onversleuteld waren opgeslagen hadden ze zo op straat gelegen, maar het hashen (of anders versleutelen) vormt een extra beveiliging, tenminste voor de mensen die een niet-triviaal wachtwoord hebben. Het toevoegen van “zout” aan de hash maakt het vinden van het wachtwoord van een specifieke gebruiker niet moeilijker… het is wel meer werk bij het bulk-hacken van een wachtwoordenlijst.

    Eens met Erik Romijn@7: Een (verplicht) versleutelde verbinding is nodig voor goede wachtwoordbeveiliging; maar de vraag blijft of LinkedIn wel waardevol genoeg is om de kosten van SSL te verdedigen.

  7. @Alex, back-uppen? 🙂 Hey, ik geef alleen maar een alternatieve methode die ook best veilig kan zijn. Je zou op de Pi ook wat code kunnen toevoegen die het mogelijk maakt om de data over de USB-poort te back-uppen in een zwaar encrypted formaat met een two-pass certificaat die alleen op de Pi bekend is. Dus zowel public als private key zijn alleen op de Pi aanwezig. De webserver kan dan wel een backup opvragen van de Pi of een backup herstellen op de Pi, maar niet de inhoud uitlezen.

    Zolang de Pi maar nooit accountnamen en wachtwoorden terugstuurt naar de web server is het systeem best te beveiligen, zelfs met opslag als plaintext. Vooral als je de verbinding tussen webserver en Pi ook via PKI certificaten beschermd.

    Wat telt is dat de data beschermd is, niet hoe. Je kunt nog zoveel salten als je wilt maar als een hacker bij je database kan komen dan heeft hij het lastigste werk al gedaan…

  8. @MathFox: kosten van SSL? Op sslcertificaten.nl kost een SSL-certificaat 10 euro per jaar. Uiteraard kost het ook wat resources, maar dat is marginaal met de rekenkracht van tegenwoordig. Ook de maatregelen om SSL correct toe te passen (zoals secure cookies) zijn vrij eenvoudig.

    (Uiteraard zijn certificaten als EV duurder, maar dat voegt marginale beveiliging toe.)

  9. Ik heb de ophef over het hele LinkedIn verhaal een beetje gemist. De password-hashes lagen op straat. Maar wat ik begrepen heb (correct me if I’m wrong) waren er geen gebruikersnamen aan gekoppeld. Het waren gewoon 6,5 miljoen losse hashes (van de 161 miljoen accounts).

    (aluhoedje,

    • als ik 6,5 miljoen hashes genereer door een hele hoop dictionaries en nog wat password-generators door een SHA-1 algoritme te laten lopen,

    • ik zet dat bestand op internet,

    • ik claim dat dit de wachtwoorddatabase van website XYZ is (waarbij XYZ tussen de 10 en 200 miljoen gebruikers heeft),

    • mensen gaan checken en een aanzienlijk deel constateert ‘ja de hash van mijn wachtwoord zit er inderdaad bij’,

    is er dan inderdaad een hack gepleegd ?)

  10. (aluhoedje,– als ik 6,5 miljoen hashes genereer door een hele hoop dictionaries en nog wat password-generators door een SHA-1 algoritme te laten lopen,– ik zet dat bestand op internet, – ik claim dat dit de wachtwoorddatabase van website XYZ is (waarbij XYZ tussen de 10 en 200 miljoen gebruikers heeft),– mensen gaan checken en een aanzienlijk deel constateert ???ja de hash van mijn wachtwoord zit er inderdaad bij???,is er dan inderdaad een hack gepleegd ?)

    Als vervolgens die mensen gaan checken en zo vervolgens de bijpassende usernames zelf doorgeven?

  11. @Richard, bij LinkedIn log je in met je email adres en wachtwoord. En email adressen zijn massaal te vinden op het Internet en diverse spammers verhandelen lijsten met miljoenen adressen erin. Wat je vervolgens uit die lijst van hashes nodig hebt zijn de 10 populairste wachtwoorden. Wat je vervolgens doet is proberen (automatisch) in te loggen met die miljoenen email adressen in combinatie met de 10 populairste wachtwoorden. Krijg je per adres maar 10 pogingen maar de kans dat je tussen die miljoenen adressen iemand vindt die een van die wachtwoorden gebruikt is vrij reeel…

    Overigens hoef je die gegevens niet te gebruiken om bij LinkedIn in te loggen. Veel mensen gebruiken hun wachtwoord voor meer dan LinkedIn dus als je iemand kunt terugvinden uit die miljoenen adressen met 1 van de 10 wachtwoorden dan kun je kijken welke andere sites je met dit adres en wachtwoord kunt benaderen. Facebook, Google Plus, Twitter, noem maar op…

    Sowieso is dit een bekende aanvals-vector, waarbij men maar weinig verschillende wachtwoorden gebruikt, in combinatie met heel veel gebruiker-accounts uitprobeert. Per gebruiker krijg je dan misschien 3 inlogpogingen (wat mogelijk niet opvalt) maar in totaal miljoenen pogingen tot bepaalde accounts gevonden worden, wat alleen op de webserver zelf kan opvallen.

    Deze hashlijst geeft hackers extra informatie over wat populaire wachtwoorden zijn, zodat ze dergelijke aanvallen beter kunnen inzetten.

  12. Overigens ben ik het ten dele wel eens met wat eerder geopperd werd. Hoe belangrijk is de beveiliging van LinkedIn?

    De informatie die je op LinkedIn zet is al openbaar. Als de informatie gewijzigd wordt merk je dat als je het bekijkt, als je wachtwoord gewijzigd wordt merk je dat nog sneller en neem je actie.

    Het is alleen een probleem als je zo onvoorzichtig bent geweest om de e-mail/wachtwoord combinatie op meer dan 1 plek te gebruiken. En dan ook nog bij kritische zaken. Ik gebruik vergelijkbare wachtwoorden met een site specific deel. Maar de echt kritische wachtwoorden zijn compleet verschillend en hebben waar mogelijk geen werkende recovery optie! Als ik de wachtwoorden vergeet liggen ze thuis op een USB stick in mijn kluis. Alleen het wachtwoord van die stick moet ik nooit vergeten.

  13. @Fred, ik dacht eerder aan putopties LinkedIn kopen en deze hoax bekend maken. De winst en de kans dat ik als dader word achterhaald zijn vele malen kleiner dan wanneer ik zelf aan het hacken sla.

    @Wim, deze aanval had ik ook bedacht maar ik zie eerlijk gezegd nauwelijks de meerwaarde van die lijst in dat geval. 161 miljoen maal 6,5 miljoen is simpelweg te groot. Als je nou 20 wachtwoorden van een pool van 100 users hebt, dan wordt zo’n lijst een meerwaarde. Maar nu niet.

    Of je hebt een eenvoudig wachtwoord en je liep toch al kans om gehacked te worden. Of je had een moeilijk wachtwoord (wel in de lijst maar zeer laag op de populariteits-ranglijst) en de kans dat jij gehacked wordt is nog steeds miniem.

  14. @Richard, stel dat de 20 populairste wachtwoorden door zo’n 10% van de totale LinkedIn gebruikers wordt gebruikt, dan kunnen ze zo 16 miljoen accounts vinden, indien ze alles uitproberen met 20 wachtwoorden. Dat zijn dus 3.32 miljard pogingen. Inderdaad best veel maar als je een botnet hebt over 10.000 computers dan zijn het nog maar ruim 300.000 pogingen per gehackte computer. Dat wordt nog veel minder indien je minder wachtwoorden gebruikt of een groter botnet hebt.

  15. @Wim, snap ik, maar a) in hoeverre zou die lijst afwijken van een standaard lijst met populaire wachtwoorden b) volgens mij is de gelekte lijst ontdubbeld en aangezien er niet gesalt is mappen dezelfde wachtwoorden op dezelfde hash en kan je niet eens weten welke wachtwoorden wel en niet populair zijn c) 300.000 pogingen per botcomputer is echt wel te detecteren en te blocken…

  16. @Richard, het gaat er niet om dat je veel wachtwoorden hebt, maar de meest populaire wachtwoorden. Met 5 wachtwoorden kom je al een behoorlijk eind als je 50 miljoen adressen kunt uittesten. En ja, diverse bekende wachtwoorden zijn al heel lang bekend dus die kunnen ze overslaan. Wat ik heb begrepen is dat de top-10 van de LinkedIn lijst begint met link, 1234, work, god, job, 12345, angel, the, ilove en sex. Forbes heeft een mooi overzicht maar de woorden die ik net noemde zijn bij elkaar 2.839 keer aanwezig in de lijst, van de 165.000 wachtwoorden die al ontcijferd zijn… Dus 1.77% van dit aantal. Laat deze lijst los op een lijst van 1 miljoen (potentiele) LinkedIn accounts en je hebt 10.000 accounts gehacked. Als je een dergelijke aanval probeert met miljoenen email adressen met 1 wachtwoord uit die lijst, dan hack je meer accounts met “link” dan met “angel”.

    En ja, 300.000 pogingen zullen wel opvallen, maar eigenlijk alleen bij de server, niet bij de gebruikers. Per gebruiker zijn er misschien maar 3 pogingen geweest.Wat je dan krijgt zijn 100.000 verschillende accounts die proberen in te loggen vanaf 1 IP adres. Maar LinkedIn en hun 160+ miljoen leden leveren sowieso veel logins op wat het uitfilteren van zoveel inlog-pogingen vanaf 1 computer doet verdwijnen in het totaal aantal logins. Je zult je systeem dusdanig moeten bouwen die dit automatisch detecteert en om eerlijk te zijn, LinkedIn nam niet eens de moeite om de wachtwoorden te salten… Denk je dat ze bij LinkedIn zoveel login pogingen zullen opmerken?

    Mocht het hen wel opvallen dan worden hooguit wat IP adressen geblokkeerd en misschien gaat een deel van het botnet onderuit maar wat het kan opleveren is best wat waard. Sowieso kunnen de gehackte accounts gebruikt worden om persoonlijke informatie mee te verzamelen voor identiteits-diefstal. Kun je vervolgens weer misbruiken bij nep-sollicitaties en het toevoegen van goed uitziende referenties, aanmaken van bankrekeningen op naam van de LinkedIn gebruikers op basis van de prive-data in de account en mogelijk nog veel meer…

  17. Hoe sterk het crypteringsalgorithme ook is en hoeveel zout je over de hashes ook strooit, het helpt allemaal niet zolang vele gebruikers hun passwords volgens voorspelbare patronen kiezen. Zie de lessen uit de eerste twee miljoen gekraakte LinkedIn passwords. Strakke eisen aan hashes en zout in passwords is als van een aannemer eisen dat die minste 2 cm pantserstaal in de voordeuren monteert waarna een kwart van de bewoners in de straat er een plastic hangslotje van 5 cent uit de speelgoedwinkel in hangt.

  18. @Wim, ik snap wel wat je zegt (ik krijg de indruk dat je jezelf herhaalt) maar mijn punt is (op het gevaar af dat ik mezelf ook herhaal) dat voor heel die aanval die jij beschrijft, de feitelijke gelekte lijst behoorlijk irrelevant is.

    NB na wat gegoogle blijkt dat de passwordlijst blijkbaar alleen bedoeld is als ‘bewijs’ dat een bepaalde hacker zou beschikken over de gebruikersnamen EN wachtwoorden, dus onze hele discussie is zinloos 🙂

  19. @Richard, de lijst zelf is minder interessant dan de statistieke gegevens die je eruit kunt halen. De methode die ik omschrijf werkt met veel accountnamen en maar een paar wachtwoorden en valt daarom ook niet snel op. Maar om succes te hebben moet je wel zo populair mogelijke wachtwoorden kiezen. Het is dus alleen maar relevant voor hackers die hun kansen willen vergroten. Als die kans met een half procent omhoog gaat is dat al een behoorlijke winst voor hen…

    En ach, die lijst is handig want bedrijven moeten gewoon al deze wachtwoorden opnemen in een blacklist. Dan kunnen bezoekers dus niet meer een van deze wachtwoorden kiezen. 🙂

  20. Arnoud, Ik vind dat je wel erg ver gaat door te beweren dat “unsalted” (ongezouten?) hashes opslaan net zo onveilig is als opslaan van plain text wachtwoorden.

    Salting wordt gebruikt als bescherming tegen rainbow tables (gigantische vooraf berekende tabellen van wachtwoord+hash combinaties). Maar een goed wachtwoord biedt zelf ook al een aardige bescherming tegen rainbow tables: als je alle letters in je wachtwoord willekeurig kiest, dan neemt de omvang van de nodige rainbow table exponentieel toe met het aantal letters in je wachtwoord. Dus met een goed, voldoende lang wachtwoord ben je al aardig beschermd.

    Ik weet niet precies wat de state-of-the-art is voor hackers, maar ik dacht dat je met 16 willekeurig gekozen letters (groot, klein, cijfers, leestekens) wel zo’n beetje uit de gevarenzone bent. Als je bestaande woorden opneemt in je wachtwoord zul je het langer moeten maken.

    Ik heb helaas de hash van mijn (inmiddels veranderde) LinkedIn-wachtwoord niet kunnen vinden in de gepubliceerde lijst. Jammer: ik had wel eens willen weten of mijn wachtwoorden kraakbaar zijn.

    Het blijft natuurlijk een schande voor LinkedIn dat ze geen salting hebben toegepast: het is een algemeen bekende en algemeen toegepaste beveiligingstechniek, en er is eigenlijk geen reden om het niet toe te passen. Daarnaast is het bij zo’n grote groep gebruikers ondenkbaar dat er geen gebruikers zijn die alle fouten tegelijkertijd maken, zoals een te makkelijk wachtwoord gebruiken en het zelfde wachtwoord ook voor andere belangrijke services gebruiken.

  21. @Corné, je maakt de fout door aan te nemen dat gebruikers wel goede wachtwoorden zullen kiezen. De realiteit is, zoals ook deze hack aantoont, dat veel gebruikers veel te eenvoudige wachtwoorden kiezen. En ja, je kunt ze dwingen om hoofdletters, kleine letters, nummers en speciale tekens te gebruiken en dat wachtwoorden 10 tekens lang moeten zijn. Dan krijg je 10.000 keer ABCdef123! als wachtwoord…

  22. @Wim #25: ik maak die aanname niet. Ik zeg alleen dat hashen zonder salten altijd nog iets beter is dan helemaal niet hashen. De mensen die wel een goed wachtwoord hebben zijn dan nog tenminste een beetje veilig; de mensen met slechte wachtwoorden natuurlijk niet.

    Een ander punt: vinden jullie het ook vreemd dat maar een deel van de LinkedIn-wachtwoorden gelekt is? Je zou toch zeggen dat alle wachtwoorden op 1 plek zijn opgeslagen, en dat de hacker ofwel alle, ofwel geen wachtwoorden heeft bemachtigd. Ik vind dit toch meer lijken op iemand die alleen maar beweert LinkedIn gehackt te hebben.

  23. @26 wat ik inmiddels begrepen heb is dat de hacker claimt dat ie ALLE wachtwoorden EN bijbehorende gebruikersnamen heeft, en deze lijst enkel heeft gelekt om zijn punt te bewijzen. Zoals ik in #13 heb betoogd is de publicatie van een lijst waarvan mensen DENKEN dat die van LinkedIn is echter vrij triviaal en bewijst de lijst mijns inziens dus niets.

  24. Arnoud: De meeste gemaakte beveiligingsfout die ik tegen kom bij webpagina’s is het niet-sanitizen van parameters die gebruikers in mogen voeren, in een SQL query. Met stip op één bij mij.

    De stelling dat hashes zonder salt net zo veilig zijn als plain text gaat alleen maar op als de hashmethode één van de veelgebruikte methodes is. MD5, SHA1.

    Laat ik een andere interessante stelling doen: Die veiligheid die een salt toevoegt aan een tabel van wachtwoordhashes is te verwaarlozen als er niet actief wordt opgetreden tegen hele zwakke, veel-voorkomende wachtwoorden. Ik wil wel uitleggen waarom deze stelling klopt, en hoe het kraken van salt/hashmethode werkt, maar de methode zie ik vrijwel nooit ergens besproken. Ik wil geen slapende honden wakker maken.

    Laat ik verder nog even opmerken dat een salt gewoon uit de broncode te halen is, mocht een hacker daar toegang tot krijgen. In dat geval hoeft ie geen moeite te doen.

  25. @Mischa: Een wachtwoordhash is een drempel voor insider-attacks. (Een systeembeheerder die een backup in handen krijgt kan niet zomaar een gebruiker kiezen waarvoor hij wil inloggen.) ??n het is een extra drempel voor degenen die de wachtwoordlijst in handen krijgen.

    De goede manier van zouten is om iedere gebruiker een eigen zout-waarde te geven, zodat hetzelfde wachtwoord tot verschillende hashes leidt. (bijv. MD5 de gebruikersnaam, plaats deze hash voor het wachtwoord en SHA het resultaat.)

  26. bijv. MD5 de gebruikersnaam, plaats deze hash voor het wachtwoord en SHA het resultaat.
    Ja, dat maakt het wel wat lastiger maar aangezien de hacker eventueel ook accountnamen kent, weet hij dus ook waarmee het wachtwoord is gesalt. Deze salt is vrij eenvoudig te raden. Een betere methode is door eerst een hash te berekenen over de gebruikersnaam, waarbij je een vaste tekst als salt gebruikt. Deze hash gebruik je vervolgens weer om het wachtwoord mee te salten.

    Toch werkt het gebruik van alleen de gebruikersnaam als salt wel goed genoeg om een complete lijst mee te beschermen. Zonder salt zal iedere gebruiker die “ABC123” als wachtwoord gebruikt dezelfde hash-waarde hebben. Weet je eenmaal van 1 gebruiker het wachtwoord dan kun je in de lijst kijken naar wie dezelfde hash heeft. Dit gebeurt ook indien je voor alle gebruikers dezelfde salt gebruikt. Het ontcijferen is lastiger maar de hacker zal de hash op meerdere plekken kunnen terugvinden. Als wachtwoorden zijn gesalt met de gebruikersnaam dan zal de hacker vrijwel geen dubbele hash-waardes tegenkomen, wat hem duidelijk maakt dat de wachtwoorden met een variabele salt zijn gehashed. Dan moet iedere account apart ontcijferd worden en kun je geen gebruikers herkennen die hetzelfde wachtwoord gebruiken. Maar omdat hashes dan vrijwel uniek zijn kan de hacker gaan gokken of de salt toevallig de gebruikersnaam is. Vandaar ook dat je het nog net iets lastiger moet maken…

    Wat wel het nadeel is van veel hashen is dat goede hashing-algoritmes van nature erg traag zijn. Ik hoor wel eens vragen om snellere hash-methodes maar dat is juist niet wat je moet hebben! Een snelle methode kan namelijk ook sneller gebruikt worden bij een brute-force aanval. Een goed hash-algoritme is dusdanig gebouwd dat er veel rekenwerk nodig is om de hash te produceren. Hoe trager, hoe beter een hash-algoritme is. Let wel op: ik heb het over de snelheid van het algoritme, niet de snelheid van de code die het algoritme uitvoert! Trage code helpt niet indien de hacker een snelle variant van het algoritme heeft.

  27. Wat hier vergeten wordt is dat hashfuncties vaak eerst gekraakt worden voor collisions. Dat wil zeggen, dat je een andere waarde vindt die dezelfde uitkomst genereert. Een salt-waarde maakt zo’n hashfunctie dan vaak toch nog bruikbaar voor wachtwoordtoepassingen, want de collision die dan gevonden wordt, zal niet geaccepteerd worden, doordat de salt-waarde hier nog weer voor gezet wordt. Maar weinig hashfuncties zijn daadwerkelijk omkeerbaar gemaakt, dus dit is zeer belangrijk!

    Ook maakt het bruteforce en dictionary aanvallen wel moeilijker, maar niet supermoeilijk, omdat de salt-waarde geld als publieke informatie bij de hash. Dat wil zeggen, als iemand de hashes heeft, heeft deze ook de salt-waarden, en kan dus gewoon hier rekening mee houden in zijn aanvallen. Wel wordt het gebruik van regenboogtabellen ontmoedigt.

  28. In de privacy policy van veel websites staat: Uw gegevens worden opgeslagen volgens industrie-standaard methoden.

    Als men dan mijn wachtwoord opslaat in unsalted SHA1 of MD5 dan is mijn inziens niet voldaan aan de privacy policy.

    Het begrip “industrie-standaard” is natuurlijk lekker vaag en ruim te interpreteren, maar de standaard in security is absoluut hoger dan unsalted SHA1. Standaard in de industrie is op moment gebruik maken van een hashing scheme als Bcrypt of PBKDF2. Zie bijvoorbeeld deze RFC: http://tools.ietf.org/html/rfc2898

    Mensen uit de security industrie vinden unsalted SHA1 of MD5 inderdaad net zo makkelijk en snel te kraken als plaintext wachtwoorden. Er is in de industrie dus absoluut geen sprake van een lakse standaard als in gebruik bij Linkedin.

    Ik gun deze class action lawsuit dan ook veel succes:

    She claims that LinkedIn failed to adequately protect users with ???basic industry standard encryption methods.??? By this, the plaintiff means LinkedIn should have been salting its password hashes. These claims are made in light of LinkedIn???s privacy policy, which states that ???All information that you provide will be protected with industry standard protocols and technology.???

    http://www.webpronews.com/linkedin-class-action-complaint-over-password-leak-2012-06

  29. Veelgemaakte overige fouten:

    • Backups met gegevens worden ergens openbaar opgeslagen, of ladekasten blijven achter bij een verhuizing

    • Password requirements zijn gebrekkig (minder dan 5 characters mogelijk, meer dan 12 characters onmogelijk)

    • Social Engineering kennis ontbreekt: “Journalist: Hoi ik ben z’n doctor, kun je de medische gegevens opsturen? Assistent: Tuurlijk meneer!”

    • (Server) Software wordt niet geupdate tegen bekende exploits.

    • Men vergeet het dichten van gangbare attack vectors als: SQL Injectie, XSS, CSRF

    • Er ontbreekt een escalatie plan: Hoe snel kunnen we onze bezoekers op de hoogte brengen? Hoe kan de hacker met ons in contact komen?

    Ikzelf denk dat we naar een officiele industriestandaard toemoeten als het gaat om het beschermen van persoonsgegevens. Compleet met inspecties/audits en certificatie. Dit zal een aardige duit kosten, maar economische spionage is nu een feit. Ook mafia bendes in Rusland die de persoonsgegevens gebruiken voor identiteitsfraude.

    Zoiets als NEN-ISO/IEC 27001:2005 ( http://nl.wikipedia.org/wiki/ISO/IEC_27001 ) zou uitkomst kunnen bieden. Nu is het reeds voor overheidsinstellingen verplicht. Laat bedrijven dit volgen.

  30. En misschien wel de meest gemaakte fout, ook van toepassing op de Linkedin leak:

    • Geen cryptograaf zijn en toch je eigen cryptografie toepassing ontwerpen.

    Bcrypt en PBKDF2 worden al langer dan 10 jaar gebruikt en staan bekend als vertrouwelijk. Een leger aan cryptografen heeft er geen zwakheden in kunnen ontdekken. Bindings of de algo’s zelf zijn voor vrijwel elke programmeertaal aanwezig. Zelfs WordPress maakt gebruik van phpass.

    Je kunt dan wel zeggen, ik maak mijn eigen sha256(“KEY” + “SALT” + “PASSWORD” + “ITERATIONS”), maar of dat veilig is voor een John the Ripper ( http://www.openwall.com/john/ ) weet je vast niet. Of je het moeilijker of makkelijker te kraken hebt gemaakt weet je al helemaal niet.

    Bij veel developers heerst de gedachte: Ik wil het zelf maken. Maar daar doe je je klanten dan geen plezier mee. Een klein beetje encryptie of hashing kennis is vaak schadelijker dan helemaal geen encyptie kennis en het vertrouwen op een bestaande en geteste library als Bcrypt.

    Dit heeft Linkedin denk ik de das om gedaan: Genoeg weten dat je paswords moet hashen en de sha-1 functie kan gebruiken, om het dan maar zelf te doen, en hard te falen.

    Een beetje als een automonteur die genoeg van motors weet om er zelf een te ontwerpen en te plaatsen, maar die dan ontploft na een paar KM rijden, omdat er geheel geen olietoevoer is gebruikt. Ook zo’n mislukte hobby auto gebruiken om miljoenen mensen mee te vervoeren dient in mijn optiek strafbaar te zijn. Toon maar aan dat je rijwaardig bent. Toon maar aan dat je het waardig bent om persoonsgegevens op te slaan.

  31. PHP developer voor zo’n 10 jaar, bij mij is het (waar mogelijk) altijd zo in elkaar gezet: Het wachtwoord wordt nooit in herleidbare vorm opgeslagen, dus ook niet encrypted (wat namelijk te decrypten valt met de gebruikte key) ik gebruik dus nog altijd de hash functie. Om te zorgen dat dit niet (efficient) dmv rainbow tables kan worden gebroken doe ik het volgende:

    Wanneer een bezoeker zich aanmeld neem ik aan de hand van de microtime functie een MD5 hash, dit wordt de unieke salt voor deze gebruiker.

    Hiernaast heb ik een ‘website wide’ salt die op meerdere plaatsen wordt gebruikt, deze staat alleen in de code van de site.

    Het wachtwoord van de gebruiker wordt vervolgens als md5 ( {wachtwoord}{usersalt}{sitesalt} ) opgeslagen.

    Een hacker zal daardoor niet alleen de database, maar ook een kopie van de code in handen moeten krijgen (of op zijn minst het bestand waar de site_salt in staat).

    Ik zou graag willen dat er ook wat minder webshops waren waarbij ik niet mijn eigen wachtwoord toegemaild krijg wanneer ik de “Wachtwoord vergeten” optie gebruik 🙁

    • Je gebruikt MD5, een algoritme dat sinds 1991 in gebruik is en waarvan in 1996 een ernstige zwakheid in is ontdekt. SHA-1 is een tijdlang als betere oplossing gezien tot bleek dat ook SHA-1 zwakheden has. Maar MD5 wordt tegenwoordig afgewezen als “onveilig”. En dat hoort allang bekend te zijn bij iedereen.

      Je kunt SHA-3 overwegen, wat een vrij nieuw algoritme is. Ook deze zal uiteindelijk gekraakt kunnen worden maar is in ieder geval vele malen sterker dan MD5.

      Overigens willen veel ontwikkelaars graag snelle hash-methodes gebruiken, wat prima is als je checksums wilt berekenen over bestanden. Maar voor echte beveiliging moet je juist trage algoritmes gebruiken om zo in ieder geval de brute-force methode flink te ontmoedigen. Je gebruiker kan wel een halve seconde wachten maar iemand die brute force probeert is dan uren bezig voor een honderdtal pogingen…

      Natuurlijk is het ook maar de vraag hoe sterk de beveiliging uiteindelijk moet zijn. Daarvoor moet je weer kijken naar de aard van de gegevens die je bewaart. Hoe meer privacy-gevoelige gegevens je gebruikt, des te beter moet de beveiliging zijn. Als jij in je software bank-gegevens bewaart van klanten dan zou ik MD5 direct afkeuren. Maar als het alleen een chat-dienst is, is MD5 wel voldoende, op dit moment…

      En ja, je salt maakt het lastiger maar besef wel dat als een hacker de database weet te bemachtigen, dan heeft hij ook al je site weten te bemachtigen! Je site in handen krijgen is zelfs eenvoudiger dan je database.

      Betreffende webshops die je wachtwoord naar jou toe mailen… Dat betekent nog niet dat ze je wachtwoord ook opslaan. Bij inschrijven moet je een wachtwoord invoeren en die kan dan zo in de email worden geplaatst terwijl alleen een hash wordt opgeslagen in de database. Bij inschrijven krijg je dan nog een keer je wachtwoord per email terug, wat je kunt archiveren. Maar later zul je je wachtwoord niet meer op kunnen vragen.

      • besef wel dat als een hacker de database weet te bemachtigen, dan heeft hij ook al je site weten te bemachtigen! Je site in handen krijgen is zelfs eenvoudiger dan je database.

        Nee. Een database kan je binnendringen met SQL injectie, dat is vaak makkelijker als bestanden lezen.

        Betreffende webshops die je wachtwoord naar jou toe mailen… Dat betekent nog niet dat ze je wachtwoord ook opslaan. Bij inschrijven moet je een wachtwoord invoeren en die kan dan zo in de email worden geplaatst terwijl alleen een hash wordt opgeslagen in de database. Bij inschrijven krijg je dan nog een keer je wachtwoord per email terug, wat je kunt archiveren. Maar later zul je je wachtwoord niet meer op kunnen vragen.

        Er stond Ik zou graag willen dat er ook wat minder webshops waren waarbij ik niet mijn eigen wachtwoord toegemaild krijg wanneer ik de “Wachtwoord vergeten” optie gebruik

        NB ik drukte per ongeluk op nuttige reactie. Dat kan ik blijkbaar niet meer ongedaan maken? Niet dat ik je reactie niet nuttig vond, maar ook weer niet zo nuttig om die knop te gebruiken.

        • Een database kan je binnendringen met SQL injectie, dat is vaak makkelijker als bestanden lezen.
          De meest recente SQLI aanvallen waren in 2013 op een Turkse website en een Chinese website en iets ouder is de aanval op Yahoo in 2012! In alle gevallen ging het om slecht ontwikkelde sites of zwaar verouderde sites. Yahoo heeft sowieso een slechte naam op het gebied van beveiliging, waardoor ik geen hoge pet op heb betreffende Yahoo.

          SQLI zal nog kunnen voorkomen bij sites die verouderde software gebruiken of door ontwikkelaars die hun kennis niet uptodate houden en dus nog verouderde technieken toepassen. SQLI mag eigenlijk niet voorkomen en dat Yahoo nog redelijk recent hiervoor gevoelig was geeft al aan hoe onveilig de sites van Yahoo kunnen zijn. De meeste andere, grote sites zijn hier allang niet meer gevoelig voor.

          Bij het hacken van computers moet je proberen om code op die computer uitgevoerd te krijgen. Dat kan een SQL commando zijn maar als je de database structuur niet kent dan is dat nog een flinke klus. Maar als je een SQL commando kunt laten uitvoeren dan kan je mogelijk ook via die SQL engine richting het bestandssysteem gaan. Bij SQL-Server kun je ‘xp_cmdshell’ gebruiken en andere database systemen hebben mogelijk vergelijkbare functies. Via deze command-shell ga je eerst zoeken naar de folders met daarin de bestanden van de site zelf. Vervolgens ga je deze downloaden zodat je daarin kunt zoeken naar de diverse tabelnamen en veldnamen. Met die tabel/veldnamen kun je vervolgens weer de gevoelige informatie opvragen. Best nog goed te doen. Maar ja, je gaat dan wel eerst de site ophalen! 🙂 Handiger is het om via SQLI een extra PHP bestand op de server te plaatsen. Dit zou dan een filebrowser moeten zijn waarmee je door het gehele systeem kunt bladeren. Als je deze op de server weet te bemachtigen dan kun je alle bestanden op het systeem benaderen. Ik weet dat dit mogelijk is omdat ik deze truuk zelf heb toegepast op een server die diverse websites ging hosten. Dit om even aan te tonen hoe onveilig het delen van 1 server voor meerdere websites kan zijn. Samen met de administrator hebben we een extra site aangemaakt met daarin een filebrowser-pagina, die alle bestanden op deze server kon inkijken. (Zonder extra systeemrechten!) En inderdaad, de browser begon met de folder van de browser-site zelf en van daaruit kon je omhoog richting de root, richting de overige sites, richting de programma’s en zelfs richting de user-folders.

          Als een hacker een dergelijke filebrowser geinstalleerd weet te krijgen op welke manier dan ook, dan hebben ze volledig (lees) toegang tot al je bestanden.

          Om de database uit te lezen moet je wel de datastructuur kennen. En om die structuur op te vragen moet de site wel een account gebruiken die rechten heeft om de structuur op te vragen. Een beetje beheerder zorgt ervoor dat de site alleen data kan lezen en schrijven en verder niets. Daarom dat je dan eerst probeert de site in handen te krijgen zodat je meer leert over de database. (Maar als een site een standaard-software site gebruikt zoals phpBB of WordPress dan is de database structuur natuurlijk wel bekend.)

          NB ik drukte per ongeluk op nuttige reactie.
          Zal jouw reactie ook per ongeluk als nuttig bestempelen. Oeps! 🙂

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS