Het toetsen van de effectiviteit van wachtwoordauthenticatie
Scriptienummer Vrije Universiteit: 2009 Auteur: Niels Kunis, IT-Auditor ING Insurance & Investment Management. Afstudeerbegeleider VU: Paul Harmzen April 2014
1 Voorwoord Voor u ligt de scriptie, die ik schreef ter afsluiting van de postgraduate IT-auditopleiding die ik begin 2012 startte aan de Vrije Universiteit te Amsterdam. Ik koos het onderwerp wachtwoordauthenticatie vanwege de vele inherente risico's die het bevat en ook de vele fouten die in de implementatie ervan gemaakt worden. Deze componenten leiden regelmatig tot incidenten en maakt het een interessant onderwerp van onderzoek. Deze scriptie heeft als doel handvatten aan te reiken aan het management van organisaties, waarmee de effectiviteit van wachtwoordauthenticatie kan worden vastgesteld. Door de gekozen opzet is het ook geschikt er ondersteuning van het riskmanagementproces en IT-audits. Ik wil als eerste mijn VU begeleider Paul Harmzen bedanken voor het meedenken over de structuur en het reviewen. Tevens wil ik de geïnterviewde specialisten Jeroen Kunis, Johan Verrips en Koc-Fai Wu bedanken voor de waardevolle vakinhoudelijke bijdragen. Als laatste wil ik het thuisfront bedanken, niet alleen voor de steun en geduld, maar zeker ook voor de niet vakinhoudelijke bijdrage.
Niels Kunis april 2014
2
2 Inhoudsopgave 1
Voorwoord ........................................................................................................................................................................................2
2
Inhoudsopgave ................................................................................................................................................................................3
3
Inleiding .............................................................................................................................................................................................4 3.1
Achtergrond ...........................................................................................................................................................................4
3.2
Onderzoeksvraag en doel ................................................................................................................................................5
3.3
Aanpak van onderzoek .....................................................................................................................................................5
3.4
Leeswijzer...............................................................................................................................................................................6
4
Scope van het onderzoek ............................................................................................................................................................7 4.1
5
Scope / afbakening .............................................................................................................................................................7
Wachtwoordauthenticatie .........................................................................................................................................................9 5.1
Wat is wachtwoordauthenticatie? ...............................................................................................................................9
5.2
Doelstelling van wachtwoordauthenticatie.............................................................................................................9
5.3
Hoe werkt wachtwoordauthenticatie? ................................................................................................................... 10
5.4
Hoe wordt wachtwoordauthenticatie gebruikt? ................................................................................................ 12
5.5
Effectiviteit van wachtwoordauthenticatie. ......................................................................................................... 13
6
Risico’s bij wachtwoordauthenticatie................................................................................................................................ 14
7
Richtlijnen voor wachtwoordauthenticatie .................................................................................................................... 17 7.1
Inleiding op de onderzochte richtlijnen ................................................................................................................. 17
7.2
Kunnen de maatregelen uit de richtlijnen de incidenten voorkomen? .................................................... 18
7.3
In welke mate worden de risico’s afgedekt door maatregelen uit richtlijnen? .................................... 21
8
Aanvullingen en nuances ......................................................................................................................................................... 23 8.1
Aanvullingen en nuances op de drie onderzochte richtlijnen ...................................................................... 23
8.2
In welke mate hadden de aanvullingen en nuances de incidenten kunnen voorkomen?................ 29
9
Het toetsen van de effectiviteit van wachtwoordauthenticatie ............................................................................. 31
10
Conclusies en samenvatting ................................................................................................................................................... 33
11
Reflectie ........................................................................................................................................................................................... 35
12
Literatuur / bronnen ................................................................................................................................................................. 36
bijlage A maatregelen uit richtlijnen ............................................................................................................................................. 39 bijlage B Relevante ISO 27001 / ISO 27002 maatregelen ................................................................................................... 50 bijlage C Relevante PCI-DSS maatregelen ................................................................................................................................... 52 bijlage D Relevante OWASP maatregelen ................................................................................................................................... 53
3
3 Inleiding 3.1 Achtergrond Het gebruik van wachtwoorden is belangrijk voor de beveiliging van gegevens in een geautomatiseerde gegevensverwerking. Zaken als toegang tot kritieke functionaliteit voor het inzien en bewerken van gegevens en functiescheiding zijn sterk afhankelijk van effectief gebruik van wachtwoordauthenticatie. Wachtwoordauthenticatie is verifiëren van de identiteit van een gebruiker door middel van een wachtwoord. Bijna dagelijks zijn echter problemen met wachtwoorden in het nieuws te lezen. Dit maakt het voor het IT-Auditvakgebied relevant om te onderzoeken. Ter illustratie, een zoekopdracht op “wachtwoord” op www.security.nl levert talloze incidenten op met betrekking tot wachtwoordauthenticatie en geeft een beeld van de kwetsbaarheden ervan. Hieronder een selectie van recente nieuwsberichten op de website security.nl, die een beeld geven van de kwetsbaarheden van wachtwoordauthenticatie, indien nodig met een toelichting. Bij elk incident wordt verwezen naar de bronvermelding. 1. 2.
Adobe gebruikte zwakke encryptie voor opslag wachtwoorden [1]. 1,9 miljoen Adobe-gebruikers hadden '123456' als wachtwoord [2]. Deze berichten refereren naar twee kwetsbaarheden: Adobe sloeg de wachtwoorden onveilig op en gebruikers kozen zwakke wachtwoorden. 3. Facebook waarschuwt gebruikers voor Adobe-hack [3]. Facebook waarschuwt gebruikers dat hun Facebook account in gevaar kan komen indien hun wachtwoord identiek is aan hun Adobe wachtwoord. Dit is een voorbeeld van wachtwoordhergebruik. 4. 42 miljoen wachtwoorden gestolen bij inbraak datingsite [4]. Twee zwakheden met betrekking tot wachtwoordbeveiliging zijn hieruit te extraheren: wachtwoorden werden opgeslagen in klare tekst en gebruikers kozen eenvoudig te raden wachtwoorden doordat sterke wachtwoorden niet werden afgedwongen. 5. GitHub reset wachtwoorden na brute force-aanval [5]. Hierbij zijn een beperkt aantal zwakke wachtwoorden op alle accounts geprobeerd. Het account van gebruikers, die een zwak wachtwoord kozen, werd gecompromitteerd. 6. Klantendatabase goksite Racing Post gestolen [6]. Door een kwetsbaarheid in de webapplicatie is de inhoud van de achterliggende database gestolen en daarmee ook de (versleutelde) wachtwoorden. 7. Microsoft: Europarlementariërs niet gehackt via Exchange-lek [7]. Dit bericht verwijst naar het onderscheppen van wachtwoorden door een zogenaamde man-in-the-middel-aanval op een open wifi internetverbinding. De onderkende kwetsbaarheid is hier afluisteren terwijl het wachtwoord over het netwerk wordt getransporteerd. 8. Forbes-personeel gebruikte zeer zwakke wachtwoorden [8]. 9. Malware steelt 600 wachtwoorden van Duitse overheid [9]. Het betreft hier malware dat de logingegevens, inclusief wachtwoorden, afvangt en doorstuurt naar kwaadwillenden. 10. Amazon-app liet aanvaller onbeperkt wachtwoorden proberen [10] We zien hier al verschillende kwetsbaarheden van het gebruik van wachtwoorden, zoals wachtwoordhergebruik; het onveilig opslaan van wachtwoorden en gebruikers die eenvoudige wachtwoorden kiezen. Aangezien organisaties vaak terughoudend zijn om informatie vrij te geven over incidenten om maar geen imagoschade op te lopen, is het aannemelijk dat dit het topje van de ijsberg is. Maar wat is de rol van de verschillende standaarden voor informatiebeveiliging hierin? Informatiebeveiligingsstandaarden met daarin richtlijnen voor authenticatie en in het bijzonder voor wachtwoordauthenticatie zijn al meer dan tien jaar voor handen. Een bekende standaard is de Code voor Informatiebeveiliging die gestandaardiseerd is in de ISO 27001 en 27002 norm. De ISO 27001 is een standaard voor de inrichting van een managementsysteem om de informatiebeveiligings-risico’s te beheersen. In annex A van de ISO 27001 staan vele maatregelen waaruit de organisatie kan putten om 4
onderkende risico’s ten aanzien van wachtwoordauthenticatie te mitigeren. Een andere bekende standaard is de PCI-DSS, welke gebruikt wordt binnen de creditcardindustrie. Deze norm stelt concrete eisen aan wachtwoordauthenticatie. Hoe kan het zo zijn, dat er al langere tijd relevante informatiebeveiligingsstandaarden voor handen zijn, en toch de incidenten ten aanzien van wachtwoordauthenticatie aan de orde van de dag zijn? Voldoen de standaarden dan niet, of worden ze niet of niet goed toegepast? Of worden niet de juiste afwegingen gemaakt? Deze vragen waren het startpunt voor het formuleren van de uiteindelijke onderzoeksvraag.
3.2 Onderzoeksvraag en doel In de inleiding werd duidelijk dat er vele incidenten zijn ten aanzien van wachtwoordauthenticatie ondanks dat hiervoor al jaren duidelijke standaarden voor handen zijn. Als management van een organisatie kan daardoor de behoefte ontstaan om een review te doen op de implementatie van wachtwoordauthenticatie binnen hun organisatie. Maar wat zou hierbij een geschikte aanpak zijn? Dat is het startpunt van deze scriptie en heeft zich vertaald in de volgende onderzoeksvraag: Hoe kan de effectiviteit van wachtwoordauthenticatie worden getoetst?
Het antwoord op deze vraag levert een bijdrage aan het doel van deze scriptie: Het management van organisaties een hulpmiddel aan te reiken dat inzicht kan geven in de effectiviteit van de implementatie van wachtwoordauthenticatie. Een secundair doel is maatregelen aan te dragen om onderkende risico’s te mitigeren. Dit wordt bereikt door een raamwerk op te leveren voor het toetsen van de effectiviteit van wachtwoordauthenticatie dat gebruikt kan worden bij de risicoanalyse en het selecteren van de juiste maatregelen als onderdeel van de risicomanagement.
3.3 Aanpak van onderzoek Zoals al in de inleiding opgemerkt, rijst de vraag hoe het nu kan dat we al sinds jaar en dag normen hebben voor informatiebeveiliging, inclusief wachtwoordauthenticatie, er nog steeds incidenten voor komen met wachtwoordauthenticatie. Wanneer we op zoek gaan naar normeringen voor wachtwoordauthenticatie, dan zien we dat elke norm die iets te maken heeft met informatiebeveiliging, wel iets zegt over het authenticatie met wachtwoorden. Een inventarisatie levert de volgende lijst met richtlijnen op:
ISO 27001 / ISO 27002 Cobit (ISACA) Standard of Good Practice for Information Security (Information Security Forum, ISF) PCI-DSS NIST Guide to Enterprise Password Management (Draft) NIST Electronic Authentication Guideline Dossier Informatiebeveiliging (Nora) College Bescherming Persoonsgegevens (CBP) Richtsnoeren – beveiliging van persoonsgegevens Open Web Application Security Project (OWASP) best practices
Voor dit onderzoek zullen de ISO 27001/ISO 27002 en PCI-DSS gebruikt worden, aangevuld met bestpractices van OWASP. Er is gekozen voor de ISO 27001 / ISO 27002, omdat dit een veel gebruikte, internationale, standard is voor informatiebeveiliging. Vooral het implementatieadvies in de ISO 27002 bevat concrete maatregelen voor wachtwoordauthenticatie. Als tweede is de PCI-DSS gekozen omdat deze norm gebruikt wordt binnen de creditcardindustrie. Omdat het frauderisico groot is binnen de creditcardindustrie is de verwachting dat dit een vrij strenge norm is en dat de eisen aan wachtwoordauthenticatie relatief hoog zijn. Als laatste is gekozen voor de best-practices van OWASP, 5
omdat deze ontworpen zijn voor websites die ontsloten zijn aan het internet en daarom verwacht mag worden dat er strenge eisen ten aanzien van authenticatie gesteld zijn. Om de maatregelen uit de verschillende normenkaders beter bruikbaar te maken voor het toetsen van de implementatie van wachtwoordauthenticatie is ervoor gekozen om de maatregelen uit de drie gekozen normeringen te structureren naar risico. Om meer structuur te geven is er, per inherent risico, een aantal oorzaken aangegeven en daaraan zijn de maatregelen gekoppeld vanuit de drie normenkaders. De inherente risico’s uitgewerkt in hoofdstuk 6 “Risico’s bij wachtwoordauthenticatie” en de koppeling vanuit de drie normenkaders naar deze risico’s zijn uitgewerkt in 7: “Richtlijnen voor wachtwoordauthenticatie”. Vervolgens is het onderwerp verder verdiept door een literatuurstudie en het bestuderen van diverse publicaties op internet, aangevuld met de eigen kennis en ervaring van de schrijver van deze scriptie. Deze verdieping heeft geleid tot aanvullingen en nuances op de drie richtlijnen. Zo is een geïntegreerd normenkader ontstaan dat vervolgens is getoetst en aangevuld door de volgende specialisten uit de praktijk: Koc-Fai Wu (RE), Cybersecurity specialist ING Bank; Jeroen Kunis (RE), Senior Manager bij KPMG en Johan Verrips, senior security architect Nationale Nederlanden. De aanvullingen en nuances op de onderzochte richtlijnen staan beschreven in hoofdstuk 8: “Aanvullingen en nuances”. Om de centrale vraag “Hoe kan de effectiviteit van wachtwoordauthenticatie worden getoetst?“ te kunnen beantwoorden, wordt deze onderverdeeld in deelvragen:
Wat is wachtwoordauthenticatie? Welke risico’s kunnen worden onderkend ten aanzien van wachtwoordauthenticatie? Welke maatregelen worden aangedragen uit relevante normenkaders? Hoe kunnen de bestaande richtlijnen nog verder worden verbeterd, specifiek op het onderwerp wachtwoordauthenticatie? Hoe kan de effectiviteit van wachtwoordauthenticatie vastgesteld worden?
3.4 Leeswijzer Hoofdstuk 4 bevat een uitwerking van de scope en afbakening van het onderwerp. Hoofdstuk 5 verdiept het onderwerp van onderzoek en geeft antwoord op de eerste deelvraag “Wat is wachtwoordauthenticatie?”. Hoofdstuk 6 gaat in op de risico’s ten aanzien van wachtwoordauthenticatie en geeft antwoord op de tweede deelvraag “Welke risico’s kunnen worden onderkend ten aanzien van wachtwoordauthenticatie?” Hoofdstuk 7 beschrijft welke maatregelen zijn opgenomen in relevante richtlijnen en geeft inzicht in welke maatregelen uit de normen welke risico’s mitigeren. Tevens wordt een inschatting gedaan in hoeverre de richtlijnen de incidenten uit de inleiding hadden kunnen voorkomen. Dit hoofdstuk geeft antwoord op de deelvraag “Welke maatregelen worden aangedragen uit relevante normenkaders?”. Hoofdstuk 8 biedt aanvullingen uit eigen onderzoek en de uitkomst van een toetsing van deze aanvullingen bij een drietal specialisten uit de praktijk. Ook wordt een inschatting gemaakt in hoeverre de aanvullende maatregelen de incidenten uit de inleiding hadden kunnen voorkomen. Dit hoofdstuk geeft antwoord op de deelvraag “Hoe kunnen bestaande richtlijnen worden verbeterd?” In hoofdstuk 9 wordt inzicht gegeven hoe het verbeterde toetsingsraamwerk ingezet kan worden bij het toetsen van de effectiviteit van wachtwoordauthenticatie en geeft antwoord op “Hoe kan de effectiviteit van wachtwoordauthenticatie getoetst worden?”. Hoofdstuk 10 bevat de conclusie en geeft een overzicht van de antwoorden op de deelvragen en centrale vraag “Hoe kan de effectiviteit van wachtwoordauthenticatie vastgesteld worden?”.
6
4 Scope van het onderzoek 4.1 Scope / afbakening Het object van onderzoek is wachtwoordauthenticatie. Wachtwoordauthenticatie is binnen de context van deze scriptie het vaststellen van de identiteit door middel van een wachtwoord. Binnen de scope vallen ook de processen rond wachtwoordauthenticatie zoals het toekennen van wachtwoorden en de procedure om een nieuw wachtwoord toe te kennen als iemand zijn wachtwoord is vergeten. Voor dit onderzoek zijn out of scope: wachtwoorden voor éénmalig gebruik; wachtwoordgebruik bij multi-factor authenticatie; wachtwoordgebruik zonder authenticatie en risico’s die voortkomen uit specifieke systeemzwakheden. Wachtwoorden voor eenmalig gebruik Wachtwoorden voor eenmalig gebruik zijn slechts eenmaal geldig. De problematiek en risico’s rondom éénmalige wachtwoorden zijn anders in vergelijking tot wachtwoorden die meerdere malen gebruikt kunnen worden omdat:
eenmalige wachtwoorden worden niet gekozen door de gebruikers, maar worden gegenereerd door een computer en afgedrukt op een lijst, dan wel op het moment dat het nodig is naar de gebruiker gestuurd met bijvoorbeeld SMS; er na gebruik geen risico meer is op misbruik omdat ze maar eenmalig geldig zijn. eenmalige wachtwoorden kunnen niet worden hergebruikt over meerdere informatiesystemen. langdurig misbruik onmogelijk is
Wachtwoordgebruik bij multi-factor authenticatie Bij multi-factor authenticatie wordt voor de authenticatie op minimaal twee factoren vertrouwd voor de authenticatie. Hoe meer factoren er gevraagd worden om de identiteit te bewijzen, hoe groter de zekerheid over de identiteit van de persoon die probeert in te loggen op een informatiesysteem. De factoren kunnen zijn:
Kennis, iets wat de gebruiker weet zoals een wachtwoord; Eigendom, iets dat de gebruiker in bezit heeft zoals een smartcard of een mobiele telefoon; een inherente factor, iets wat de gebruiker is, zoals een vingerafdruk of de vorm van de tekening in de iris.
Net als bij authenticatie met wachtwoorden voor eenmalig gebruik is ook bij multi-factor authenticatie de problematiek en het risicoprofiel anders. Het inherente risico is kleiner omdat niet meer vertrouwd wordt op het wachtwoord alleen, maar ook een tweede factor vereist is. Wachtwoordgebruik zonder identificatie Wachtwoorden worden ook gebruikt om informatie te beschermen zonder dat eerst identificatie nodig is. De toegang wordt dus verschaft aan iedereen die het wachtwoord weet. Dit valt buiten de scope omdat dit geen authenticatie betreft. Het doel van authenticatie is het vaststellen van iemands identiteit en daarvan is geen sprake wanneer er geen identificatie-stap is. Voorbeelden zijn USB-sticks met een wachtwoord, een wachtwoordkluis-bestand dat beveiligd is met een wachtwoord of een versleutelde harde schijf. Hoewel dit buiten de scope valt voor deze scriptie, is dit wel interessant, want wanneer iemand misbruik maakt van zo’n wachtwoord, maakt deze zich niet schuldig aan identiteitsfraude. Is in dat geval dan nog sprake van ongeautoriseerd toegang? Risico’s van wachtwoordauthenticatie die voortkomen uit specifieke systeemzwakheden Wachtwoorden die uitlekken door specifieke zwakheden in systemen worden buiten beschouwing gelaten. Het uitlekken van wachtwoorden wordt in deze scriptie gezien als een inherent risico, omdat het 7
voor de onderzoeksvraag niet relevant is hoe precies een wachtwoord kan uitlekken. Wel worden er op hoger abstractieniveau maatregelen besproken zoals het hardenen1 en patchen2 van een systeem.
Systeem-hardening: Het “dichttimmeren” van een systeem door onder andere het verwijderen van onnodige software en het instellen van systeemparameters, dusdanig dat een optimale beveiliging bereikt wordt. 2 Patchen is het aanbrengen van updates op software met als doel kwetsbaarheden en fouten in informatiesystemensystemen weg te nemen of te verminderen. 1
8
5 Wachtwoordauthenticatie 5.1 Wat is wachtwoordauthenticatie? Om ongeautoriseerd lezen of wijzigen van gegevens te voorkomen, zijn hedendaagse informatiesystemen voorzien van een mechanisme voor logische toegangsbeveiliging. Logische toegangsbeveiliging is mede een waarborg voor de betrouwbaarheid van de geautomatiseerde gegevensverwerking. Belangrijke aspecten van logische toegangsbeveiliging zijn het vaststellen van de identiteit van een gebruiker bij het inloggen en het toekennen, wijzigen en intrekken van toegangsrechten. Bij het onderzoek naar de definitie kwamen verschillende definities aan het licht, die in de kern hetzelfde zijn. We hanteren de definitie zoals staat in het Nederlandse OverheidsReferentieArchitectuur (Nora) [11]: “Authenticatie is het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.” Bij authenticatie gaat het er dus om dat aangetoond wordt dat een identiteitsclaim geverifieerd wordt. De claim van een bepaalde identiteit wordt meestal gedaan door de loginnaam in te geven op het systeem. Het is ook mogelijk dat een computersysteem zich identificeert bij een ander computersysteem. In dat geval is het doel van authenticatie zekerheid te verschaffen over de identificatie van dat andere systeem. Voor het gemak spreken we in deze scriptie van “hij”, terwijl dat dus ook een “zij” of een “het” kan zijn. Bij wachtwoordauthenticatie wordt het bewijs geleverd door het overhandigen van een wachtwoord, gekoppeld aan deze identiteitsclaim. Wanneer authenticatie heeft plaatsgehad, heeft een computersysteem vastgesteld dat de persoon of systeem (z.g. claimant3) is die hij zegt dat hij is. De verificatie van de identiteit is belangrijk, omdat de identiteit van een gebruiker een vereiste is voor de autorisaties. Het systeem geeft toegang tot bepaalde informatie, afhankelijk van onder welke naam er wordt ingelogd. Ook bepaalt het systeem wat er met de informatie gedaan kan worden: bijvoorbeeld alleen lezen of ook modificeren van gegevens. Een wachtwoord geeft toegang tot een gebruikersaccount. Een gebruikersaccount wordt gebruikt op z.g. multi-user systemen, waarbij het systeem onderscheid kan maken tussen verschillende gebruikers. In deze scriptie wordt de definite van Encyclopia [12] gehanteerd. Deze luidt als volgt: “A collection of data associated with a particular user of a multiuser computer system. Each account comprises a user name and password, and defines security access levels, disk storage space, etc. The system administrator is responsible for setting up and overseeing user accounts.”
5.2 Doelstelling van wachtwoordauthenticatie De doelstelling van wachtwoordauthenticatie binnen de scope van deze scriptie is het verifiëren van de identiteit van een claimant door middel van een wachtwoord. Dit levert een bijdrage aan de volgende doelen:
3
Waarborgen van de vertrouwelijkheid van informatie. Alleen geautoriseerde personen mogen gegevens lezen. Mede een waarborg van de integriteit van de informatie. Alleen geautoriseerde personen mogen de gegevens aanpassen. Onweerlegbaarheid. Het kunnen bewijzen dat alleen een bepaald persoon bepaalde acties heeft uitgevoerd in het systeem. Dit hangt overigens wel van de loggingfaciliteiten van het systeem af.
Een claimant is een iemand of iets die een identiteit claimt. 9
Waarborg voor de beschikbaarheid van data en informatiesystemen. Wanneer iemand zich ongeautoriseerd toegang kan verschaffen tot een informatiesysteem, dan zou deze persoon de data of het systeem zelf onbeschikbaar kunnen maken door gegevens te wissen en/of het informatiesysteem te ontregelen. Het technisch afdwingen van functiescheidingen in informatiesystemen. Functiescheiding is een maatregel, waarbij functies worden verdeeld zodat iedere medewerker maar een deel van het totale proces kan beïnvloeden en de mogelijkheid bestaat tot wederzijdse controle. Een voorwaarde voor het inregelen van afgedwongen functiescheidingen in informatiesystemen is dat het systeem persoon X van persoon Y kan onderscheiden.
5.3 Hoe werkt wachtwoordauthenticatie? Om een beter inzicht te verschaffen in problematiek en risico’s is het van belang de processen en technische achtergrondinformatie te kennen rond het instellen en controleren van het wachtwoord. Hieronder volgt daarom een korte uiteenzetting van deze twee onderwerpen. 1) Het instellen van het wachtwoord. Procedureel Initieel wordt het wachtwoord ingesteld door een gebruikersaccount en wachtwoorduitgifteproces. Een belangrijk aspect is de identificatie van de gebruiker, alvorens het wachtwoord ter beschikking te stellen. Wanneer de gebruiker zijn wachtwoord vergeten is, zal ervoor gezorgd moeten worden dat de gebruiker een nieuw wachtwoord krijgt. De procedure die in werking treedt hiervoor wordt de wachtwoordresetprocedure genoemd. Ook hier is het van het grootste belang dat het wachtwoord aan de juiste persoon overhandigd wordt, om te voorkomen dat het wachtwoord in de verkeerde handen valt. Technisch Praktisch alle moderne informatiesystemen die wachtwoordauthenticatie gebruiken, werken volgens het systeem dat staat beschreven in “Handbook of applied cryptography” [13]. Dit systeem, dat in hoofdstuk 10.2 “Passwords” is opgenomen, beschrijft eerst het instellen van het wachtwoord. Bij het instellen van het wachtwoord wordt niet het wachtwoord opgeslagen, maar de uitkomst van een niet-omkeerbare cryptografische hashfunctie. De uitkomst van deze functie wordt de hash of wachtwoordhash genoemd. De hash is niet op een triviale manier om te zetten in het leesbare wachtwoord. 2) Authenticatie. Procedureel De gebruiker voert gebruikersnaam en wachtwoord in. Het systeem controleert vervolgens of het ingevoerde wachtwoord identiek is aan het wachtwoord dat is ingevoerd bij het instellen van het wachtwoord. Technisch: Bij het controleren van het wachtwoord, wordt over hetgeen de gebruiker heeft ingevoerd een hashfunctie uitgerekend, net zoals dat bij het instellen van het wachtwoord is gebeurd. Wanneer deze hash gelijk is aan de hash die gegenereerd is bij het instellen van het wachtwoord, dan resulteert dit in een succesvolle authenticatie. Dit is schematisch uitgebeeld in het volgend schema uit “Handbook of applied cryptography” [13], Figuur 10.1 “Use of one-way function for password checking”:
10
figuur 1. Login mechanisme. Bron: [13], Figure 10.1 “Use of one-way function for password checking”. “Claimant A” is een gebruiker die wil inloggen op een systeem en een identiteit claimt door het invoeren van een login-naam. Hij voert bij het inloggen zijn wachtwoord (zie figuur 1 “password”) en zijn loginnaam (zie figuur 1: “A”) in. In het informatiesysteem wordt de cryptografische hash uitgerekend in de rekenbox (zie figuur 1: “h”) en wordt de opgeslagen hash uit de tabel gelezen van de betreffende gebruiker “A”. Wanneer beide hashes identiek zijn, en dit is alleen zo als de gebruiker het juiste wachtwoord heeft ingevuld, dan volgt een acceptatie (ACCEPT), anders een afkeuring (REJECT). Ter illustratie volgt nu een stapsgewijze beschrijving van dit proces waarbij het wachtwoord wordt gehasht met het hashing-algoritme SHA-1. Stap 1: het instellen van het wachtwoord. Er wordt gekozen voor het wachtwoord “Pietje@Puk,,nl”. De SHA-1 hash van dit wachtwoord is a3b18e7ac7db39e44681aaa5fd70a01e3d6c0542 en dit wordt opgeslagen bij de loginnaam van de gebruiker. Anders dan bij encryptie, waarbij een versleutelde boodschap met behulp van een wachtwoord terug omgezet kan worden in klare tekst, is dit bij een hashfunctie niet zondermeer mogelijk. Stap 2: Het controleren van het wachtwoord (authenticatie) De gebruiker wil nu inloggen. Hij voert zijn login-naam in en als wachtwoord “Pietje@Puk.,ml”, hij toetst dus per ongeluk voor de “n” een “m” in. Door de eigenschappen van een hashfunctie resulteert dit in een compleet andere hash: 7fbd56aa6d0d5bc3393684c964d0f31563f29c85. Het systeem vergelijkt de uitgerekende hash met de opgeslagen hash en constateert dat de hashes niet gelijk zijn en daarom zal het systeem de gebruiker niet authentiseren. De gebruiker probeert het nog een keer, nu met het juiste wachtwoord “
[email protected]”. De SHA-1 hash die nu wordt uitgerekend, “a3b18e7ac7db39e44681aaa5fd70a01e3d6c0542”, is wél identiek aan de opgeslagen hash en de gebruiker wordt geauthentiseerd en daarna toegelaten tot het systeem. Opmerking: dit is een voorbeeld ter illustratie, waarbij specifieke risico’s van het opslaan van wachtwoorden in hash-vorm niet zijn afgedekt.
11
5.4 Hoe wordt wachtwoordauthenticatie gebruikt? Wachtwoordauthenticatie wordt gebruikt voor de authenticatie van eindgebruikers en computerprocessen. Wachtwoordauthenticatie van eindgebruikers Dit is de meest bekende vorm van wachtwoordauthenticatie en dit behelst een eindgebruiker in de vorm van een mens, dat gebruik wil maken van een informatiesysteem. Kenmerkend voor wachtwoordwoordauthenticatie van eindgebruikers zijn de login-schermen met daarop de invoervelden voor loginnaam en wachtwoord. Hieronder enkele voorbeelden van een login op SalesForce en Windows 8:
figuur 2: Salesforce login
figuur 3: Windows 8 login Wachtwoordauthenticatie door computerprocessen Niet alleen mensen loggen in en gebruiken daarbij wachtwoorden, maar ook computerprocessen. Een computerproces is software dat actief is op een computersysteem. Een voorbeeld van zo’n computer proces bijvoorbeeld een (Java) applicatieserver. Een applicatieserver gebruikt vaak data dat is opgeslagen in een databaseserver. Om gebruik te kunnen maken van de databaseserver zal de applicatieserver eerst moeten inloggen op de databaseserver. Dit gebeurt praktisch altijd met een wachtwoord. In figuur 4 is een z.g. 3-tier architectuur weer gegeven met daarin twee applicatieservers die gebruik maken van één databaseserver.
12
figuur 4: 3-tier architecture
5.5 Effectiviteit van wachtwoordauthenticatie. Een effectieve wachtwoordauthenticatie is zo ingericht dat het doel behaald wordt en (bedrijfs)processen zo min mogelijk gehinderd worden. Zoals besproken in hoofdstuk 5.2 “Doelstelling van wachtwoordauthenticatie” is het doel van wachtwoordauthenticatie het vast stellen van de identiteit van een claimant om als basis te kunnen fungeren voor het zekerstellen van de vertrouwelijkheid, integriteit en beschikbaarheid van bedrijfsgegevens, alsmede voor het garanderen van functiescheidingen en het onweerlegbaarheid. Bij de definitie van wat een effectieve wachtwoordbeveiliging is, zouden we echter niet alleen naar het primaire doel moeten kijken, maar ook naar de kans van een onterechte uitsluiting, en gebruikersvriendelijkheid. Een effectieve wachtwoordbeveiliging zal met al deze aspecten rekening houden. We definiëren een effectieve wachtwoordbeveiliging daarom als volgt:
Kleine kans op een geslaagde ongeautoriseerde login op een informatiesysteem. Een onterechte login treedt op wanneer iemand die niet is geautoriseerd om een bepaald gebruikersaccount te gebruiken, deze toch kan gebruiken en in staat is in te loggen met dit account. Kleine kans op het onterecht buitensluiten van legitieme gebruikers. Wanneer legitieme gebruikers onterecht worden uitgesloten, dan kan dit een negatieve impact hebben op de (bedrijfs-)processen. Vooral wanneer de productiviteit van medewerkers, de klanttevredenheid of de motivatie van medewerkers worden verminderd. Gebruiksvriendelijkheid. Een ongebruiksvriendelijke authenticatiemechanisme kan leiden tot verlies van productieve uren en/of ontevreden klanten.
Op welk aspect de nadruk moet worden gegeven, hangt af van de doelen en prioriteiten van een onderneming. Vooral bij het selecteren van maatregelen om de risico’s van wachtwoordauthenticatie (zie hoofdstuk 6) te verminderen, zal er een afweging tussen bovenstaande aspecten gemaakt moeten worden. Algemeen moeten de kosten van het totale pakket aan maatregelen rond wachtwoordauthenticatie altijd in verhouding staan met de mate van risico-mitigatie. Een uitzondering hierop is een eis die een maatregel wettelijk afdwingt.
13
6 Risico’s bij wachtwoordauthenticatie In dit hoofdstuk is getracht alle inherente risico’s te specificeren van wachtwoordauthenticatie om als hulp te dienen bij het maken van risicoanalyses. Wachtwoordauthenticatie wordt ingevoerd om een bijdrage te leveren aan een aantal organisatiedoelen. Wat deze doelen precies zijn, hangt uiteraard af van de organisatie; de processen; de computersystemen en de gegevens die erin zitten. Deze doelen zijn al in hoofdstuk 5.2 “Doelstelling van wachtwoordauthenticatie” behandeld:
Waarborg van de vertrouwelijkheid van informatie. Waarborg van de integriteit van de informatie Onweerlegbaarheid. Waarborg voor de beschikbaarheid van data en informatiesystemen. Het (technisch) afdwingen van functiescheidingen in informatiesystemen.
De risico’s van wachtwoordauthenticatie kunnen worden gevonden in dreigingen, die er toe zouden kunnen leiden dat bovenstaande organisatiedoelen niet worden bereikt. Bij het samenstellen van de in dit hoofdstuk genoemde lijst van risico’s is gebruik gemaakt van NIST’s “Guide to Enterprise Password Management” [14], aangevuld met risico’s uit een presentatie van Joe St Sauver “Passwords” [15] omdat de NIST een bruikbare structuur aan draagt voor risico’s ten aanzien van wachtwoordauthenticatie en omdat de presentatie van Joe St Sauver een zeer uitgebreide lijst met risico’s en incidenten in zich heeft. Risico 1: Wachtwoorden vallen in handen van een derde Zoals besproken in hoofdstuk 4.1 is een wachtwoord een vorm van één-factor authenticatie. De factor is hier kennis. Inherent risico’s van kennis zijn dat het dupliceerbaar is en dat het dus kan uitlekken. Wanneer een wachtwoord in handen valt van een derde, dan weet hij het wachtwoord ook. Vanaf dat moment kan dat individu zich ongeautoriseerd toegang verschaffen tot het informatiesysteem en de autorisaties van de legitieme gebruiker misbruiken. Dit risico kan leiden tot het niet halen van alle vijf hierboven genoemde organisatiedoelen. Mogelijk oorzaken zijn: a) Ineffectieve processen voor wachtwoord uitgifte / reset ten aanzien van identificatie zoals: Inadequate identificatie van eindgebruiker. eenvoudig te raden wachtwoorden worden uitgegeven. De manier van communiceren van de wachtwoorden aan de eindgebruiker, als onderdeel van de gebruikersaccountcreatie- of wachtwoordresetprocedure, is kwetsbaar voor afluisteren. Medewerkers van de servicedesk weten het wachtwoord van de eindgebruiker. b) social-engineering of handelen van de gebruiker zoals: De gebruiker vertelt zijn wachtwoord vrijwillig door aan een derde, bijvoorbeeld omdat iemand tijdens vakantie zijn werk moet overnemen. een derde kan het wachtwoord raden omdat de gebruiker een eenvoudig te raden wachtwoord koos. Een derde gebruikt een elders gecompromitteerd wachtwoord doordat de gebruiker wachtwoorden hergebruikt. Een derde ontfutselt het wachtwoord bij een gebruiker door social-engineering technieken toe te passen zoals phishing4. Een derde heeft toegang tot de door de gebruiker onveilig opgeslagen wachtwoorden Omkoping. Phishing is een techniek waarbij door middel van email informatie zoals bijvoorbeeld gebruikersnaam en wachtwoord van een gebruiker wordt ontfutseld. 4
14
c) d) e) f) g) h) i)
Bedreiging. Samenspanning Een hardware/software keylogger of camera. Een hacker of kwaadaardige software steelt de wachtwoorden of wachtwoordhashes. Een hacker kraakt de wachtwoordhashes nadat hij het systeem gecompromitteerd heeft. Wachtwoorden worden afgeluisterd wanneer ze over het netwerk worden verstuurd. Online guessing. Het wachtwoord wordt gevonden door een groot aantal verschillende wachtwoorden te proberen op één of meerdere gebruikersaccounts. Een derde vindt het wachtwoord door een enkele eenvoudige wachtwoorden te proberen op alle of een groot aantal gebruikersaccounts. Een derde steelt de wachtwoorden of wachtwoordhashes van backup-media.
Risico 2: Wachtwoorden van niet-persoonsgebonden accounts blijven bekend bij personen, terwijl dat niet (meer) hoort bij hun taken en verantwoordelijkheden In sommige gevallen is het onvermijdelijk dat niet-persoonlijke accounts gebruikt worden. Een niet persoonlijk account wordt vaak gedeeld met meerdere personen en is niet triviaal herleidbaar naar een natuurlijk persoon. Wanneer één van die geautoriseerde personen een niet-geautoriseerd persoon wordt, doordat deze persoon een andere rol krijgt of het bedrijf verlaat, dan kan deze persoon misbruik maken van het betreffende niet-persoonlijke account, omdat hij nog het wachtwoord weet. Dit risico kan leiden tot het niet halen van één of meer van de vijf hierboven genoemde doelen. De onweerlegbaarheid komt in gevaar omdat meerdere mensen één account delen. Mogelijke oorzaken zijn: a) Een wachtwoord van een niet-persoonsgebonden account is niet gewijzigd nadat iemand het team verlaat of ander werk gaat doen. b) Een standaard wachtwoord is niet gewijzigd Risico 3: Wachtwoorden worden vervangen door een bij een andere persoon bekend wachtwoord Om het wachtwoord bij het inloggen te kunnen controleren, moet het systeem een vorm van wachtwoordopslag hebben. Wanneer een kwaadwillende er in slaagt het opgeslagen wachtwoord van een account dat niet van hem is (tijdelijk) te vervangen door een wachtwoord dat hij wél kent dan kan de kwaadwillende persoon ongeautoriseerd inloggen op dat gebruikersaccount. Ook dit risico kan leiden tot het niet halen van alle vijf hierboven genoemde doelen omdat het leidt tot ongeautoriseerde toegang tot een gebruikersaccount. Mogelijk oorzaken zijn: a) Ondeugdelijke wachtwoordresetprocedures. b) Wachtwoorden of wachtwoordhashes zijn onvoldoende beschermd tegen ongeautoriseerd wijzigen. c) Social-engineering. Hierbij wordt de gebruiker verleid om zijn wachtwoord te veranderen op aangeven van een kwaadwillende. d) Een kwaadwillende wijzigt het wachtwoord door misbruik te maken van een werkstation of mobiel apparaat waarop de legitieme gebruiker is ingelogd. e) Een systeembeheerder vervangt (tijdelijk) het wachtwoord of wachtwoordhashes waarna deze tijdelijk misbruik kan maken van andermans gebruikersaccount. Dit is een bedreiging voor de onweerlegbaarheid. Risico 4: Wachtwoorden die eenmaal gecompromitteerd zijn, worden lange tijd misbruikt Dit behelst het risico dat in het geval een wachtwoord eenmaal gecompromitteerd is, deze lange tijd gebruikt kan worden. Ook dit risico kan leiden tot het niet halen van alle vijf hierboven genoemde doelen.
15
Mogelijk oorzaken zijn: a) wachtwoorden blijven lange tijd hetzelfde doordat wachtwoordwijzigingen niet worden afgedwongen. b) de gebruiker het uitlekken van zijn wachtwoord niet meldt en geen actie onderneemt. c) de gebruiker gebruikt opvolgende wachtwoorden waardoor het volgende wachtwoord steeds voorspelbaar is. Risico 5: Iemand wordt ten onrechte niet geauthentiseerd op een informatiesysteem Dit risico is een primair een beschikbaarheidsrisico. Wanneer een gebruiker niet kan inloggen doordat het authenticatiesysteem niet goed werkt, dan kost dit productieve uren en kunnen de bedrijfsprocessen in gevaar komen. Ook kan dit leiden tot ontevreden klanten. Mogelijke oorzaken kunnen zijn: a) De authenticatieserver is niet beschikbaar. b) De integriteit van de wachtwoordopslag (c.q. wachtwoordhashes) is aangetast. c) Het account is vergrendeld doordat het lockoutmechanisme wordt misbruikt voor een Denial of Service (DOS) aanval. Hierbij worden accounts moedwillig geblokkeerd door meerdere malen achter elkaar een fout wachtwoord te gebruiken.
16
7 Richtlijnen voor wachtwoordauthenticatie 7.1 Inleiding op de onderzochte richtlijnen Zoals behandeld in de hoofdstuk 3.3 “Aanpak van onderzoek”, wordt de nadruk gelegd op de ISO 27001/ISO 27002, PCI-DSS en de richtlijnen van het Open Web Application Security Project (OWASP) om een beeld te krijgen welke maatregelen aangedragen worden vanuit relevante richtlijnen. In dit hoofdstuk 7 wordt ingegaan op de aard van de gekozen normen, in welke mate de maatregelen de incidenten uit de inleiding hadden kunnen voorkomen en of de maatregelen uit de richtlijnen de onderkende risico’s uit hoofdstuk 6 kunnen mitigeren. ISO 27001 / ISO 27002 [16] [17]. De ISO 27001 [16] en ISO 27002 [17] zijn ISO standaarden voor informatiebeveiliging. Hoewel er tijdens het schrijven van deze thesis een 2013 versie van deze standaarden uitgekomen is, is toch gebruik gemaakt van de 2005 versie omdat deze nog steeds het meest gebruikt wordt. Uit een artikel van Dejan Kosutic [18] blijkt dat er ten aanzien van wachtwoordauthenticatie geen nieuwe maatregelen zijn opgenomen in de 2013 versies van deze standaarden, dus de 2013 versie is verder buiten beschouwing gelaten. De ISO 27001 is een norm voor z.g. “security management system”. In wezen is de ISO 27001 een riskmanagement methodiek dat toegespitst is op informatiebeveiliging en heeft daarom als doel de risico’s ten aanzien van informatiebeveiliging te beheersen. Belangrijke aspecten zijn de risicoanalyse; het bepalen van maatregelen en het continu verbeteren van het managementsysteem rond informatiebeveiliging. De maatregelen die in annex A van ISO 27001 genoemd zijn, zijn bedoeld om maatregelen te extraheren als onderdeel van het risicomanagement. Het is dus niet gezegd dat met de invoering van de maatregelen uit Annex A alle risico’s adequaat gemitigeerd worden. Dit hangt namelijk sterk af van de specifieke risico’s en beheersdoelstellingen. Ook beperkt de ISO 27001 zich ook niet tot de maatregelen in de Annex A. Men is vrij extra maatregelen te implementeren wanneer dat nodig is op basis van de risicoanalyse. De ISO 27002 bevat implementatie-adviezen voor de maatregelen die in Annex A van de ISO 27001 genoemd zijn. In bijlage B is een overzicht te vinden van de maatregelen in Annex A van ISO 27001, inclusief de implementatieadviezen uit ISO 27002, die relevant zijn voor wachtwoordauthenticatie PCI-DSS [19]. PCI-DSS staat voor Payment Card Industry – Data Security Standard. Deze richtlijn wordt mondiaal opgelegd door de grote creditcard bedrijven zoals Visa en Mastercard aan bedrijven die creditcardgegevens verwerken. Deze norm bevat een aantal eisen aan wachtwoordauthenticatie die zijn opgesomd in bijlage C. Echter, de PCI-DSS sluit het gebruik van een wachtwoord alléén uit voor bepaalde toepassingen zoals remote access. OWASP OWASP staat voor Open Web Application Security Project en is een werkgroep dat zich toelegt op de beveiliging van webapplicaties. Omdat webapplicaties vaak blootgesteld worden aan het internet, is de kans op aanvallen van buitenaf groot en dat kunnen we bijna dagelijks zien in de media (zie ook de inleiding, hoofdstuk 3). Een deel van de OWASP aanbevelingen hebben betrekking op wachtwoordauthenticatie. OWASP heeft een aantal z.g. cheat sheets [20] gepubliceerd, met daarin maatregelen om de authenticatie met wachtwoorden veiliger te maken. Hoewel OWASP zich richt op webapplicaties, zijn de beschreven maatregelen breder toepasbaar. Omdat een webapplicatie een verbijzondering is van een applicatie kunnen de richtlijnen van de OWASP, die primair ontworpen zijn voor webapplicaties, vaak ook worden gebruikt voor niet-webapplicaties. De cheat sheets voor Authentication, Password Storage en, Forgot Password zijn het meest relevant voor het onderwerp wachtwoordauthenticatie. Naast de cheat sheets heeft OWASP nog publicaties op internet in de vorm van een Password length & complexity best practice een Developer Guide en een Authentication best practice.
17
In bijlage D is een op risico gestructureerd overzicht te vinden van relevante cheat sheets en de maatregelen die daarin beschreven staan. De doelgroep voor de ISO 27001/2 zijn alle organisaties waarvoor informatiebeveiliging belangrijk is en is daarmee de minst verbijzonderde richtlijn van de drie. De relevante maatregelen voor wachtwoordauthenticatie zijn: A.8.3.3: Het verwijderen van toegangsrechten; A.11.2.3: Wachtwoord beheer; A.11.3.1: Gebruikers verantwoordelijkheden ten aanzien van wachtwoorden; A.11.5.1: Veilige login procedures; A.11.5.3: Wachtwoord beheer systeem. Omdat de ISO 27001/2 het minst verbijzonderd is op een situatie, zijn de maatregelen ook het minst specifiek. Zelfs het implementatieadvies dat is opgenomen in de ISO 27002 geeft daardoor niet al te concreet advies. Voor wachtwoordauthenticatie betekent dat bijvoorbeeld dat er beleid moet zijn voor een minimale wachtwoordlengte, maar deze wordt niet gespecifieerd. De PCI-DSS daarentegen is concreter en normatiever hierin en dat leidt er toe dat een minimale wachtwoordlengte wordt geëist van 7 tekens. De meeste maatregelen, relevant voor wachtwoordauthenticatie in de PCI-DSS zijn ook in de bijlage van ISO 27001 opgenomen, ware het niet dat de maatregelen in de PCI-DSS concreter zijn geformuleerd. Waar ISO 27001/27002 en PCI DSS op een vrij hoog abstractieniveau zijn beschreven, is OWASP veel praktischer, gedetailleerder en technischer. OWASP geeft bijvoorbeeld gedetailleerde instructies hoe een wachtwoord veilig opgeslagen kan worden en waar dan precies een wachtwoordresetprocedure aan zou moeten voldoen. Voor belangrijke onderwerpen ten aanzien van wachtwoordauthenticatie zijn z.g. cheat sheets ontwikkeld. Uit de wijzigingshistorie van de OWASP documenten is te zien dat de laatste wijzigingsdatum niet langer geleden is dan 6 maanden. Daarmee zijn de OWASP documenten volatieler dan de ISO 27001/2 en PCI-DSS richtlijnen. Waarschijnlijk doordat de OWASP richtlijnen wat volatieler zijn, zijn ze ook op punten ook wat minder consistent. Zo adviseert de OWASP’s “Authentication Cheat Sheet” een minimale wachtwoordlengte van 10 tekens, waar de het advies in “Password length & complexity” 8 karakters als veilig minimum is en in de “Developer guide” wordt gesteld dat wachtwoorden onder de 16 karakters niet veilig zijn.
7.2 Kunnen de maatregelen uit de richtlijnen de incidenten voorkomen? De vraag rijst nu, waren de incidenten genoemd in de inleiding ook op getreden als de onderzochte normeringen waren toegepast? Dit hoofdstuk geeft daar per richtlijn een antwoord op. In de basis zouden de ISO 27001 en PCI-DSS de incidenten geheel kunnen afdekken als onderdeel van goed riskmanagement. Hieronder worden echter alleen de concrete maatregelen uit de richtlijnen aan gehouden om het concreet te houden. 1.
Adobe gebruikte zwakke encryptie voor opslag wachtwoorden [1]. Bij dit incident zijn hackers ingebroken op het netwerk van Adobe en hebben de versleutelde wachtwoorden gestolen. De wachtwoorden waren wel versleuteld maar met een symmetrische encryptie. Deze manier van versleutelen is in strijd met alle drie de onderzochte normeringen. De OWASP geeft de meest gedetailleerde instructies door ook adviezen te geven welke one-way versleuteling (oftewel hashing) betrouwbaar zijn voor het opslaan van wachtwoorden. Wanneer het advies van de OWASP was opgevolgd, was er geen symmetrische encryptie gebruikt en zou een sterk hashingalgoritme zijn gebruikt. De OWASP adviseert ook trivialiteitscontroles bij het instellen van wachtwoorden door gebruikers, wat zwakke wachtwoorden kan voorkomen. Met deze OWASP maatregelen zouden er nog steeds wachtwoorden worden gecompromitteerd maar een kleiner aantal en het zou langer duren om ze te kraken waarbij ook meer rekenkracht nodig is.
18
ISO 27001 / ISO 27002
PCI-DSS
OWASP
deels omdat wel one-way encryptie wordt voorgeschreven maar niet hoe precies.
deels omdat wel one-way encryptie wordt voorgeschreven maar niet hoe precies.
ja, zwakke encryptie van wachtwoorden zou niet gebeurd zijn.
2.
1,9 miljoen Adobe-gebruikers hadden '123456' als wachtwoord [2]. Dit bericht gaat over de keuze van eenvoudig te raden wachtwoordkeuze door gebruikers. Onderzoeken, genaamd “Consumer Password Worst Practices” [21], “A Large-Scal Study of Web Password Habits” [22] en “A brief Sony password analysis” [23] wijzen uit dat gebruikers eenvoudig te raden wachtwoorden kiezen. Zowel de ISO 27001/2, PCI-DSS als OWASP adviseren een minimale wachtwoordlengte en eisen te stellen aan de wachtwoordcomplexiteit. ISO 27002 stelt dat gebruikers geadviseerd moet worden om eenvoudig te raden wachtwoorden te mijden. Dit laatste is een relatief zwakke maatregel, omdat dit niet technisch wordt afgedwongen. De OWASP “Developer guide” adviseert een trivialiteitscontrole bij het instellen van wachtwoorden, wat een maatregel is tegen gebruikers die eenvoudig te raden wachtwoorden kiezen.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
deels, door adviezen aan gebruikers
deels door wachtwoordeisen te stellen, echter eenvoudige wachtwoorden zijn nog steeds een risico binnen de grenzen van het wachtwoordbeleid.
ja, door controle op triviale wachtwoorden.
3.
Facebook waarschuwt gebruikers voor Adobe-hack [3]. Facebook waarschuwt gebruikers dat hun Facebook account in gevaar kan komen indien hun wachtwoord identiek is aan hun Adobe wachtwoord. Dit is een voorbeeld van wachtwoordhergebruik. Uit de onderzoeken: “A Large-Scal Study of Web Password Habits” [22] en “What do Sony and Yahoo have in common? Passwords!” [24] blijkt dat gebruikers op grote schaal wachtwoorden hergebruiken over verschillende informatiesystemen. Wanneer één informatiesysteem wordt gecompromitteerd, kan dat een direct gevaar betekenen voor andere informatiesystemen. In een slechter scenario kunnen wachtwoorden, die gestolen zijn van een externe website, zelfs gebruikt worden om in te loggen op een bedrijfsnetwerk. Alle drie de richtlijnen adviseren reguliere wachtwoordwisselingen en het bijhouden van oude wachtwoorden om te voorkomen dat steeds dezelfde wachtwoorden gebruikt worden. De ISO 27002 adviseert nog extra om gebruikers te adviseren om verschillende wachtwoorden voor business en non-business toepassingen te gebruiken. Alle drie de normen bieden maatregelen tegen wachtwoordhergebruik, die met grote waarschijnlijkheid hier niet zijn toegepast. Een mogelijke reden hiervoor is dat Facebook een bedrijf is die als businessmodel heeft, het verkopen van marktgegevens en het tonen van advertenties. Dit kan er voor zorgen dat gebruiksvriendelijkheid meer prioriteit krijgt dan beveiliging.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
ja
ja
ja
4.
42 miljoen wachtwoorden gestolen bij inbraak datingsite [4]. Twee zwakheden met betrekking tot wachtwoordbeveiliging zijn hieruit te extraheren: wachtwoorden werden opgeslagen in klare tekst en gebruikers kozen eenvoudig te raden wachtwoorden. Zie incident 1 en 2 voor opslag van wachtwoorden en keuze van wachtwoorden door gebruikers.
19
5.
GitHub reset wachtwoorden na brute force-aanval [5]. Hierbij zijn een beperkt aantal zwakke wachtwoorden op alle accounts geprobeerd door een aanvaller, ervan uitgaande dat er altijd wel een paar gebruikers zijn met een zeer eenvoudig wachtwoord. Alleen de ISO 27002 heeft hiervoor een maatregel: adviseer de gebruiker om geen wachtwoorden te kiezen die eenvoudig te raden zijn. Deze maatregel is echter niet sterk, omdat het af hangt van het gedrag van eindgebruikers.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
deels, door gebruikers te adviseren sterke wachtwoorden te kiezen
nee
ja, door een controle op triviale wachtwoorden
6.
Klantendatabase goksite Racing Post gestolen [6]. Door een kwetsbaarheid in de webapplicatie is de inhoud van de achterliggende database gestolen en daarmee ook de (versleutelde) wachtwoorden. Dit incident betreft het uitlekken van one-way versleutelde wachtwoorden. Deze manier van opslaan van wachtwoorden is conform alle drie de richtlijnen. Diverse nieuwsartikelen op internet (oa op de website TheCyberSecuritySentinel [25]) suggereren dat er gebruik gemaakt is van Rainbow Tables5 om de wachtwoorden te kraken. De maatregelen hiertegen is het gebruik van z.g. salt bij het hashen van de wachtwoorden. Alleen de OWASP adviseert dit in de Password Storage Cheat Sheet.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
nee, geen maatregelen tegen aanvallen met rainbow tables
nee, geen maatregelen tegen aanvallen met rainbow tables
Ja, OWASP adviseert het gebruik van salt tegen een aanval met rainbow tables.
7.
Microsoft: Europarlementariërs niet gehackt via Exchange-lek [7]. Dit bericht verwijst naar het onderscheppen van wachtwoorden door een zogenaamde man-in-the-middel-aanval op een open WiFi internetverbinding. De onderkende kwetsbaarheid is hier afluisteren, terwijl het wachtwoord over het netwerk wordt getransporteerd. Alle drie de richtlijnen dekken dit af doordat wordt aangereaden om wachtwoorden niet in klare tekst te versturen over een netwerk, maar een communicatie met encryptie te kiezen.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
ja, middels encryptie op netwerk niveau
ja, middels encryptie op netwerk niveau
ja, middels encryptie op netwerk niveau
8. 9.
Forbes-personeel gebruikte zeer zwakke wachtwoorden [8]. Dit is opnieuw een voorbeeld waarbij gebruikers eenvoudig te raden wachtwoorden kiezen, zie incident 2. Malware steelt 600 wachtwoorden van Duitse overheid [9]. Het betreft hier malware, dat de logingegevens inclusief wachtwoorden afvangt en doorstuurt naar kwaadwillenden. Alle drie de richtlijnen bevatten algemene maatregelen tegen malware.
ISO 27001 / ISO 27002
PCI-DSS
OWASP
ja, met algemene maatregelen tegen malware
ja, met algemene maatregelen tegen malware
ja, met algemene maatregelen tegen malware
Een rainbow table is een tabel met daarin een groot aantal potentiele wachtwoorden samen met de hashwaarde die daar bij hoort. Het wachtwoord in klare tekst kan dan vervolgens worden gevonden door de hashwaarde op te zoeken in een tabel. 5
20
10. Amazon-app liet aanvaller onbeperkt wachtwoorden proberen [10]. Dit betreft een fout in het loginmechanisme waardoor het z.g. account lockoutmechanisme niet werkte. Alle drie de richtlijnen eisen dat een gebruikersaccount wordt vergrendeld na een aantal inlogpogingen met een fout wachtwoord. ISO 27001 / ISO 27002
PCI-DSS
OWASP
ja, door een account lockout maatregel
ja, door een account lockout maatregel
ja, door een account lockout maatregel
Bovenstaande kunnen we samenvatten in een tabel met daarin de mate waarin het incident voorkomen zou zijn in het geval de maatregelen uit verschillende richtlijnen adequaat zouden zijn geïmplementeerd: Incident
Risico / kwetsbaarheid / oorzaak:
ISO 27001 / ISO 27002
PCI-DSS
OWASP
1,4
Zwakke wachtwoord opslag
deels
deels
ja
2,4,8
Gebruikers kiezen eenvoudig te raden wachtwoorden
deels
deels
ja
3
Wachtwoordhergebruik
ja
ja
ja
5
Aanval met enkele wachtwoorden op vele accounts
deels
Nee
ja
6
Zwakke wachtwoordopslag / geen salting gebruikt
nee
nee
ja
7
Onveilig transport over netwerk
ja
ja
ja
9
Malware
ja
ja
ja
10
Account lockout mechanisme
ja
ja
ja
7.3 In welke mate worden de risico’s afgedekt door maatregelen uit richtlijnen? Per risico, onderkend in hoofdstuk 6, zijn maatregelen geselecteerd uit de drie richtlijnen. Het eindresultaat van deze inventarisatie is te vinden in bijlage A. Deze inventarisatie is gedaan om inzicht te krijgen waarom de maatregelen in de normen staan en geeft antwoord op de vraag “welke maatregelen reiken de normen aan om een bepaald risico te mitigeren”. Dit is gedaan om het selecteren van maatregelen vanuit een risicoanalyse te ondersteunen. Wanneer bijvoorbeeld het risico op het uitlekken van wachtwoorden via een keylogger als een realistisch scenario wordt gezien, dan kan in het raamwerk worden opgezocht welke maatregelen daar tegen kunnen helpen. Er is hierbij onderscheid gemaakt tussen preventieve en detectieve maatregelen omdat elke maatregel nu eenmaal kan falen en een detectieve maatregel kan er dan voor kan zorgen dat het opgemerkt wordt en er correctieve handelingen gedaan kunnen worden. Na analyse van bijlage A komen de volgende punten naar voren:
De onderzochte richtlijnen geven nauwelijks inzicht in welk risico ze beogen af te dekken. Dit kan er toe leiden dat er bij het selecteren van maatregelen meer op gevoel geselecteerd wordt dan op basis van onderkende risico’s.
21
Mitigerende maatrelen tegen een aanval waarbij een beperkt aantal wachtwoorden wordt geprobeerd op alle of een groot aantal gebruikers-accounts is niet onderkend. De normen bieden nauwelijks detectieve maatregelen, die specifiek gericht zijn om de effectiviteit van maatregelen te waarborgen. Omdat de ISO 27001/2 en de PCI-DSS minder specifiek zijn, is de kwaliteit van de risicoanalyse en de selectie van maatregelen sterk afhankelijk van de kennis en kunde van de mensen die het uitvoeren. De OWASP richtlijnen zijn daarom een waardevolle aanvulling om zaken concreter in te vullen. Voorbeelden hiervan zijn: - wachtwoordopslag. - beveiliging van de applicatielaag tegen het stelen van wachtwoorden - encryptie van wachtwoorden terwijl ze over het netwerk verstuurd worden. Er zijn slechts algemene maatregelen tegen: - het plaatsen van hardware keyloggers en mini camera’s - het vervangen van wachtwoorden door bij de aanvaller bekende wachtwoorden met behulp van social-engineering technieken. De OWASP richtlijnen zijn overigens niet op alle punten consistent, vooral op het onderwerp minimale wachtwoordlengte, welke van 8 t/m 16 voor komt in de verschillende OWASP documenten. Tegen de aanval waarbij een beperkt aantal eenvoudige wachtwoorden op alle accounts geprobeerd wordt hebben de ISO 27001/2 en PCI-DSS relatief zwakke maatregelen. De OWASP heeft als enige maatregelen hiertegen in de Developer Guide. De ISO 27001/2 bieden geen maatregelen tegen een denial of service attack, door het account lockoutmechanisme te misbruiken.
22
8 Aanvullingen en nuances Dit hoofdstuk geeft antwoord op de deelvraag “Hoe kunnen de bestaande richtlijnen nog verder worden verbeterd, specifiek op het onderwerp wachtwoordauthenticatie?”. In het vorige hoofdstuk zijn de drie verschillende richtlijnen geanalyseerd op het onderwerp wachtwoordauthenticatie en zijn deze gestructureerd naar de risico’s en dreigingen onderkend in hoofdstuk 6 “Risico’s bij wachtwoordauthenticatie“. Hieronder worden een aantal aanvullingen op de drie onderzochte richtlijnen voorgesteld met als doel de risico’s ten aanzien van wachtwoordauthenticatie beter te kunnen mitigeren. Ook worden er enkele nuances gedaan op maatregelen uit de richtlijnen. De aanvullingen en nuances zijn primair afkomstige uit eigen onderzoek door wetenschappelijke stukken, literatuur en publicaties op internet te onderzoeken aangevuld met de praktijkkennis van de schrijver van de scriptie. Deze aanvullingen en nuances zijn vervolgens getoetst bij drie andere specialisten uit de praktijk. De structuur is dezelfde als die in bijlage A, zodat het uiteindelijk een geconsolideerd raamwerk gemaakt kan worden. Het raamwerk is getoetst bij de volgende specialisten: Koc-Fai Wu (RE), Cyber Security Specialist, ING Bank Jeroen Kunis (RE), senior IT audit manager, KPMG Johan Verrips, senior security architect, Nationale Nederlanden
8.1 Aanvullingen en nuances op de drie onderzochte richtlijnen Risico 1: Wachtwoorden vallen in handen van een derde oorzaak
Aanvullende maatregelen en nuances
a) Ineffectieve processen voor wachtwoord uitgifte / reset ten aanzien van identificatie. b) Social-engineering of handelen van de gebruiker.
Preventief:
Leg de gebruikers uit hoe ze wachtwoorden willekeurig kunnen genereren en veilig kunnen op slaan, bijvoorbeeld door gebruik te maken van wachtwoord-kluis software. (JV). Dwing het wachtwoordbeleid, zoals minimale wachtwoordlengte en complexiteit, technisch af. (NK, bevestigd door specialisten) Weiger triviale wachtwoorden. Dit om eenvoudig te raden wachtwoorden zoals “Password01” en “Welkom01” te mijden. Het is bij de trivialiteitscontrole belangrijk dat ook gecontroleerd wordt op permutaties van woorden in de woordenlijst, want dat gebruiken aanvallers ook. Bij ING staat de trivialiteitscontrole als eis in het informatiebeveiligingsbeleid. (JV) Creëer een situatie dat het voldoen aan regels rond het gebruik van wachtwoorden ook echt mogelijk is. Zorg er daarom voor dat het nooit nodig is een wachtwoord door te geven aan een ander. (JK). Filter phishing emails weg nog voordat ze eindgebruikers bereiken. (NK, bevestigd door specialisten). Nuance op het ISO 27002 eis om wachtwoorden nooit leesbaar op het scherm te tonen: Een aantal artikelen op de website van Smashing Magazine [26] en ZDNet [27] suggereren dat wanneer gebruikers hun wachtwoord kunnen zien bij het kiezen van een nieuw wachtwoord en bij het inloggen, dat zij dat langere, complexere en daardoor betere wachtwoorden kiezen. Ook claimen de artikelen dat wachtwoorden dan minder vaak worden vergeten. Windows 8 is een voorbeeld van software
23
dat dit heeft ingevoerd. (NK, werd door de specialisten als plausibel bestempeld). Detectief:
c) Een hardware/software keylogger of camera.
Reguliere surveillance op rondslingerde briefjes met wachtwoorden erop. Deze maatregel werkt ook preventief. (NK, bevestigd door specialisten). Reguliere controles op het onveilig digitaal opslaan van wachtwoorden. (NK, bevestigd door specialisten). Proberen wachtwoordhashes te kraken met speciale cracking tools om eenvoudige wachtwoorden te detecteren (NK). Deze methode is beschreven in een paper van Matt Bischop “Improving System Security via Proactive Password Checking” [28]. Echter, twee van de drie specialisten zien deze als te complex, te specialistisch en daardoor niet haalbaar. Ook zien dezelfde twee specialisten dit als een te groot risico dat de gekraakte wachtwoorden uitlekken juist door deze maatregel.
Detectief:
Reguliere controles op verdachte apparatuur en in het bijzonder keyloggers en minicamera’s. (NK, bevestigd door specialisten) Creëer opmerkzaamheid bij gebruikers voor veranderingen in de apparatuur en in het bijzonder voor keyloggers en minicamera’s. Moedig aan om dit te melden bij de IT organisatie. (NK, bevestigd door specialisten)
d) Een hacker of kwaadaardige software steelt de wachtwoorden of wachtwoordhashes.
Preventief:
e) Een hacker kraakt de wachtwoordhashes nadat hij het systeem gecompromitteerd heeft.
Preventieve maatregelen:
JV benadrukt dat het gebruik van een separate authenticatieserver een pré is, omdat de kans dat wachtwoordhashes uitlekken kleiner is doordat deze niet de applicatiesystemen aanwezig zijn. Ook hoeven gebruikers minder verschillende wachtwoorden onthouden omdat er dan gebruik gemaakt kan worden van z.g. Single Sign On. Dit gaat nadrukkelijk niet over wachtwoordsynchronisatie, waarbij wachtwoorden vanuit een centraal systeem worden gedistribueerd naar andere systemen. Dit zorgt voor een averechts effect: wanneer één van de systemen gecompromitteerd is, dan zijn alle systemen in gevaar.
Lange, complexe wachtwoorden afdwingen. Echter, wanneer men te stringente eisen stel heeft dit diverse nadelen zoals: - lange, complexe wachtwoorden worden vaker onveilig opgeslagen. Bron: Gartner [29]. - minder gebruiksvriendelijk. Merk op dat wachtwoorden langer moeten zijn indien de beoogde aanvaller over meer rekenkracht beschikt en/of de wachtwoorden opgeslagen zijn met een zwakke hashfunctie. Weigeren triviale wachtwoorden. De richtlijnen stellen al voor om wachtwoordwijzigingen regelmatig af te dwingen. Het doel van deze maatregel is om ervoor te zorgen dat een wachtwoord wordt gewijzigd, vóórdat een wachtwoord door brute-
24
force6 wordt gekraakt. Nuance: wanneer een slimmere en daardoor snellere methode wordt gekozen, zoals een aanval met wachtwoordlijsten dan kan het wachtwoord toch gekraakt worden voordat het gewijzigd is. Daarom is het voorkomen van triviale wachtwoorden van het grootste belang. (NK). Detectief:
f) Wachtwoorden worden afgeluisterd wanneer ze over het netwerk worden verstuurd.
Detectief:
g) Online guessing
Regulier controleren op wachtwoorden in klare-tekst op systemen. Klare tekst wachtwoorden kunnen o.a. voorkomen in bestanden, in een database of in een technisch component zoals een router of firewall. Zie ook SANS’ “Passwords are everywhere” [30] om een beeld te krijgen waar wachtwoorden in klare tekst kunnen voorkomen. (NK, bevestigd door specialisten). Op reguliere basis of steekproefsgewijs de wachtwoordhashes van systemen bekijken en controleren of dit sterke hashes zijn. Extra aandacht behoeven systemen die wachtwoorden op slaan op verschillende manieren. Een voorbeeld is Oracle, dat is overgestapt op een sterker hashingalgoritme, maar het oude is vaak ook nog actief. (NK, bevestigd door specialisten). Network security monitoring, detectie op wachtenwoorden in klaretekst. Vooral applicatieprotocollen uit de begintijd van internet zijn berucht, zoals telnet en ftp (NK, bevestigd door specialisten). Reviews op gebruikte netwerk encryptie. (NK, bevestigd door specialisten).
Preventief:
Als aanvulling op de account lockout eisen van de drie normenkaders: NK: Er zou overwogen kunnen worden om het aantal pogingen dat gedaan kan worden voordat het gebruikersaccount vergrendeld op te hogen naar bijvoorbeeld 10. Uit een onderzoek uit 2003 [31] “Ten strikes and you're out”: Increasing the number of login attempts can improve password usability” blijkt dat bij het opschroeven van het blokkeren na 10 foute loginpogingen in plaats van 3 foute loginpogingen, het aantal gelockte accounts met 44% af neemt. Dit heeft als voordeel minder irritatie voor de eindgebruiker en minder belasting voor de helpdesk. Een andere overweging is het verwijderen van de lockout door een automatisch mechanisme dat na een bepaalde tijd het gebruikersaccount weer vrij geeft. Dit is minder arbeidsintensief dan handmatig unlocken. Wanneer de tijd voordat een gebruikersaccount automatisch wordt ontgrendeld steeds wordt verdubbeld of exponentieel oploopt, dan is het extra risico beperkt. Om een DOS aanval te voorkomen moeten de loginnamen confidentieel behandeld worden en eenvoudig te voorspellen zijn (NK, bevestigd door de specialisten). Zorg ervoor dat voor alle manieren van inloggen een blokkeringsmechanisme actief is. Een recent voorbeeld is de Amazonapp, dat inlogt in de back-office van Amazon. Wanneer op die manier wordt ingelogd op de back-office was er tijdelijk geen lockout mechanisme actief, zie inleiding. Weiger triviale wachtwoorden.
Bij een brute-force aanval op wachtwoorden wordt systematisch alle combinaties van mogelijke wachtwoorden afgelopen. (bijvoorbeeld: a,b,c,d,e etc. en daarna ab,ac,ad,ae etc tot dat het juiste wachtwoord gevonden wordt. ) 6
25
h) Een derde vind het wachtwoord door een enkele eenvoudige wachtwoorden te proberen op alle of een groot aantal gebruikersaccounts.
Preventief:
Behandel loginnamen confidentieel. (NK, bevestigd door de specialisten). Weiger triviale wachtwoorden. (NK, bevestigd door de specialisten). Het gebruik van een separate authenticatieserver kan het eenvoudiger maken om login-namen confidentieel te houden. Afhankelijk van de gekozen authenticatieserver, is het eenvoudiger danwel lastiger de login-namen confidentieel te houden. Dit zou dus een selectiecriteria kunnen zijn bij de keuze voor een authenticatieserver.
Detectief:
Monitoring op het totaal aantal foute login-pogingen voor alle gebruikersaccounts per tijdseenheid. (NK, bevestigd door specialisten).
i) Een derde steelt de wachtwoorden of wachtwoordhashes van backup-media.
Risico 2: Wachtwoorden van niet-persoonsgebonden accounts blijven bekend bij personen, terwijl dat niet (meer) hoort bij hun taken en verantwoordelijkheden oorzaak
Aanvullende maatregelen en nuances
a) Een wachtwoord van een niet-persoonsgebonden account is niet gewijzigd nadat iemand het team verlaat of ander werk gaat doen.
Preventief:
De beheerorganisatie zou moeten eisen dat alle niet persoonsgebonden accounts wijzigbaar zijn, ook nadat het systeem in productie is genomen. Hiervoor zou een geteste procedure opgeleverd moeten worden. (JV). Bij overdracht van project naar beheerorganisatie worden alle niet persoonsgebonden accounts gewijzigd d.m.v. bovengenoemde procedure. (JV)
Detectief:
Controleer enige tijd na overgang van project naar beheerorganisatie (bv 2 weken na oplevering), of er geen wachtwoorden in het systeem aanwezig zijn die bij in beheer name niet gewijzigd zijn. In veel systemen is dit uit te lezen. Wanneer het niet uit te lezen valt, dan kan worden geleund op de registratie van de uitgevoerde changes of andere registratie waaruit dat blijkt. (JV)
b) Standaard wachtwoord is niet gewijzigd
Risico 3: Wachtwoorden worden vervangen door een bij een andere persoon bekend wachtwoord oorzaak
Aanvullende maatregelen en nuances
a) Ondeugdelijke wachtwoordresetprocedures.
Detectief:
26
b) Wachtwoorden of wachtwoordhashes zijn onvoldoende beschermd tegen ongeautoriseerd wijzigen.
Review op reguliere basis of de procedures voor wachtwoorduitgifte en wachtwoordreset worden nageleefd. De “Forgot Password Cheat Sheet” [32] kan hierbij als norm voor het review dienen. (NK, bevestigd door specialisten)
Preventief
Zorg dat de integriteit van de opslag van wachtwoorden of wachtwoordhashes niet aangetast kan worden. M.a.w. zorg dat bestanden of velden in een database waar wachtwoorden of wachtwoordhashes zijn opgeslagen niet wijzigbaar zijn voor ongeautoriseerde personen. Dit kan o.a. bereikt worden door het instellen van de juiste autorisaties op de informatie en de algehele beveiliging van het systeem, wat hier buiten de scope valt. (NK, bevestigd door specialisten). Gebruik een separate authenticatieserver. Een separate authenticatieserver kan helpen de wachtwoorden te beschermen tegen ongeautoriseerd wijzigen omdat de wachtwoorden dan gecentraliseerd zijn in één systeem in plaats dat de wachtwoorden op verschillende plaatsen zijn opgeslagen.
Detectief:
c) Social-engineering. Hierbij wordt de gebruiker verleid om zijn wachtwoord te veranderen op aangeven van de aanvaller.
Voer reguliere reviews uit de beveiliging van systemen en in het bijzonder op de autorisaties (ACL’s7) van opgeslagen wachtwoordhashes. (NK, bevestigd door de specialisten)
Preventief:
Maak gebruikers bewust van de mogelijkheid dat iemand ze zou kunnen proberen over te halen hun wachtwoord te veranderen in een aangegeven wachtwoord. (NK, bevestigd door specialisten).
d) Een kwaadwillende wijzigt het wachtwoord door misbruik te maken van een werkstation of mobiel apparaat waarop de legitieme gebruiker is ingelogd. e) Wanneer een beheerder de wachtwoord-hash (tijdelijk) vervangt door een wachtwoord-hash die bij hem bekend is, dan kan hij ongeautoriseerd inloggen met dat account.
Detectief:
Loggen en monitoren van wijzigingen in de wachtwoord-opslag. (NK, bevestigd door specialisten) Gebruik een separate authenticatieserver. Het gebruik van een separate authenticatieserver onder beheer van een separaat team (bv security administrators) zou kunnen voorkomen dat beheerders wachtwoorden (tijdelijk) aanpassen.
Risico 4: Wachtwoorden die eenmaal gecompromitteerd zijn, worden lange tijd misbruikt oorzaak
Aanvullende maatregelen en nuances
ACL = access control list. Hiermee stel je de autorisaties in op bijvoorbeeld een bestand of op een record of veld in een database. 7
27
a) wachtwoorden blijven lange tijd hetzelfde doordat wachtwoordwijzigingen niet worden afgedwongen
Detectief:
Detecteer met security monitoring logins vanaf ongebruikelijke plekken met securitymonitoring. (NK, bevestigd door specialisten).
b) de gebruiker het uitlekken van zijn wachtwoord niet meldt en geen actie neemt. c) de gebruiker gebruikt opvolgende wachtwoorden waardoor het volgende wachtwoord steeds voorspelbaar is.
Preventief:
Weiger opvolgende wachtwoorden (NK, bevestigd door specialisten). Dit kan gerealiseerd worden door permutaties van het nieuwe wachtwoord te toetsen aan de wachtwoordhistorie. De wachtwoordhistorie bevat de wachtwoordhashes van eerder gebruikte wachtwoorden.
Risico 5: Iemand wordt ten onrechte niet geauthentiseerd op een informatiesysteem oorzaak
Aanvullende maatregelen en nuances
a) De authenticatieserver is niet beschikbaar. b) De integriteit van de wachtwoordopslag (c.q. wachtwoordhashes) is aangetast
Detectief:
c) Het account is vergrendeld doordat het lockoutmechanisme wordt misbruikt voor een z.g. Denial of Service (DOS) aanval. Hierbij worden accounts moedwillig geblokkeerd door meerdere malen achter elkaar een fout wachtwoord te gebruiken.
Preventief:
Bewaken integriteit van bestanden van het besturingssysteem. (NK, bevestigd door de specialisten). Gebruik een separate authenticatieserver en maak gebruik van standaard software (bv Active Directory). Dit kan de kans op problemen met de integriteit van de wachtwoordhashes voorkomen omdat deze software reeds uitvoerig getest is door de fabrikant en in productie bij andere klanten. Kies willekeurig gekozen loginnamen en houdt deze geheim. Wachtwoordkluissoftware heeft vaak een functie om willekeurige wachtwoorden te genereren. (JV, ING). Richt de vergrendeling zo in dat de vergrendeling alleen geldt voor het netwerkadres (ip-adres) dat de blokkering veroorzaakt heeft. Dit om Denial Of Service (DOS) aanval te voorkomen. Dit is alleen aan te raden op geïsoleerd bedrijfsnetwerk, dus niet voor systemen die aan internet gekoppeld zijn omdat op internet botnets8 actief zijn die vanaf vele verschillende netwerk-adressen actief zijn. (KW) Overweeg gebruikersaccounts van beheerders niet te voorzien van een blokkeringsmechanisme, maar van een beveiliging op netwerkniveau. Dit laatste om uitsluiting van systeembeheerders te voorkomen. (KW).
Analyse: Wanneer we de aanvullingen en nuances in ogenschouw nemen, dan vallen de volgende zaken op:
Een botnet is een groot aantal gecompromitteerde computers die vanaf één centrale plek worden bestuurd door een kwaadwillende. 8
28
Bepaalde maatregelen zijn op meerdere fronten effectief omdat ze meerdere oorzaken van risico’s afdekken. Enkele voorbeelden: - Het weigeren van triviale wachtwoorden verkleind de kans dat oorzaken 1b, e, g en h optreden. - Het gebruik van een separate authenticatieserver verkleind de kans dat oorzaak oorzaak 1d en h, 3 b en e en 5b optreden. Er zijn bij de meeste oorzaken van risico’s detectieve maatregelen toegevoegd om te kunnen monitoren of bepaalde onderkende oorzaken zich voordoen. Enkele nuances zijn gemaakt op wachtwoordlengte en complexiteit, account lockout mechanisme en het tonen van wachtwoorden op het scherm van de gebruiker. Er zijn geen aanvullende maatregelen tegen samenspanning, bedreiging en omkoping.
8.2 In welke mate hadden de aanvullingen en nuances de incidenten kunnen voorkomen? In hoeverre kunnen nu de aanvullingen en nuanceringen uit het vorige paragraaf er voor zorgen dat de incidenten niet of minder voorkomen? Hieronder is een inschatting gemaakt per incident. In totaal zijn 9 issues uit de 11 incidenten geëxtraheerd, die hieronder staan opgesomd. Per issue is een inschatting gemaakt in hoeverre het incident afgedekt is door de aanvullingen en nuances. Incident
issue
Risico
Risico afgedekt door aanvullingen en nuances:
1,4
Wachtwoorden worden gestolen en daarna gekraakt
1de
Ja, bij gebruik van een separate authenticatieserver.
2,4,8
Gebruikers kiezen eenvoudig te raden wachtwoorden
1b
Ja, door de controle op triviale wachtwoorden meer naar voren te brengen, die al genoemd is in OWASP’s Developer Guide.
3
Gebruikers hergebruiken wachtwoorden over verschillende systemen, ook buiten de organisatie.
1b
Nee. De onderzochte standaarden dekken dit al deels af door het afdwingen van wachtwoordwijzigingen en een minimale wachtwoordlengte en complexiteit aangevuld met awareness programma’s.
5
Aanval met enkele wachtwoorden op vele accounts
1g
Ja, afgedekt door aanvullende maatregelen als het confidentieel behandelen van loginnamen en het weigeren van triviale wachtwoorden.
6
Kwetsbare applicatie, buiten de scope.
7
Onveilig transport over netwerk, sniffing
1f
Was al afgedekt door de onderzochte richtlijnen, als aanvulling kunnen detectieve maatregelen worden ingericht.
29
9
Malware steelt wachtwoorden in klare tekst
1d
Het betreft hier een aanval aan de client-kant. Geen aanvullingen of nuances.
10
Account lockout mechanisme
1
Was al afgedekt door de drie onderzochte richtlijnen. Hier is wel een nuance gemaakt ten gunste van kosten en gebruiksvriendelijkheid.
30
9 Het toetsen van de effectiviteit van wachtwoordauthenticatie Het doel van deze scriptie is het management van organisaties hulpmiddelen aan te reiken waarmee de effectiviteit van wachtwoordauthenticatie kan worden getoetst. In hoofdstuk 5.5 is bepaald dat een effectieve wachtwoordauthenticatie de volgende eigenschappen heeft:
Kleine kans op een geslaagde ongeautoriseerde login op een informatiesysteem. Kleine kans op het onterecht buitensluiten. Gebruiksvriendelijkheid.
Kleine kans op een geslaagde ongeautoriseerde login / kleine kans op onterecht uitsluiten. Om de eerste twee items van effectiviteit af te dekken, kan het geïntegreerde normenkader gebruikt worden in combinatie met een algemene audit-aanpak: 1) Inventarisatie van de organisatiedoelen. 2) Risico analyse. Het doel van deze stap is het bepalen of specifieke risico’s van wachtwoordauthenticatie ook een risico voor de organisatie vormen. De onderkende risico’s van wachtwoordauthenticatie uit hoofdstuk 6 kunnen daarbij helpen. 3) Beoordelen van de opzet van risicomitigatie. Hierbij wordt geïnventariseerd welke maatregelen er zijn geïmplementeerd om de specifiek wachtwoordauthenticatierisico’s uit stap 2 te mitigeren. De maatregelen uit de drie onderzochte richtlijnen in bijlage A, samen met de aanvullingen en nuanceren uit hoofdstuk 8 kunnen helpen om de inventarisatie compleet te krijgen. Vooral de mogelijke oorzaken van de risico’s en de mogelijke mitigerende maatregelen daarvoor zijn bruikbaar hiervoor. 4) Bepalen van de effectiviteit van de maatregelen. De aanpak hierbij hangt sterk af van de soort maatregel. Algemene auditmethoden, zoals het opvragen van inlichtingen en bewijsstukken en het doen van interviews, kunnen hier ingezet worden. 5) Per risico beoordelen of het pakket van maatregelen het risico adequaat afdekken. Gebruiksvriendelijkheid Het item gebruiksvriendelijkheid hangt voor een groot deel af van het doel van het informatiesysteem. Daarom is gekozen om dit te behandelen aan de hand van een drietal voorbeelden:
De eigenaar van het systeem heeft als doel zoveel mogelijk advertentie-inkomsten te vergaren, zoals Facebook. Het is dan van belang dat gebruikers altijd op een eenvoudige manier kunnen inloggen. Beveiliging is daarbij een secundair doel om imagoschade te voorkomen. Bij een internetbankieren-applicatie is het doel klanten de mogelijkheid te geven om digitaal zijn transactiegegevens in te zien en betaaltransacties te initiëren. Hierbij is gebruiksvriendelijkheid belangrijk vanwege de diversiteit van de doelgroep en een sterke beveiliging is ook belangrijk om fraude en imagoschade te voorkomen. In het geval van een militair informatiesysteem, voor het uitwisselen van gegevens in oorlogstijd, is het doel veilig kunnen communiceren. Het authenticatiemechanisme zal hier dus zeer sterk moeten zijn en dat mag deels ten koste gaan van de gebruiksvriendelijkheid omdat het defensiepersoneel doorgaans specifieke trainingen krijgt voor het gebruik van het informatiesysteem.
In hoeverre gebruiksvriendelijkheid een bepalende factor is, hangt dus erg af van de situatie. Omdat het implementeren van risico-beperkende maatregelen er voor kan zorgen dat het systeem minder gebruiksvriendelijk wordt, zal altijd een afweging gemaakt moeten worden. Omdat ook dit situatiespecifiek is, zijn hieronder een aantal overwegingen ten aanzien van het implementeren van maatregelen: Wachtwoordkeuze / inloggen Wanneer een gebruiker een nieuw wachtwoord moet invoeren, kan dat een frustrerende bezigheid zijn indien vele malen het wachtwoord wordt geweigerd. Het wachtwoordbeleid, zoals minimale lengte; 31
complexiteit; geen woordenboek-woord en het wachtwoord mag niet al eerder gebruikt zijn, kan hiervan de oorzaak zijn. Een wachtwoordresetprocedure waarbij de gebruiker naar de servicedesk moet bellen om het gebruikersaccount weer bruikbaar te maken, kan ook als ongebruiksvriendelijk worden ervaren. Volgens een onderzoek van Gartner [29], kan een stringent wachtwoordbeleid zelfs het risico dat een wachtwoord in handen van een derde valt verhogen, omdat de kans dat een wachtwoord wordt opgeschreven groter is. Account lockoutmechanisme Het lockoutmechanisme treedt in werking na een aantal mislukte loginpogingen en leidt tot een (tijdelijk) blokkade van het gebruikersaccount. Dit is een maatregel tegen online guessing. Wanneer het blokkeren echter al na een beperkt aantal mislukte pogingen optreedt, dan kan dat worden ervaren als minder gebruiksvriendelijk. Uit een onderzoek uit 2003 “Ten strikes and you're out”: Increasing the number of login attempts can improve password usability” [31] blijkt dat bij het opschroeven van het blokkeren van 3 foute loginpogingen naar 10 foute loginpogingen, het aantal gelockte accounts met 44% af neemt. Dit heeft als voordeel minder irritatie voor de eindgebruiker en minder belasting voor de helpdesk. Het nadeel van het ophogen van het aantal pogingen is dat de kans op een succesvolle online guessing aanval ongeveer drie keer zo groot wordt. Het aspect gebruiksvriendelijkheid zal bij de keuze welke mitigerende maatregelen worden getroffen en hoe die maatregelen geïmplementeerd gaan worden, een belangrijke rol spelen om ervoor te zorgen dat het systeem bruikbaar blijft voor de doelen waarvoor het gebouwd is.
32
10 Conclusies en samenvatting Incidenten met wachtwoorden komen regelmatig voor en zijn vaak in de media te lezen. Veel voorkomende incidenten leiden tot ongeautoriseerde toegang tot informatiesystemen door het uitlekken van wachtwoorden; wachtwoordhergebruik en de keuze van gebruikers voor eenvoudig te raden wachtwoorden. Gezien de vele incidenten is er de verwachting dat er behoefte is bij IT-managers en riskmanagers om de effectiviteit van wachtwoordauthenticatie te toetsen. Wachtwoordauthenticatie is het verifiëren van een gebruiker van een informatiesysteem. Deze gebruiker kan een mens of machine zijn. In deze scriptie noemen we wachtwoordauthenticatie effectief wanneer de risico’s beheerst worden en het daarnaast ook gebruiksvriendelijk is. De richtlijnen ISO 27001/ISO 27002, PCI-DSS en OWASP cheat sheets bieden voor het aspect risicobeheersing een aantal maatregelen. Aan de hand van een aantal recente incidenten zijn de richtlijnen geanalyseerd en bleek dat de richtlijnen voor alle incidenten mitigerende maatregelen bevatten. Het werd duidelijk dat de ISO 27001/27002 en PCI-DSS onvoldoende diepgang bieden om de incidenten te voorkomen. Voor 7 van de 11 onderzochte incidenten geldt, dat deze niet of slechts gedeeltelijk door de ISO27001/27002 en PCI-DSS worden afgedekt. De OWASP was nodig om maatregelen aan te dragen om de laatste 7 incidenten te kunnen voorkomen. De OWASP is dus een waardevolle toevoeging. Om het aspect risicobeheersing volledig in beeld te kunnen krijgen, is een raamwerk opgesteld dat uitgaat van een vijftal risico’s ten aanzien van wachtwoordauthenticatie. De onderkende risico’s zijn: Risico 1: Wachtwoorden vallen in handen van een derde Risico 2: Wachtwoorden van niet-persoonsgebonden accounts blijven bekend bij personen, terwijl dat niet (meer) hoort bij hun taken en verantwoordelijkheden Risico 3: Wachtwoorden worden vervangen door een bij een andere persoon bekend wachtwoord Risico 4: Wachtwoorden die eenmaal gecompromitteerd zijn, worden lange tijd misbruikt Risico 5: Iemand wordt ten onrechte niet geauthentiseerd op een informatiesysteem Aan elk risico zijn maatregelen uit de onderzochte richtlijnen gekoppeld. Vervolgens is, waar nodig, door eigen onderzoek het raamwerk uitgebreid om de onderkende risico’s beter te mitigeren. Het resultaat daarvan is getoetst bij een 3-tal specialisten uit de praktijk. Dit heeft geleid tot een aantal aanvullingen en nuances op de bestaande richtlijnen. Belangrijke aanvullingen zijn: detectieve maatregelen in het algemeen, de inzet van een separate authenticatieserver; meer nadruk op het voorkomen van triviale wachtwoorden en op specifieke dreigingen zoals keyloggers; camera’s; Denial of Service aanvallen en phishing. Ook zijn er meer specifieke maatregelen toegevoegd tegen een aanval door een klein aantal eenvoudige wachtwoorden op elke gebruikersaccount te proberen. Op organisatorisch niveau zijn er maatregelen toegevoegd voor de overgang van project naar beheersorganisatie. Verder zijn er nuances aangebracht op minimale wachtwoordlengte, de frequentie van wachtwoordwijzigingen en het account lockoutmechanisme. Wanneer we kijken naar de onderzochte incidenten dan zijn de aanvullingen: separate authenticatieserver; voorkomen van triviale wachtwoorden en gebruik van confidentiële gebruikersaccounts waardevolle toevoegingen. Het aspect gebruiksvriendelijkheid is van belang, omdat wanneer het niet gebruiksvriendelijk is, er manieren gezocht en gevonden gaan worden om maatregelen te omzeilen of anderzijds ineffectief te maken. Het is daarom belangrijk om maatregelen te selecteren die een juiste balans vinden tussen gebruiksvriendelijkheid en veiligheid. Een belangrijke factor is het businessdoel van het systeem en de gegevens en de risico’s die gelopen worden. Een toetsing op een specifieke implementatie van wachtwoordauthenticatie kan plaats vinden door te beoordelen of specifieke risico’s zijn afgedekt en of voldoende rekening wordt gehouden met de gebruiksvriendelijkheid. Deze scriptie levert een aanpak en een hulpmiddel voor het bepalen van risico’s door een vijftal inherente risico’s van wachtwoordauthenticatie aan te reiken en daaraan gekoppeld de 33
maatregelen uit een drietal richtlijnen, aangevuld met verbeteringen en nuances. Het is daarbij belangrijk te realiseren dat een raamwerk geen specifieke risico’s afdekt en ook geen rekening kan houden met specifieke eisen en wensen.
34
11 Reflectie Bij de totstandkoming van deze scriptie ben ik eerst diep op de inhoudelijk stof ingegaan. Wat ik daaruit geleerd heb, is hoe ik wetenschappelijke stukken kan vinden en op waarde kan schatten. Hoewel lang niet alle bestudeerde informatie in deze scriptie is verwerkt, gebruik ik de opgedane kennis dagelijks in het uitoefenen van mijn beroep als IT-auditor. Ik vond het lastig om selecties te maken in de grote hoeveelheid informatie die voor handen over dit onderwerp. Ook was het een uitdaging om een duidelijke structuur aan te brengen om de informatie goed te kunnen presenteren. Ik hoop dat mijn scriptie een aanvulling vormen op de bestaande richtlijnen en dat het gebruikt zal worden ter ondersteuning van het riskmanagementproces binnen organisaties. Ik heb de scriptie als een grote belasting ervaren naast werk, colleges, tentamens, gezin en sociale activiteiten. Alles bij elkaar vond ik het een leerzame ervaring en door het interessante onderwerp heb ik er het grootste deel van de tijd met plezier aan gewerkt.
35
12 Literatuur / bronnen
[1]
redactie security.nl, „Adobe gebruikte zwakke encryptie voor opslag wachtwoorden,” 2 november 2013. [Online]. Available: https://www.security.nl/posting/368661/Adobe+gebruikte+zwakke+encryptie+voor+opslag+wa chtwoorden. [Geopend 30 november 2013].
[2]
redactie security.nl, „1,9 miljoen Adobe-gebruikers hadden '123456' als wachtwoord,” 5 november 2013. [Online]. Available: https://www.security.nl/posting/368890/1%2C9+miljoen+Adobegebruikers+hadden+%27123456%27+als+wachtwoord. [Geopend 30 november 2013].
[3]
redactie security.nl, „Facebook waarschuwt gebruikers voor Adobe-hack,” 11 november 2013. [Online]. Available: https://www.security.nl/posting/369459/Facebook+waarschuwt+gebruikers+voor+Adobe-hack. [Geopend 30 november 2013].
[4]
redactie security.nl, „42 miljoen wachtwoorden gestolen bij inbraak datingsite,” 20 november 2013. [Online]. Available: https://www.security.nl/posting/370185/42+miljoen+wachtwoorden+gestolen+bij+inbraak+dat ingsite. [Geopend 30 november 2013].
[5]
redactie security.nl, „GitHub reset wachtwoorden na brute force-aanval,” 20 november 2013. [Online]. Available: https://www.security.nl/posting/370189/GitHub+reset+wachtwoorden+na+brute+force-aanval. [Geopend 30 november 2013].
[6]
redactie security.nl, „Klantendatabase goksite Racing Post gestolen,” 25 november 2013. [Online]. Available: https://www.security.nl/posting/370551/Klantendatabase+goksite+Racing+Post+gestolen. [Geopend 30 november 1013].
[7]
redactie security.nl, „Microsoft: Europarlementariërs niet gehackt via Exchange-lek,” 27 november 2013. [Online]. Available: https://www.security.nl/posting/370811/Microsoft%3A+Europarlementari%C3%ABrs+niet+geh ackt+via+Exchange-lek. [Geopend 30 november 2013].
[8]
security.nl, „Forbes-personeel gebruikte zeer zwakke wachtwoorden,” 17 februari 2014. [Online]. Available: https://www.security.nl/posting/378637/Forbespersoneel+gebruikte+zeer+zwakke+wachtwoorden. [Geopend 8 maart 2014].
[9]
security.nl, „Malware steelt 600 wachtwoorden van Duitse overheid,” 30 februari 2014. [Online]. Available: https://www.security.nl/posting/377207/Malware+steelt+600+wachtwoorden+van+Duitse+ove rheid. [Geopend 8 maart 2014].
[10] security.nl, „Amazon app liet aanvaller onbeperkt wachtwoorden proberen,” 27 februari 2014. [Online]. Available: https://www.security.nl/posting/379765/Amazon+app+liet+aanvaller+onbeperkt+wachtwoorde n+proberen. [Geopend 14 maart 2014]. [11] e-overheid, „NORA Dossier Informatiebeveiliging - Normen IT-voorzieningen,” 1 september 2010. [Online]. Available: http://www.e-
36
overheid.nl/images/stories/nieuws_2010/normenit_noradossier_informatiebeveiliging.pdf. [Geopend 25 januari 2014]. [12] J. Dainith, „user account,” 2004. [Online]. Available: http://www.encyclopedia.com/doc/1O11useraccount.html. [Geopend 1 maart 2014]. [13] A. J. Menezes, P. C. v. Oorschot en S. A. Vanstone, Handbook of Applied Cryptography, CRC Presss, 1996. [14] K. Scarfone en M. Souppaya, „Guide to Enterprise Password Management, NIST,” April 2009. [Online]. Available: http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf. [Geopend 24 03 2013]. [15] J. S. Sauver, „Passwords,” 18 november 2009. [Online]. Available: http://pages.uoregon.edu/joe/passwords/passwords.pdf. [Geopend 9 maart 2014]. [16] BSI, BS ISO/IEC 27001:2005, BSI, 2005. [17] BSI, BS ISO/IEC 27002:2005, BSI, 2005. [18] D. Kosutic, „Main changes in the new ISO 27002,” 25 september 2013. [Online]. Available: http://blog.iso27001standard.com/2013/02/11/main-changes-in-the-new-iso-27002-2013draft-version/. [Geopend 26 februari 2014]. [19] P. -. S. S. Council, „Payment Card Industry (PCI) - Data Security Standard v2 - Requirements and Security Assessment Procedures,” oktober 2010. [Online]. Available: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf. [Geopend 26 januari 2014]. [20] OWASP, „Cheat Sheets,” 14 februari 2014. [Online]. Available: https://www.owasp.org/index.php/Cheat_Sheets. [Geopend 26 februari 2014]. [21] Imperva, „Consumer Password Worst Practices,” [Online]. Available: http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf. [Geopend 1 april 2013]. [22] D. Florêncio en C. Herley, „A Large-Scale Study of Web Password Habits,” mei 2007. [Online]. Available: http://research.microsoft.com/pubs/74164/www2007.pdf. [Geopend 26 januari 2014]. [23] troyhunt.com, „A brief Sony password analysis,” 6 juni 2011. [Online]. Available: http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html. [Geopend 1 April 2013]. [24] troyhunt.com, „What do Sony and Yahoo! have in common? Passwords!,” 12 Juli 2102. [Online]. Available: http://www.troyhunt.com/2012/07/what-do-sony-and-yahoo-have-in-common.html. [Geopend 27 Oktober 2013]. [25] Sophos Naked Security, „Racingpost.com Hacked - How to properly handle a data breach,” 13 November 2013. [Online]. Available: http://thecybersecuritysentinel.blogspot.nl/2013/11/racingpostcom-hacked-how-toproperly.html. [Geopend 25 maart 2014]. [26] S. M. T. Anthony, „Innovative Techniques To Simplify Sign-Ups and Log-Ins,” 5 mei 2011. [Online]. Available: http://uxdesign.smashingmagazine.com/2011/05/05/innovative-techniques-tosimplify-signups-and-logins/. [Geopend 2 maart 2014].
37
[27] M. Baxter-Reynolds, „We need to stop masking passwords,” 19 september 2013. [Online]. Available: http://www.zdnet.com/we-need-to-stop-masking-passwords-7000020894/. [Geopend 2 maart 2014]. [28] D. V. K. Matt Bishop, „Improving System Security via Proactive Password Checking,” 1995. [Online]. Available: http://ftp.uk.freesbie.org/sites/ftp.wiretapped.net/pub/security/development/secureprogramming/bishop-1995-improving-system-security-via-proactive-password-checking.pdf. [Geopend 14 januari 2014]. [29] A. Allen, „Passwords Are Near the Breaking Point,” Gartner, 2004. [30] H. Pomeranz, „Passwords Are Everywhere!,” [Online]. Available: https://digitalforensics.sans.org/summit-archives/2012/passwords-are-everywhere.pdf. [Geopend 19 februari 2014]. [31] S. Brostoff en M. Sasse, „“Ten strikes and you’re out”: Increasing the number of login attempts can improve password usability,” april 2003. [Online]. Available: http://discovery.ucl.ac.uk/19826/2/hcisec-workshop-brostoff-2.pdf. [Geopend 26 januari 2014]. [32] OWASP, „Forgot Password Cheat Sheet,” 7 maart 2013. [Online]. Available: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet. [Geopend 19 januari 2014]. [33] OWASP, „Authentication Cheat Sheet,” 16 oktober 2013. [Online]. Available: https://www.owasp.org/index.php/Authentication_Cheat_Sheet. [Geopend 19 januari 2014]. [34] OWASP, „Transport Layer Protection Cheat Sheet,” 14 januari 2014. [Online]. Available: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet. [Geopend 26 februrai 2014]. [35] OWASP, „Password Storage Cheat Sheet,” 7 oktober 2013. [Online]. Available: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet. [Geopend 19 januari 2014]. [36] OWASP, „Password length & complexity,” 15 september 2013. [Online]. Available: https://www.owasp.org/index.php/Authentication_Cheat_Sheet. [Geopend 22 februari 2014]. [37] OWASP, „OWASP Developer Guide 2.0.1,” [Online]. Available: https://www.owasp.org/index.php/OWASP_Guide_Project.
38
bijlage A maatregelen uit richtlijnen Risico 1: Wachtwoorden vallen in handen van een derde oorzaken
Maatregelen
a) Ineffectieve processen voor wachtwoord uitgifte / reset ten aanzien van identificatie. Voorbeelden:
Preventief:
Inadequate identificatie van eindgebruiker. eenvoudig te raden wachtwoorden worden uitgegeven. De manier van communiceren van de wachtwoorden aan de eindgebruiker is kwetsbaar voor afluisteren. Medewerkers van de servicedesk weten het wachtwoord van de eindgebruiker.
ISO 27002 A.11.2.3:
Gebruikers moeten worden voorzien van een veilig initieel wachtwoord, dat gewijzigd dient te worden bij de eerste keer inloggen. Voer procedures in die zekerstellen dat de identiteit van de gebruiker wordt vast gesteld vóór dat wachtwoorden worden uitgegeven (tijdelijke) wachtwoorden moeten op een veilige manier worden gecommuniceerd aan de gebruiker tijdelijke wachtwoorden moeten uniek zijn en niet te raden zijn gebruikers moeten bevestigen dat ze het tijdelijke wachtwoord hebben ontvangen.
ISO 27002 A.11.3.1:
Wijzig tijdelijke wachtwoorden (die uitgegeven zijn na een wachtwoordreset of initieel uitgegeven wachtwoorden) na de eerste keer inloggen.
ISO 27002 A.11.5.1
Geef geen onnodige informatie bij een niet geslaagde login-poging dat een ongeautoriseerde gebruiker kan helpen om binnen te komen.
ISO 27002 A.11.5.3
Laat gebruikers hun eigen wachtwoorden kiezen, instellen en wijzigen Dwing gebruikers om hun wachtwoord te wijzigen na de eerste login
PCI-DSS 8.5.1:
Verifieer de identiteit van de gebruiker vóór het uitvoeren van een wachtwoord reset procedure
PCI-DSS 8.5.3
Geef bij het instellen van initiële wachtwoorden en wachtwoorden bij een wachtwoord reset altijd unieke wachtwoord in en forceer een wachtwoordwijziging na de eerste maal inloggen.
OWASP “Forgot Password Cheat Sheet:
Identificatie van de gebruiker moet zorgvuldig worden vastgesteld om te voorkomen dat het wachtwoord wordt doorgegeven aan “de verkeerde” persoon. Een tijdelijk nieuw wachtwoord wordt aangemaakt en verstuurd via een ander kanaal, zoals via SMS of email. Suggereer een wachtwoordwijziging nadat de gebruiker inlogt met zijn nieuwe wachtwoord.
OWASP “Password length & complexity”:
Wanneer wachtwoorden worden gegenereerd, bijvoorbeeld bij wachtwoord reset procedure, dan een algoritme gebruiken dat pseudowillekeurige getallen genereerd.
OWASP “Developer guide”:
Gebruik geen automatisch wachtwoord-reset mechanisme, tenzij het systeem en de data waar het systeem toegang toe geeft onbelangrijk is. De reden is dat automatische wachtwoord-reset mechanismes vaak 39
onveilig zijn omdat ze vertrouwen op z.g. geheime antwoorden op voorgedefinieerde vragen. Dit is een onveilig mechanisme omdat de antwoorden op deze vragen in klare tekst worde opgeslagen. Stel de gebruiker op de hoogte wanneer een wachtwoord reset procedure is aangevraagd.
Detectief: b) Social-engineering of handelen van de gebruiker zoals:
De gebruiker vertelt zijn wachtwoord vrijwillig door aan een derde, bijvoorbeeld omdat iemand tijdens vakantie zijn werk moet overnemen of door omkoping. een derde kan het wachtwoord raden omdat de gebruiker een eenvoudig te raden wachtwoord koos. Een derde gebruikt een elders gecompromitteerd wachtwoord doordat de gebruiker wachtwoorden hergebruikt. Een derde ontfutseld het wachtwoord bij een gebruiker door social engineering technieken toe te passen. Een derde heeft toegang tot de door de gebruiker onveilig opgeslagen wachtwoorden, bijvoorbeeld de wachtwoorden die op een briefje geschreven zijn, opgeslagen in de webbrowser of in een macro voor automatisch inloggen. Omkoping Bedreiging Samenspanning
Preventief: ISO 27002 A.11.2.3:
Gebruikers moeten een verklaring tekenen dat ze hun wachtwoord confidentieel behandelen.
ISO 27002 A.11.3.1:
Gebruikers moet worden geadviseerd om wachtwoorden confidentieel te behandelen Gebruikers moet worden geadviseerd om wachtwoorden niet te registreren (op een papiertje, in een bestand of op een mobiel apparaat), tenzij dit veilig gebeurd en is goedgekeurd Gebruikers moet worden geadviseerd om wachtwoorden niet te hergebruiken Gebruikers moeten worden geadviseerd om wachtwoorden regulier te wijzigen, gebaseerd op het aantal keer inloggen. Gebruikers moet worden geadviseerd om business wachtwoorden niet voor privé accounts te gebruiken en andersom.
ISO 27002 A.11.5.1 / A.11.5.3:
Toon het wachtwoord niet op het scherm bij het invoeren Houd een registratie bij van vorige wachtwoorden en voorkom daarmee hergebruik van wachtwoorden
PCI-DSS 8.5.9:
Forceer een wachtwoordwijziging elke 90 dagen.
PCI-DSS 12.6:
Ontwikkel een formeel security awareness programma om personeel bewust te maken van het belang van (creditcard) beveiliging Leid personeel op bij aanname en op zijn minst jaarlijks Vereis van personeel dat ze op zijn minst jaarlijks een verklaring ondertekenen dat ze het beveiligingsbeleid gelezen hebben en begrijpen
OWASP “Authentication Cheat Sheet”:
Digitale wachtwoord kluizen. OWASP suggereert het gebruik van een wachtwoordkluis voor elke gebruiker om niet alleen wachtwoorden op te slaan, maar ook om veilige wachtwoorden te genereren
OWASP “Password lenght & complexity”:
Hou bij welke wachtwoorden er in het verleden gebruikt zijn en zorg dat deze niet kunnen worden hergebruikt.
OWASP “Developer guide”:
versoepel de frequentie van afgedwongen wachtwoordwijzigingen wanneer een gebruiker een wachtwoord kiest tussen 8 en 16 tekens.
40
Wachtwoordwijziging voor wachtwoorden langer dan 16 tekens zou zelfs nooit afgedwongen te hoeven worden. Detectief: c) Een hardware/software keylogger of camera.
Preventief: ISO 27002 A.9:
Fysiek beveiliging zoals, fysieke zonering, tourniquets, deuren met paslezers etc.
ISO 27002 A.10.4:
Algehele beveiliging van werkstations tegen installatie van software keyloggers.
PCI-DSS, Requirement 6: Ontwikkel en onderhoud veilige systemen en applicaties. out of scope voor OWASP Detectief: d) Een hacker of kwaadaardige software steelt de wachtwoorden of wachtwoordhashes.
Preventief: ISO 27002 A.10.4: Algehele beveiliging van systemen. (niet opgenomen in bijlage B, omdat het niet specifiek genoeg is voor het onderwerp). PCI-DSS, Requirement 6: Ontwikkel en onderhoud veilige systemen en applicaties. (niet opgenomen in bijlage C, omdat het niet specifiek genoeg is voor het onderwerp). OWASP richtlijnen voor het beveiligen van de applicatielaag (niet opgenomen in bijlage D, omdat het niet specifiek genoeg is voor het onderwerp). Detectief: PCI-DSS, Requirement 11 / ISO 27002 15.2.1:
Reguliere controles op de beveiliging van systemen
PCI-DSS, Requirement 10 / ISO 27002 10.10:
Security monitoring.
PCI-DSS, Requirement 11, ISO 27002 15.2.2:
Monitoring op instellingen in het systeem die relevant zijn voor de beveiliging (z.g. technical state compliance monitoring9).
PCI-DSS, Requirement 11.5, ISO 27002 15.2.2:
Monitor de integriteit van belangrijke bestanden op het systeem, op besturingssysteem, database en applicatie niveau.
Technical Compliance State Monitoring is het monitoren van de security instellingen van applicaties en systemen om er zeker van te zijn dat deze niet ongeautoriseerd worden gewijzigd. 9
41
e) Een hacker kraakt de wachtwoordhashes nadat hij het systeem gecompromitteerd heeft.
Preventief: ISO 27002 A. 11.3.1:
wachtwoorden mogen nooit onbeveiligd worden opgeslagen
ISO 27002 A. 11.3.1:
Gebruik kwaliteits-wachtwoorden die aan de volgende eisen voldoen: - voldoende lang - eenvoudig te onthouden - niet gebaseerd op iets wat eenvoudig te raden is of informatie dat gekoppeld is aan de persoon en eenvoudig te achterhalen is zoals telefoonnummer, geboortedatum, naam van huisdier etc.
ISO 27002 A. 11.5.3:
Eis kwaliteitswachtwoorden van gebruikers. Opslag van wachtwoord moet in een beveiligde (versleuteld of gehasht) vorm
PCI-DSS 8.4:
Versleutel alle wachtwoorden bij opslag
PCI-DSS 8.5.10/11:
Forceer een minimale wachtwoordlengte van 7 tekens. Forceer dat elk wachtwoord zowel numerieke als alfanumerieke tekens bevat
OWASP “Authentication Cheat Sheet”:
Minimum en maximum wachtwoordlengte. Wachtwoorden korter dan 10 tekens wordt gezien als zwak. Er wordt aangeraden om de maximum wachtwoorden niet kleiner te maken dan 128 tekens om gebruikers niet te beperken. Wachtwoordcomplexiteit. OWASP adviseert: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 speciaal teken en niet meer dan twee dezelfde tekens achter elkaar. Aanvullend advies: de wachtwoord policy goed communiceren aan de gebruikers
OWASP “Password Storage Cheat Sheet”:
Beperk de keuze van een wachtwoord zo min mogelijk door lange wachtwoorden toe te staan en zo veel mogelijk karakters toe te staan (bv ook spaties, en leestekens). Salting. Salting behelst het toevoegen van een willekeurige tekenreeks aan elke wachtwoord alvorens het op te hashen en op te slaan. Dit heeft twee doelen: 1) Het is niet meer te zien dat twee wachtwoorden identiek zijn en 2) een aanval met voorberekende hash waarden (z.g. rainbow table) is onmogelijk geworden.). Beide doelen vertragen een off-line brute force aanval. Gebruik een hashfunctie dat bestand is tegen aanvallen met GPU’s10 en FPGA’s11.
GPU=Graphics Processing Unit. Dit is een video uitbreidingskaart voor een computer. Bekende merken zijn NVidia en AMD. 11 FPGA= Field-programmable gate array. Dit is gespecialiseerde hardware voor een bepaald taak. In dit geval is de taak het snel kraken van wachtwoorden. 10
42
Gebruik een hash functie waarbij een z.g. key toegevoegd kan worden om het off-line kraak proces zeer lastig danwel onmogelijk (afhankelijk van de lengte van de key) te maken. De key is een extra willekeurige tekenreeks dat op een andere plek wordt opgeslagen als de wachtwoordhashes. Bij het uitlekken van de wachtwoordhashes wordt de key mogelijk niet gecompromitteerd, wat de hashes onbruikbaar maakt. Een voorbeeld is het HMAC algoritme zoals HMAC-SHA-256
OWASP “Password lenght & complexity”:
Minimale lengte: 8 karakters Minimaal een letter, een cijfer en een leesteken Wanneer wachtwoorden worden gegenereerd, bijvoorbeeld bij wachtwoord reset procedure, dan een algoritme gebruiken dat pseudowillekeurige getallen genereerd
OWASP “Developer guide”, Authentication:
Wachtwoorden onder de 16 karakters zijn niet veilig en kunnen worden gekraakt binnen twee weken. Stel wachtwoordbeleid op voor: - gebruikers om de juiste wachtwoorden te kiezen. - sta gebruikers toe hun wachtwoorden op te schrijven, onder voorwaarde dan het papier veilig wordt weggeborgen. - Moedig gebruikers aan om z.g. pass phrases te gebruiken in plaats van wachtwoorden. Pass phrases zijn complete zinnen die als wachtwoord gebruikt worden. - versoepel de frequentie van afgedwongen wachtwoordwijzigingen wanneer een gebruiker een wachtwoord kiest tussen 8 en 16 tekens. Wachtwoordwijziging voor wachtwoorden langer dan 16 tekens zou zelfs nooit afgedwongen te hoeven worden Dwing geen wachtwoordcomplexiteit af wanneer het wachtwoord langer is dan 13 tekens. Test bij het instellen van het wachtwoord of het een triviaal, eenvoudig te raden wachtwoord betreft door het te toetsen aan een lijst met veel voorkomende wachtwoorden. Voer een minimale frequentie in voor het afdwingen van een wachtwoordwijziging. Wachtwoorden moeten altijd versleuteld worden met een algoritme dat niet omkeerbaar is (een z.g. hash).
OWASP “Developer guide”, Configuration: f) Wachtwoorden worden afgeluisterd wanneer ze over het netwerk worden verstuurd.
Wachtwoorden zouden alleen opgeslagen moeten worden in een niet omkeerbare vorm, oftewel een hash.
Preventief: ISO 27002 A.11.5.1:
Transporteer wachtwoorden niet in klare tekst over een netwerk
ISO 27002 A.11.5.3:
Transport van wachtwoorden moet in een beveiligde (versleuteld of gehasht) vorm
PCI-DSS 8.4:
Versleutel alle wachtwoorden tijdens transmissie over een netwerk
43
OWASP “Transport Layer Protection”gaat compleet over het veilig versturen van gegevens, inclusief wachtwoorden over een netwerk. Detectief: g) Online guessing
Preventief: ISO 27002 A.11.3.1:
Gebruik kwaliteits-wachtwoorden die aan de volgende eisen voldoen: - voldoende lang - eenvoudig te onthouden - niet gebaseerd op iets wat eenvoudig te raden is of informatie dat gekoppeld is aan de persoon en eenvoudig te achterhalen is zoals telefoonnummer, geboortedatum, naam van huisdier etc.
ISO 27002 A.11.5.1:
Limiteer het aantal niet-succesvolle login pogingen tot bijvoorbeeld 3 pogingen en overweeg: - registreer niet-succesvolle en succesvolle login pogingen - forceer een tijdspanne voordat weer een login poging gedaan kan worden of blokkeer elke volgende login poging - alarmeer IT medewerkers wanneer het maximaal toegestane login pogingen is overschreden. - zet het maximaal aantal onsuccesvolle login pogingen in samenhang met het de minimale lengte van het wachtwoord en de waarde van het systeem Geef geen onnodige informatie bij een niet geslaagde login-poging dat een ongeautoriseerde gebruiker kan helpen om binnen te komen
ISO 27002 A.11.5.3:
Dwing wachtwoordwijzigingen af
PCI-DSS 8.5.10:
Forceer een minimale wachtwoordlengte van 7 tekens
PCI-DSS 8.5.11
Forceer dat elk wachtwoord zowel numerieke als alfanumerieke tekens bevat
PCI-DSS 8.5.13
Blokkeer een gebruikersaccount na 6 onsuccesvolle login pogingen
PCI-DSS 8.5.14
Zet de blokkeer tijdsduur minimaal op 30 minuten of tot wanneer een beheerder het account deblokkeert.
OWASP “Authentication Cheat Sheet”:
Minimum en maximum wachtwoordlengte. Wachtwoorden korter dan 10 tekens wordt gezien als zwak. Er wordt aangeraden om de maximum wachtwoorden niet kleiner te maken dan 128 tekens om gebruikers niet te beperken. Wachtwoordcomplexiteit. OWASP adviseert: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 speciaal teken en niet meer dan twee dezelfde
44
tekens achter elkaar. Aanvullend advies: de wachtwoord policy goed communiceren aan de gebruikers. Foutmeldingen bij een niet-geslaagde loginpoging. De foutmeldingen bij een niet geslaagde inlogpoging zouden alleen moeten terugmelden dat het inloggen niet is geslaagd, verder niets. Het voorkomen van brute-force aanvallen door een wachtwoord lockout mechanisme. Een wachtwoord lockout mechanisme blokkeert verdere loginpogingen nadat een x aantal mislukte pogingen zijn gedaan.
OWASP “Password Storage Cheat Sheet”:
Beperk de keuze van een wachtwoord zo min mogelijk door lange wachtwoorden toe te staan en zo veel mogelijk karakters toe te staan (bv ook spaties, en leestekens).
OWASP “Password lenght & complexity”:
Minimale lengte: 8 karakters Minimaal een letter, een cijfer en een leesteken Hou bij welke wachtwoorden er in het verleden gebruikt zijn en zorg dat deze niet kunnen worden hergebruikt. Wanneer wachtwoorden worden gegenereerd, bijvoorbeeld bij wachtwoord reset procedure, dan een algoritme gebruiken dat pseudowillekeurige getallen genereerd.
OWASP “Developer guide”:
Wachtwoorden onder de 16 karakters zijn niet veilig en kunnen worden gekraakt binnen twee weken. Stel wachtwoordbeleid op voor: - gebruikers om de juiste wachtwoorden te kiezen. - sta gebruikers toe hun wachtwoorden op te schrijven, onder voorwaarde dan het papier veilig wordt weggeborgen. - Moedig gebruikers aan om z.g. pass phrases te gebruiken in plaats van wachtwoorden. Pass phrases zijn complete zinnen die als wachtwoord gebruikt worden. - versoepel de frequentie van afgedwongen wachtwoordwijzigingen wanneer een gebruiker een wachtwoord kiest tussen 8 en 16 tekens. Wachtwoordwijziging voor wachtwoorden langer dan 16 tekens zou zelfs nooit afgedwongen te hoeven worden. Dwing geen wachtwoordcomplexiteit af wanneer het wachtwoord langer is dan 13 tekens. Test bij het instellen van het wachtwoord of het een triviaal, eenvoudig te raden wachtwoord betreft door het te toetsen aan een lijst met veel voorkomende wachtwoorden. Voer een minimale frequentie in voor het afdwingen van een wachtwoordwijziging.
Detectief: ISO 27002 A.11.5b:
Monitor niet geslaagde loginpogingen.
45
h) Een derde vind het wachtwoord door een enkele eenvoudige wachtwoorden te proberen op alle of een groot aantal gebruikersaccounts.
Preventief: ISO 27001/2: adviseer gebruikers om kwaliteitswachtwoorden te kiezen. OWASP “Authentication Cheat Sheet” / ISO 27002 A.11.5.1d:
Voer een trivialiteitscontrole uit om eenvoudig te raden wachtwoorden te voorkomen. Geef zo min mogelijk informatie bij een foute inlogpoging. Zo kan niet bepaald worden of een user-account bestaat of niet.
Detectief: ISO 27002 11.5b: i) Een derde steelt de wachtwoorden of wachtwoordhashes van backup-media.
Monitor de frequentie van niet geslaagde inlogpogingen, per netwerknode, maar ook overall.
Preventief: ISO 27002 A.10.5.1e:
Backup-media moeten fysiek beveiligd worden. (Staat niet in bijlage A omdat dit niet specifiek is voor wachtwoordauthenticatie).
PCI-DSS 9.5:
Versleutelen van informatie voor het opgeslagen wordt op backupmedia. (Staat niet in bijlage C omdat het niet specifiek is voor wachtwoordauthenticatie.).
Dit valt buiten de scope van OWASP. Detectief:
Risico 2: Wachtwoorden van niet-persoonsgebonden accounts blijven bekend bij personen, terwijl dat niet (meer) hoort bij hun taken en verantwoordelijkheden oorzaak
Mogelijke maatregelen
n.v.t.
Preventief: ISO27002 A.11.2.1:
Geef gebruikers een unieke login-naam.
PCI-DSS 8.1:
Ken aan elke gebruiker een uniek gebruikersaccount toe.
PCI-DSS 8.5.8:
Gebruik geen niet-persoonlijke gebruikersaccounts.
Bovenstaande maatregelen zijn maatregelen door vermijding. a) Een wachtwoord van een niet-persoonsgebonden account is niet gewijzigd
Preventief: ISO 27002 A.8.3.1: 46
nadat iemand het team verlaat of ander werk gaat doen.
Wachtwoorden regulier wijzigen
ISO 27002 A.8.3.3:
Als een vertrekkende medewerker, inhuurkracht of medewerker van derde partij wachtwoorden weet van user accounts die actief blijven, dan moet dit wachtwoord worden gewijzigd op het moment dat het dienstverband, contract of overeenkomst ten einde komt.
Detectief: n.v.t. b) Standaard wachtwoord is niet gewijzigd
ISO 27002 A.11.2.3:
Standaard wachtwoorden moeten aangepast worden
PCI-DSS 2.1:
Wijzig standaard wachtwoorden altijd voordat het systeem wordt aangesloten op een netwerk
OWASP “Developer guide”:
Pas de wachtwoorden van z.g. “default accounts” aan
Risico 3: Wachtwoorden worden vervangen door een bij een andere persoon bekend wachtwoord oorzaak
Mogelijke maatregelen
a) Ondeugdelijke wachtwoordresetprocedures.
Preventief: OWASP “Forgot Password Cheat Sheet”
In het geval dat de gebruiker zelf zijn wachtwoord in mag toetsen onder supervisie van IT-support, dan eerst de gebruiker identificeren op basis van een geldig identiteitsbewijs. Bij het initieel instellen van het wachtwoord en bij wachtwoordreset het wachtwoord via een veilig medium naar de eindgebruiker communiceren. De identiteit van de gebruiker verifiëren, voordat de gebruiker zijn wachtwoord opnieuw mag instellen als onderdeel van een “wachtwoord vergeten” procedure.
Detectief: b) Wachtwoorden of wachtwoordhashes zijn onvoldoende beschermd tegen ongeautoriseerd wijzigen.
Preventief:
c) Social-engineering. Hierbij wordt de gebruiker verleid om zijn wachtwoord te veranderen op aangeven van de aanvaller.
Preventief:
d) Een kwaadwillende wijzigt het wachtwoord door mibruik te maken van een werkstation of mobiel apparaat waarop de legitieme gebruiker is ingelogd.
Preventief:
ISO 27002 / PCI-DSS: algemene beveiliging van de systemen. Detectief: Alle drie de richtlijnen bevatten maatregelen om de risicobewustzijn te vergrote bij gebruikers. Detectief: OWASP “Authentication Cheat Sheet”:
Her-authenticatie bij gevoelige functies zoals wachtwoord wijzigen
ISO 27001 / PCI-DSS: algemene maatregelen voor fysieke beveiliging en bewustwording bij de gebruiker op dit punt.
47
Detectief: e) Een systeembeheerder vervangt (tijdelijk) het wachtwoord of wachtwoordhashes waarna deze tijdelijk misbruik kan maken van andermans gebruikersaccount. Dit is een bedreiging voor de onweerlegbaarheid.
Preventief: ISO 27001 8.1.2 / PCI-DSS 12.7:
Geen specifieke maatregelen, wel algemene zoals het screenen van beheerders.
Detectief:
Risico 4: Wachtwoorden die eenmaal gecompromitteerd zijn, worden lange tijd misbruikt oorzaak
Mogelijke maatregelen
a) wachtwoorden blijven lange tijd hetzelfde doordat wachtwoordwijzigingen niet worden afgedwongen
Preventief: ISO 27002 A.11.3.1:
Gebruikers wordt geadviseerd om wachtwoorden regulier te wijzigen, gebaseerd op het aantal keer dat is ingelogd.
ISO 27002 A.11.5.3:
Dwing gebruikers om hun wachtwoord te wijzigen na de eerste login.
PCI-DSS 8.5.9:
Forceer een wachtwoordwijziging elke 90 dagen
Detectief:
b) de gebruiker het uitlekken van zijn wachtwoord niet meldt en geen actie onderneemt.
Laat de gebruiker zien bij het inloggen wanneer voor het laatst is ingelogd. Zo kan de gebruiker zelf vast stellen dat iemand onder zijn accounts is ingelogd.
Preventief: ISO 27001 A.11.3.1:
Gebruikers moet worden geadviseerd om wachtwoorden te wijzigen op het moment dat er een vermoeden is dat het wachtwoord is gecompromitteerd.
OWASP “Developer guide”:
Gebruikers moeten zo snel mogelijk hun wachtwoord wijzigen, wanneer er een vermoeden is dat het wachtwoord in handen van een derde is gevallen
Detectief: c) de gebruiker gebruikt opvolgende wachtwoorden waardoor het volgende wachtwoord steeds voorspelbaar is.
Preventief: ISO 27002 A.11.3.1:
wachtwoorden regulier te wijzigen, gebaseerd op het aantal keer inloggen. Wachtwoorden mogen niet worden hergebruikt en er mag geen wederkerend patroon worden gebruikt (fietSbel01, fietSbel02, etc.)
48
Detectief:
Risico 5: Iemand wordt ten onrechte niet geauthentiseerd op een informatiesysteem oorzaak
Mogelijke maatregelen
a) De authenticatieserver is niet beschikbaar.
Preventief: Er zijn geen specifieke maatregelen in de onderzochte normen. Wel zijn er algemene maatregelen voor het garanderen van de beschikbaarheid van systemen. Detectief:
b) De integriteit van de wachtwoordopslag (c.q. wachtwoordhashes) is aangetast
monitoren van de beschikbaarheid van de authenticatieserver.
Preventief:
Maatrelen die de integriteit van de server garanderen zoals logische toegangsbeveiliging, patching, hardening etc. Dit valt hier echter buiten de scope.
Detectief: c) Het account is vergrendeld doordat het lockoutmechanisme wordt misbruikt voor een z.g. Denial of Service (DOS) aanval. Hierbij worden accounts moedwillig geblokkeerd door meerdere malen achter elkaar een fout wachtwoord te gebruiken.
Security monitoring.
Preventief: PCI-DSS 8.5.14
Zet de blokkeer tijdsduur minimaal op 30 minuten of tot wanneer een beheerder het account deblokkeert.
49
bijlage B Relevante ISO 27001 / ISO 27002 maatregelen A.8.3.3 Het verwijderen van toegangsrechten Maatregel: Toegangsrechten van alle medewerkers, inhuurkrachten, en medewerkers van derde partijen tot informatiesystemen moeten worden ingetrokken bij het beëindiging van het dienstverband, contract of overeenkomst, of aangepast bij wijziging. Implementatieadvies vanuit ISO 27002: Als een vertrekkende medewerker, inhuurkracht of medewerker van derde partij wachtwoorden weet van user accounts die actief blijven, dan moet dit wachtwoord worden gewijzigd op het moment dat het dienstverband, contract of overeenkomst ten einde komt. A.11.2.3 Wachtwoord beheer Maatregel: De toewijzing van wachtwoorden dient te worden gecontroleerd door middel van een formeel proces. Implementatieadvies vanuit ISO 27002: a) Gebruikers moeten een verklaring tekenen dat ze hun wachtwoord confidentieel behandelen. b) Gebruikers moeten worden voorzien van een veilig initieel wachtwoord, dat gewijzigd dient te worden bij de eerste keer inloggen. c) Voer procedures in die zekerstellen dat de identiteit van de gebruiker wordt vast gesteld vóór dat wachtwoorden worden uitgegeven d) (tijdelijke) wachtwoorden moeten op een veilige manier worden gecommuniceerd aan de gebruiker e) tijdelijke wachtwoorden moeten uniek zijn en niet te raden zijn f) gebruikers moeten bevestigen dat ze het tijdelijke wachtwoord hebben ontvangen. g) wachtwoorden mogen nooit onbeveiligd worden opgeslagen. h) standaard wachtwoorden12 moeten aangepast worden. A 11.3.1 Gebruikers verantwoordelijkheden ten aanzien van wachtwoorden Maatregel: Gebruikers moeten worden geadviseerd om goede wachtwoorden te kiezen en wachtwoorden op de juiste manier te gebruiken. Implementatieadvies vanuit ISO 27002: Gebruikers moet worden geadviseerd om:
Wachtwoorden confidentieel te behandelen Wachtwoorden niet te registreren (op een papiertje, in een bestand of op een mobiel apparaat), tenzij dit veilig gebeurd en is goedgekeurd. Wachtwoorden te wijzigen op het moment dat er een vermoeden is dat het wachtwoord is gecompromitteerd. Gebruik kwaliteits-wachtwoorden die aan de volgende eisen voldoen: - voldoende lang - eenvoudig te onthouden - niet gebaseerd op iets wat eenvoudig te raden is of informatie dat gekoppeld is aan de persoon en eenvoudig te achterhalen is zoals telefoonnummer, geboortedatum, naam van huisdier etc.
Een standaard wachtwoord is een wachtwoord dat initieel staat ingesteld na installeren van software of hardware. Een standaard wachtwoord is voorspelbaar en dus zeer eenvoudig te raden. 12
50
wachtwoorden regulier te wijzigen, gebaseerd op het aantal keer dat is ingelogd. Wachtwoorden mogen niet worden hergebruikt en er mag geen wederkerend patroon worden gebruikt (fietSbel01, fietSbel02, etc..) Wijzig tijdelijke wachtwoorden (die uitgegeven zijn na een wachtwoord-reset of initieel uitgegeven wachtwoorden) na de eerste keer inloggen. wachtwoorden niet te gebruiken in scripts om automatisch in te loggen. (bv opgeslagen in een macro of script). wachtwoorden niet te hergebruiken business wachtwoorden niet voor privé accounts te gebruiken en andersom.
Aanvulling: Het management van de help desk systeem behoeft speciale aandacht, omdat dit aangevallen kan worden. 11.5.1 Veilige login procedures Maatregel: Toegang tot besturingssystemen moeten worden beheerst door een beveiligde login procedure Implementatieadvies vanuit ISO 27002: c) Geef geen onnodige informatie bij een niet geslaagde login-poging dat een ongeautoriseerde gebruiker kan helpen om binnen te komen. e) Limiteer het aantal niet-succesvolle login pogingen tot bijvoorbeeld 3 pogingen en overweeg: - registreer niet-succesvolle en succesvolle login pogingen - forceer een tijdspanne voordat weer een login poging gedaan kan worden of blokkeer elke volgende login poging - alarmeer IT medewerkers wanneer het maximaal toegestane login pogingen is overschreden. - zet het maximaal aantal onsuccesvolle login pogingen in samenhang met het de minimale lengte van het wachtwoord en de waarde van het systeem g) Informeer de gebruiker na het inloggen over: datum/tijd van de laatste succesvolle login en details van onsuccesvolle login pogingen sinds de laatste succesvolle login. h) Toon het wachtwoord niet op het scherm bij het invoeren. i) Transporteer wachtwoorden niet in klare tekst over een netwerk. A 11.5.3 Wachtwoord beheer systeem Maatregel: Wachtwoord beheer systeem moet interactief zijn en kwaliteitswachtwoorden afdwingen. Implementatieadvies vanuit ISO 27002: a) Dwing individuele login-id’s en wachtwoorden af om aansprakelijkheid (en onweerlegbaarheid) te garanderen. b) Laat gebruikers hun eigen wachtwoorden kiezen, instellen en wijzigen c) Dwing kwaliteitswachtwoorden technisch af. (er wordt hierbij verwezen naar ISO 27002, 11.3.1) d) Dwing wachtwoordwijzigingen af (er wordt hierbij verwezen naar ISO 27002, 11.3.1) e) Dwing gebruikers om hun wachtwoord te wijzigen na de eerste login (er wordt hierbij verwezen naar ISO 27002 11.2.3) f) Houd een registratie bij van vorige wachtwoorden en voorkom daarmee hergebruik van wachtwoorden. g) Toon wachtwoorden niet op het scherm bij het intoetsen. h) Sla wachtwoorden gescheiden op van applicatie data. i) Transport en opslag van wachtwoorden moet in een beveiligde (versleuteld of gehasht) vorm.
51
bijlage C Relevante PCI-DSS maatregelen 2.1 Wijzig standaard wachtwoorden12 altijd voordat het systeem wordt aangesloten op een netwerk. 8.1: Ken aan elke gebruiker een uniek gebruikersaccount toe. 8.4: Versleutel alle wachtwoorden tijdens transmissie over een netwerk en bij opslag. 8.5.1 Verifieer de identiteit van de gebruiker vóór het uitvoeren van een wachtwoord reset procedure13 8.5.3 Geef bij het instellen van initiële wachtwoorden en wachtwoorden bij een wachtwoord reset altijd unieke wachtwoord in en forceer een wachtwoordwijziging na de eerste maal inloggen. 8.5.8 Gebruik geen niet-persoonlijke gebruikersaccounts14. 8.5.9 Forceer een wachtwoordwijziging elke 90 dagen. 8.5.10 Forceer een minimale wachtwoordlengte van 7 tekens. 8.5.11 Forceer dat elk wachtwoord zowel numerieke als alfanumerieke tekens bevat 8.5.12 Sta niet toe en dwing technisch af dat een wachtwoord niet gelijk is aan de laatste 4 gebruikte wachtwoorden. 8.5.13 Blokkeer een gebruikersaccount na 6 onsuccesvolle login pogingen. 8.5.14 Zet de blokkeer tijdsduur minimaal op 30 minuten of tot wanneer een beheerder het account deblokkeert. 12.6: Ontwikkel een formeel security awareness programma om personeel bewust te maken van het belang van (creditcard) beveiliging. 12.6.1 Leid personeel op bij aanname en op zijn minst jaarlijks. 12.6.2 Vereis van personeel dat ze op zijn minst jaarlijks een verklaring ondertekenen dat ze het beveiligingsbeleid gelezen hebben en begrijpen.
Een wachtwoord reset procedure treedt in werking wanneer een gebruiker zijn wachtwoord is vergeten. En nieuw wachtwoord moet dan worden ingesteld en gecommuniceerd naar de gebruiker. 13
De Nederlandse overheid noemt een niet-persoonlijk gebruikers account een “functioneel account”. Zie ook het Nora dossier informatiebeveiliging v1.3, blz 43 [12]. 14
52
bijlage D Relevante OWASP maatregelen Authentication Cheat Sheet De “Authentication Cheat Sheet” van OWASP [33] beschrijft richtlijnen voor wachtwoordauthenticatie:
Minimum en maximum wachtwoordlengte. Wachtwoorden korter dan 10 tekens wordt gezien als zwak. Er wordt aangeraden om de maximum wachtwoorden niet kleiner te maken dan 128 tekens om gebruikers niet te beperken. Wachtwoordcomplexiteit. OWASP adviseert: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 speciaal teken en niet meer dan twee dezelfde tekens achter elkaar. Aanvullend advies: de wachtwoord policy goed communiceren aan de gebruikers. Wachtwoordreset-procedure. Hiervoor wordt verwezen naar de OWASP “Forgot Password Cheat Sheet” Wachtwoord-opslag. Hiervoor wordt verwezen naar de OWASP “Password Storage Cheat Sheet” Transport van wachtwoorden over het netwerk. Hiervoor wordt verwezen naar de “Transport Layer Protection Cheat Sheet” [34] van OWASP. Her-authenticatie bij gevoelige functies zoals wachtwoord wijzigen. Foutmeldingen bij een niet-geslaagde loginpoging. De foutmeldingen bij een niet geslaagde inlogpoging zouden alleen moeten terugmelden dat het inloggen niet is geslaagd, verder niets. Het voorkomen van brute-force aanvallen door een wachtwoord lockout mechanisme. Een wachtwoord lockout mechanisme blokkeert verdere loginpogingen nadat een x aantal mislukte pogingen zijn gedaan. Digitale wachtwoord kluizen. OWASP suggereert het gebruik van een wachtwoordkluis voor elke gebruiker om niet alleen wachtwoorden op te slaan, maar ook om veilige wachtwoorden te genereren.
Password Storage Cheat Sheet OWASP heeft een richtlijnen opgesteld specifiek voor het op slaan van wachtwoorden, de “Password Storage Cheat Sheet” [35]. Het is belangrijk dat wachtwoorden veilig worden opgeslagen om het risico van het uitlekken van wachtwoorden te verkleinen nadat de opslag van de wachtwoorden in gecompromitteerd (bv door een SQL injectie kwetsbaarheid in de applicaties). De richtlijnen voor wachtwoord opslag zijn:
Beperk de keuze van een wachtwoord zo min mogelijk door lange wachtwoorden toe te staan en zo veel mogelijk karakters toe te staan (bv ook spaties, en leestekens). Salting. Salting behelst het toevoegen van een willekeurige tekenreeks aan elke wachtwoord alvorens het op te hashen en op te slaan. Dit heeft twee doelen: 1) Het is niet meer te zien dat twee wachtwoorden identiek zijn en 2) een aanval met voorberekende hash waarden (z.g. rainbow table) is onmogelijk geworden.). Beide doelen vertragen een off-line brute force aanval. Gebruik een hashfunctie dat bestand is tegen aanvallen met GPU’s15 en FPGA’s16. Gebruik een hash functie waarbij een z.g. key toegevoegd kan worden om het off-line kraak proces zeer lastig danwel onmogelijk (afhankelijk van de lengte van de key) te maken. De key is een extra willekeurige tekenreeks dat op een andere plek wordt opgeslagen als de wachtwoordhashes. Bij het uitlekken van de wachtwoordhashes wordt de key mogelijk niet gecompromitteerd, wat de hashes onbruikbaar maakt. Een voorbeeld is het HMAC algoritme zoals HMAC-SHA-256.
Forgot Password Cheat Sheet
GPU=Graphics Processing Unit. Dit is een video uitbreidingskaart voor een computer. Bekende merken zijn NVidia en AMD. 16 FPGA= Field-programmable gate array. Dit is gespecialiseerde hardware voor een bepaald taak. In dit geval is de taak het snel kraken van wachtwoorden. 15
53
Dit OWASP document geeft richtlijnen over hoe om te gaan met een wachtwoord reset, ook wel “wachtwoord vergeten” procedure [32]. Belangrijke aandachtspunten hierin zijn:
Identificatie van de gebruiker moet zorgvuldig worden vastgesteld om te voorkomen dat het wachtwoord wordt doorgegeven aan “de verkeerde” persoon. Een tijdelijk nieuw wachtwoord wordt aangemaakt en verstuurd via een ander kanaal, zoals via SMS of email. Suggereer een wachtwoordwijziging nadat de gebruiker inlogt met zijn nieuwe wachtwoord.
Password length & complexity OWASP geeft de volgende richtlijnen voor het wachtwoordlengte en –complexiteit [36]:
Minimale lengte: 8 karakters Minimaal een letter, een cijfer en een leesteken Hou bij welke wachtwoorden er in het verleden gebruikt zijn en zorg dat deze niet kunnen worden hergebruikt. Wanneer wachtwoorden worden gegenereerd, bijvoorbeeld bij wachtwoord reset procedure, dan een algoritme gebruiken dat pseudo-willekeurige getallen genereerd.
OWASP developer guide Ook de “OWASP developer guide” [37] heeft een aantal hoofdstukken, relevant voor wachtwoordauthenticatie: Authentication
Wachtwoorden onder de 16 karakters zijn niet veilig en kunnen worden gekraakt binnen twee weken. Stel wachtwoordbeleid op voor: - gebruikers om de juiste wachtwoorden te kiezen. - sta gebruikers toe hun wachtwoorden op te schrijven, onder voorwaarde dan het papier veilig wordt weggeborgen. - Moedig gebruikers aan om z.g. pass phrases te gebruiken in plaats van wachtwoorden. Pass phrases zijn complete zinnen die als wachtwoord gebruikt worden. - versoepel de frequentie van afgedwongen wachtwoordwijzigingen wanneer een gebruiker een wachtwoord kiest tussen 8 en 16 tekens. Wachtwoordwijziging voor wachtwoorden langer dan 16 tekens zou zelfs nooit afgedwongen te hoeven worden. Pas de wachtwoorden van z.g. “default accounts” aan. Gebruikers moeten zo snel mogelijk hun wachtwoord wijzigen, wanneer er een vermoeden is dat het wachtwoord in handen van een derde is gevallen. Dwing geen wachtwoordcomplexiteit af wanneer het wachtwoord langer is dan 13 tekens. Test bij het instellen van het wachtwoord of het een triviaal, eenvoudig te raden wachtwoord betreft door het te toetsen aan een lijst met veel voorkomende wachtwoorden. Voer een minimale frequentie in voor het afdwingen van een wachtwoordwijziging. Wachtwoorden moeten altijd versleuteld worden met een algoritme dat niet omkeerbaar is (een z.g. hash). Gebruik geen automatisch wachtwoord-reset mechanisme, tenzij het systeem en de data waar het systeem toegang toe geeft onbelangrijk is. De reden is dat automatische wachtwoord-reset mechanismes vaak onveilig zijn omdat ze vertrouwen op z.g. geheime antwoorden op voorgedefinieerde vragen. Dit is een onveilig mechanisme omdat de antwoorden op deze vragen in klare tekst worde opgeslagen. Stel de gebruiker op de hoogte wanneer een wachtwoord reset procedure is aangevraagd.
54
Configuration
Wachtwoorden zouden alleen opgeslagen moeten worden in een niet omkeerbare vorm, oftewel een hash.
55