Mag een werkgever wachtwoorden kraken?

password-salt.jpgEen lezer vroeg me:

Onze IT-afdeling heeft besloten dat security een extra aandachtspunt wordt en als onderdeel daarvan wil men middels rainbow tables en andere tools alle wachtwoorden uit het bedrijf eens gaan controleren. Ik heb daar moeite mee: ik gebruik sterke wachtwoorden maar bouw die wel op volgens een bepaald patroon, en als dat straks in interne documenten gaat rondzwerven dan schaadt dat juist de security. Mag de werkgever dit wel doen? Er zijn toch betere manieren om de beveiliging te versterken, zoals tweefactorauthenticatie.

Juridisch gezien denk ik dat hier weinig tegen te doen is. De werkgever bepaalt hoe het werk wordt uitgevoerd, dat is haast de definitie van werkgeverschap. Als hij vindt dat je wachtwoord zestien tekens lang moet zijn met maximaal acht letters, dan heb je maar zo’n wachtwoord te verzinnen. Wil hij geen tweefactorauthenticatie, dan zul je je daar als werknemer bij neer moeten leggen.

Het kraken van wachtwoorden om te kijken hoe sterk ze zijn, doet wat gek aan. Ik snap het wel: veel mensen hebben zwakke wachtwoorden, en met zo’n test kun je kijken hoe slecht je ervoor staat, om vervolgens draagvlak te creëren voor sterkere wachtwoorden of regels. Maar het kan vervelend zijn voor mensen die al een eigen, sterk wachtwoord hebben en zich nu verplicht zien een heel ander soort wachtwoord erop na te houden.

Ik weet alleen echt niet hoe je daar iets tegen kunt doen als werknemer. Dit is geen wijziging van je arbeidscontract of een schending van je grondrechten, en apert onredelijk kan ik deze actie ook niet noemen. Dat een andere oplossing sterker is (tweefactorauthenticatie) zie ik meteen, maar dat is echt de keuze van de werkgever. Ik zou dus niets anders weten dan het overleg aangaan en hopen dat de IT-afdeling inziet dat dat een betere besteding van het budget is.

Arnoud

28 reacties

  1. Ik vind het helemaal geen gek idee: ik vind het juist een heel goed idee dat dit bedrijf dat doet. Bedrijven, software-pakketten, websites en dergelijke zouden dit veel vaker moeten doen.

    Als je je wachtwoorden “volgens een bepaald patroon” opbouwt, dan moet je heel erg oppassen dat dat patroon je wachtwoord niet voorspelbaar maakt. Als jouw wachtwoord wordt “gekraakt” door de tools van je werkgever, dan kunnen hackers dat waarschijnlijk ook, en dan is het per definitie een onveilig wachtwoord.

    Blijft natuurlijk de vraag hoe de werkgever zou moeten reageren als ze een onveilig wachtwoord ontdekken. Het verspreiden van het onveilige wachtwoord lijkt me niet zinvol, en kan juist extra schade veroorzaken. Het lijkt me beter als ze gewoon zeggen “uw wachtwoord is niet veilig. U moet nu een nieuw wachtwoord aanmaken. Hier zijn wat tips voor het maken van een veilig wachtwoord.”

  2. Op welke manier zou iemand met een sterk wachtwoord hier last van hebben? Als een wachtwoord gekraakt kan worden door een rainbowtable dan is het niet zo sterk als de gebruiker denkt. Het enige wat een gebruiker hier van zou merken is een bericht van de IT-afdeling dat zijn wachtwoord wel/niet sterk genoeg is en in het laatste geval dat hij het moet veranderen.

    Twee-factor authenticatie is lastig, duur en behoorlijk impopulair bij gebruikers. Als je het via een gsm/smartphone regelt krijg je te maken met mensen die zo’n din niet willen hebben, en als de accu leeg is kunnen ze niet werken. Tokens en dergelijke worden door anderen gezien als een lastig extra voorwerp dat ze bij zich moeten dragen.

    1. Two-factor auth duur en maar lastig? Dat kan zo zijn. Maar security is ook belangrijk. Het hangt natuurlijk af van wat je bedrijf doet. En een IT bedrijf kan het natuurlijk makkelijker zelf regelen dan een schoonmaakbedrijf.

    2. Als ik moet kiezen tussen een extra sleutel aan mijn sleutelbos en een wachtwoord wat minstens 32 tekens moet zijn, 2 hoofdletters, 4 cijfers en 8 leestekens moet bevatten, en wat ik elke maand moet veranderen, dan weet ik het ook wel.

      Die regels afdwingen wordt namelijk met de weg van de minste weerstand gedaan. Iets als “W8Woord!123!@#$%^&” is toch iets makkelijker te onthouden dan “E48XqyfjqW461#$#$&!(*&”.

  3. Het lijkt mij dat je hashes kunt proberen te matchen met een rainbow table. Maar er is geen enkele reden voor om te kijken wat dan het oorspronkelijke wachtwoord zou zijn.

    Een patroon is natuurlijk gevaarlijk. Maar vaak heb je daar mee te maken omdat je elke X tijd je wachtwoord moet vervangen. En dat is blijkbaar een slecht idee https://www.security.nl/posting/463989/Professor%3A+regelmatig+wachtwoord+wijzigen+onverstandig

    Als je verschillende wachtwoorden vanwege een veel-fout van systemen nodig hebt. Dan is er binnen het bedrijf wel een verbetering door te voeren.

      1. Ik vermoed sterk dat de vragensteller niet snapt wat voor test hier uitgevoerd wordt. Rainbow tables gebruiken lijkt me sterk, want dan is inderdaad het systeem reeds lek.

        Wat men waarschijnlijk gaat doen is de hashes in de database vergelijken met de hashes van een lijst standaard wachtwoorden.

        en als dat straks in interne documenten gaat rondzwerven dan schaadt dat juist de security.

        Mmmh, ja dit bevestigd mijn vermoeden. Of: De IT-afdeling snapt niets van security, of de werknemer denkt security beter te snappen dan de IT-afdeling. Geen IT-afdeling kraakt eerst een wachtwoord en zet dit dan in interne documenten, zonder dat wachtwoord (te laten) veranderen.

  4. Wat is het exacte doel? Aantonen dat mensen slechte makkelijke wachtwoorden gebruiken? en dan?

    Is het niet gewoon veel makkelijker eisen te stellen aan het wachtwoord en mensen verplichten dit periodiek aan te passen? Dan heb je toch net zo goed je doel bereikt? Je hoeft helemaal niet te weten welke wachtwoorden er in omloop zijn om strenge eisen te stellen, gewoon invoeren en binnen de vastgestelde periode heeft iedereen een veilig wachtwoord (inclusief de post-it memo’s op de monitoren natuurlijk als je het te moeilijk gemaakt hebt, het blijft toch een soort mensenboerderij zo’n kantoor…)

      1. Daar kun je over van mening verschillen natuurlijk, omdat een iemand iets zegt is het nog niet persé waar… (zeker als het een geheime dienst betreft die dan weer “moeite” moeten doen om toegang te krijgen tot gegevens die ze interessant vinden?!? Zouden ze het zelf ook in hun beleid hebben staan denk je?) Maar stel dat je toch langer een wachtwoord toe wil laten staan dan kun je altijd nog steeds eenmalig zeggen dat iedereen binnen een periode van een maand een nieuw permanent wachtwoord moet maken dat wel aan de (nieuwe) eisen voldoet… Hoe moeilijk is dat nu werkelijk?

        1. Uiteraard moet het wachtwoord wel aan de sterke eisen voldoen en als hij eenvoudig te kraken is (of opduikt/gebruikt is in een of andere hack) dan kun je hem wel laten resetten. Maar standaard elke volle maan/kwartaal/jaar een nieuw wachtwoord maakt het juist onveiliger.

          Ik heb geen idee of de britse geheime diensten hun eigen advies volgen, maar in mijn ervaring zullen mensen die regelmatig een wachtwoord moeten wijzigen bijna allemaal iets doen als:

        2. Een wachtwoord gebruiken die net aan de minimale eisen voldoet
        3. Een patroon gebruiken om het wachtwoord te veranderen (bijvoorbeeld een getal ophogen)
        4. Opschrijven op een post-it, helemaal als ze hem een paar keer vergeten zijn
        5. Het wachtwoord vergeten waarna de servicedesk hem reset naar een standaard wachtwoord (dat ze vervolgens moeten aanpassen, maar het geeft wel een mogelijkheid voor mensen die dat wachtwoord kennen om het account over te nemen)
        6. Of, zoals ik doe, ze slaan hem op in een wachtwoord manager die vervolgens met 1 wachtwoord te openen is en waar geen bedrijfs-wachtwoord-policy voor op gaat.

          En gelukkig zijn heel veel experts het met mij eens dat wachtwoorden periodiek resetten een slecht idee is (wat niet wil zeggen dat je een wachtwoord nooit moet aanpassen, maar de reden ervoor moet niet zijn ‘het is al zo lang geleden’ maar ‘hij is niet veilig meer’)

          1. Het wachtwoord bij het ziekenhuis waar ik werkte verliep elke 6 maanden. Omdat ik nauwelijks met mijn centrale account werkte (software-ontwikkelingsteam werkte met Macs op ons eigen subnet) belde ik dus 1 a 2 keer per jaar de helpdesk voor een reset (want ik merkte niet wanneer het verliep, ik kreeg die waarschuwing daarover immers niet in beeld op mijn computer).

            Mooiste is echter dat vervolgens dat wachtwoord na het telefoongesprek met de helpdesk iets was als “madelief2”. Die kon je echter dan een dag lang niet opnieuw veranderen! Dus mijn wachtwoord was hierdoor minstens een dag lang van lage kwaliteit, en in de praktijk vaak langer want ik vergat het de volgende dag natuurlijk (want daarna had ik m’n centrale account niet meer nodig).

        7. Daar kun je over van mening verschillen natuurlijk, omdat een iemand iets zegt is het nog niet persé waar…

          Het argument is vrij simpel. Als je mensen dwingt constant hun wachtwoord te veranderen, dan gaan ze automatisch makkelijkere wachtwoorden kiezen, puur omdat mensen een beperkte mogelijkheid hebben voor het onthouden van wachtwoorden.

          Het veelgehoorde argument voor reguliere wijzigingen is het beperken van je ‘exposure window’ – echter, als je er even over nadenkt is dat geen zinnig argument. De gebruiker gaat vrijwel gegarandeerd nummers erachter plakken (iets dat je niet kunt voorkomen als je wachtwoord-opslag in orde is, want je hebt enkel de hashes), en dus maakt het niet uit of je een wachtwoord verandert – een ‘adversary’ hoeft enkel naar het gecompromitteerde wachtwoord te kijken en de nummers wat hoger te maken. Bovendien zijn dit soort wachtwoord-lekken uberhaupt al erg zeldzaam, en heb je veel meer te vrezen van bruteforce-aanvallen – iets dat je met een dergelijke policy alleen maar makkelijker maakt.

          Dus nee, veel meningsverschil valt er niet over te hebben. Het argument voor reguliere wijzigingen is simpelweg fout, en het is een goed voorbeeld van cargo-cultery (iets waar Arnoud hier ook al enkele malen over heeft geschreven, maar dan in de context van het recht). Er is simpelweg geen voordeel te behalen met een dergelijke policy – en je tijd als systeembeheerder is veel beter besteed aan het lesgeven aan personeel over goede wachtwoord-gewoontes (zoals wachtwoord-databases), en/of het implementeren van 2-factor-authenticatie.

          1. iets dat je niet kunt voorkomen als je wachtwoord-opslag in orde is, want je hebt enkel de hashes

            Dat is niet helemaal waar. Je hebt de hashes en het gewenste nieuwe wachtwoord in plain text. Gegeven het nieuwe wachtwoord kun je die muteren om te kijken of vorige wachtwoorden misschien er veel op lijken (gegeven een wachtwoordwijziging naar “pass5word” kun je best de historische wachtwoorden vergelijken met de hash van “pass4word”).

            1. Als ik wachtwoorden aanpas moet ik meestal zowel het oude als het nieuwe wachtwoord opgeven. Dat is niet alleen een beveiliging tegen krakers als je even koffie bent gaan halen en je scherm niet gelockt hebt, maar je kunt dan ook het oude en nieuwe wachtwoord vergelijken. En ik heb inderdaad wel eens een melding gehad dat ze te veel op elkaar leken.

  5. Ik snap de klacht niet. Als je een sterk wachtwoord hebt kunnen ze het niet kraken. Als ze dat wel kunnen, dan heb je dus geen sterk wachtwoord (ongeacht wat je zelf roept) en is het reeel dat je een andere moet kiezen.

    Maar euh, rainbow tables? Seeden ze hun hashes niet?

    1. Seeden? Bedoel je salten?

      Als ze dat goed doen, dan zou een rainbow attack inderdaad niet moeten werken. Een dictionary atack (met generator voor eenvoudige wachtwoord-patronen, bijv. letter-nummer-substitutie) ligt dan meer voor de hand. Is ook wat hackers vaak wel gebruiken.

  6. Wij proberen zelf te stimuleren dat collega’s password managers als LastPass gaan gebruiken. Hiervoor stellen wij collega’s met interesse ook kostenloos premium accounts ter beschikking. Een plus hieraan voor ons is dat LastPass zelf de kracht van wachtwoorden test en dat als een ingekleurde staaf adhv het percentage toont. Indien dit erg laag is dan probeer ik persoonlijk hierover met de betreffende collega in gesprek te gaan. Gelukkig is de bedrijfscultuur er ook wel naar dat collega’s hiervoor open staan.

  7. Maar het kan vervelend zijn voor mensen die al een eigen, sterk wachtwoord hebben en zich nu verplicht zien een heel ander soort wachtwoord erop na te houden.

    Ik zie hier het probleem niet helemaal. Als het wachtwoord op dergelijke wijze kraakbaar is, dan is het dus zwak en had het sowieso niet door deze persoon gebruikt moeten worden, waar dan ook. Dit is een beetje als redeneren dat mensen je code niet mogen auditen omdat ze dan misschien wel beveiligingslekken vinden – dat is het hele punt ervan. Als de auditor dat kan, dan kan een ‘adversary’ het dus ook.

    Overigens zijn patroon-gebaseerde wachtwoorden sowieso zwak, en moet de vraagsteller dus echt eens naar (offline) wachtwoorddatabases als KeePass/KeePassX gaan kijken. Mensen zijn verschrikkelijk voorspelbar, en een dergelijk patroon-wachtwoord mag er dan misschien complex uitzien voor een mens maar is doorgaans triviaal kraakbaar voor een computer.

    Door het gebruik van een wachtwoorddatabase kun je ook daadwerkelijk willekeurig gekozen wachtwoorden gebruiken, en dat is essentieel voor een veilig wachtwoord – of je het dan uitdrukt in letters en cijfers of in woorden maakt niet uit, zolang de onderliggende bron-data maar daadwerkelijk (CSPRNG-)willekeurig is.

  8. Ik denk dat sowieso iedere werkgever gewoon met enige regelmaat alle wachtwoorden van het personeel moet controleren. Als er dan accounts gekraakt worden dan dient de betreffende persoon per direct zijn wachtwoord te wijzigen. Immers, als de werkgever een wachtwoord al kan kraken dan heeft een hacker daar zelfs minder moeite mee.

    De reden hiervoor is ook eenvoudig, want veel gebruikers hebben de neiging om een enkel wachtwoord te gebruiken voor diverse accounts en daarmee zou een hacker dus ook al die accounts kunnen kraken als ze eenmaal een wachtwoord weten.

    Maar goed, ik weet dat er veel bedrijven juist enorm onzorgvuldig met wachtwoorden omgaan en dat levert dan problemen op. Ik heb tot nog toe maar 1x meegemaakt dat de systeembeheerder een dergelijke wachtwoord-audit uitvoerde om te zien of alle bedrijfs-accounts veilig waren. En daarbij waren drie gebruikers die gewoon een veel te simpel wachtwoord hadden gebruikt. (Eentje had 123abc als wachtwoord!) Je moet het personeel nu eenmaal trainen om veiliger te werken.

    Overigens werden toen ook de bureaus gecontroleerd of er zichtbaar briefjes lagen met daarop een wachtwoord geschreven. Die werden vervolgens gewoon opgeruimd waarna er twee mensen gingen klagen want het papiertje was weg en ze konden niet meer inloggen.

    In die tijd gebruikte ik overigens osewiesewosewiesewallakristalla als wachtwoord. Ik kon dat makkelijk onthouden maar was dusdanig lang dat de systeembeheerder ongeduldig werd toen ik een keer samen met hem ging inloggen op mijn PC. 😀 Hij gaf toe dat ik na 16 tekens wel kon stoppen met typen omdat het systeem wachtwoorden afkapte op 16 tekens. Lekker veilig… 😉

    1. Ik heb ooit gewerkt aan een applicatie waar ingelogd werd met een wachtwoord — maar zonder username. Dat kan natuurlijk, zoals je ook voor alarmsystemen iedere gebruiker een eigen code kan geven. Maar dan moeten de wachtwoorden wel uniek zijn. Raad eens hoeveel wachtwoorden “1234” waren en welke constraint dus niet aangebracht was ?

      1. Laat me raden… Iedereen behalve jij gebruikte ‘1234’! 😀

        Ik heb ooit een project overgenomen van een andere ontwikkelaar waarin de gebruiker moest inloggen met gebruikersnaam en wachtwoord. Die wachtwoorden waren eerst met een ROT13 beveiligd en daar was de klant niet blij mee. Dus had hij een SHA-hash gebruikt maar verkeerd geimplementeerd waardoor iets teveel wachtwoorden op dezelfde hash uitkwamen. Ook niet handig. Dus dat mocht ik vervolgens lekker repareren.

        Oh, ja. Er zat nog een ander foutje in. Het opstarten van de applicatie duurde altijd even maar als je snel twee shortcuts intypte (‘Alt+u’, en dan ‘m’) voordat het wachtwoord-dialoog naar voren kwam, dan kwam je in het onderdeel User MAnagement terecht en zag je alle gebruikersnamen en kon je van alle gebruikers het wachtwoord wijzigen. Ja, wel met een login dialoog op de voorgrond maar die kon je opzij schuiven. Ook dat heb ik mogen repareren.

        En qua beveiliging heb ik nog wel veel meer belachelijk zwakke situaties gezien, inclusief een constraint bij een website waarbij wachtwoorden niet langer mochten zijn dan 8 letters en geen cijfers of speciale tekens mochten bevatten. En maar 1 hoofdletter, aan het begin.

        Maar goed, de leukste blunder die ik had meegemaakt was een combinatie van factoren. Een manager van een project had de login gegevens ontvangen van de test-omgeving waar we de nieuwste test-versies hadden geplaatst en was zo slim om deze even aan zijn zoon te geven van 14 om te kijken of zijn zoon het een en ander kon breken. Een dag later zou er dan van diezelfde testversie een demonstratie gegeven worden aan een belangrijke klant. De manager was alleen vergeten om tegen zijn zoon te zeggen dat hij wel net taalgebruik moest gebruiken, dus toen de klant een presentatie kreeg van de test-omgeving met namen zoals ‘meneer Poep’ en ‘mevrouw Pies’ (en dan nog iets grover) wisten we dat het systeem ook op een iets andere maniet “gebroken” kon worden.

        De klant zag er gelukkig de humor van in maar voor iemand die een demonstratie geeft is dit een der ergste nachtmerries. Maar ja, dat krijg je als je minderjarigen met je account laat spelen…

  9. Klinkt alsof deze IT afdeling via Google een leuk tooltje heeft ontdekt en daarmee wil spelen. Het klinkt als een oplossing die op zoek is naar een probleem.

    Want het probleem is niet zwakke wachtwoorden, maar het opschrijven en delen ervan, en het ontbreken van two-factor. Maar ja, dat kan je shiny nieuwe tooltje niet makkelijk ontdekken, dus richt je je maar op wat je wél kunt meten, en verklaart dat vervolgens tot het probleem.

    1. Vooraf doen met PAM op het moment dat het wachtwoord wordt aangemaakt. Zitten zelfs voorbeelden van in PAM.

      Het opschrijven van wachtwoorden is op zich zelf niets mis mee. Het probleem zit hem er in als je dat als sticky note op je monitor plakt. Maar iemand die kwade bedoelingen heeft en fysieke toegang bij je computer kan eenvoudig schade toerichten, ook zonder wachtwoord. Een USB sniffer op het keyboard is zo geinstalleerd. Checkt de gebruiker dat voor ieder gebruik? Natuurlijk niet.

      1. Als iemand met kwade bedoelingen al fysiek bij een systeem kan komen dan is een ander onderdeel van je beveiliging natuurlijk niet in orde. Dan had die persoon net zo makkelijk het hele systeem mee kunnen nemen.

  10. Ik zou willen dat onze systeembeheerder een keer zo’n test zou doen. In plaats daarvan vroeg hij het hele kantoor of ze misschien even hun wachtwoorden (van email, maar werd ook gebruikt als inlog op computer) naar hem wilden emailen voor een script dat op deze manier toegang zou krijgen tot onze mailboxen om de mailboxen te migreren naar een nieuwe emaildienst. En niemand leek dat gek te vinden en volgens mij ben ik de enige die voor de gelegenheid het wachtwoord heeft aangepast. Is natuurlijk ook een manier om te controleren hoe sterk de wachtwoorden zijn…

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.