Technisch overzicht van wachtwoorden

In dit onderwerp voor IT-professionals wordt uitgelegd hoe Windows wachtwoorden implementeert in versies van Windows vanaf Windows Server 2012 en Windows 8.1. Ook worden sterke wachtwoorden, wachtwoordzinnen en wachtwoordbeleid besproken.

Hoe wachtwoorden worden opgeslagen in Windows

Dit artikel bevat informatie over de opslag van wachtwoorden in rusttoestand.

Windows vertegenwoordigt wachtwoorden in UNICODE-tekenreeksen van 256 tekens, maar het aanmeldingsdialoogvenster is beperkt tot 127 tekens. Daarom heeft het langst mogelijke wachtwoord 127 tekens. Programma's zoals services kunnen langere wachtwoorden gebruiken, maar ze moeten programmatisch worden ingesteld.

Het Windows-besturingssysteem slaat wachtwoorden op veel verschillende manieren op voor verschillende doeleinden.

Wachtwoorden die zijn opgeslagen als OWF

Voor gebruik in Windows-netwerken, waaronder Active Directory-domeinen, wordt het wachtwoord standaard op twee verschillende manieren opgeslagen: als de functie LAN Manager in één richting (LM OWF) en als de NT OWF. 'Eenrichtingsfunctie' is een term die een eenrichtingskundige transformatie van gegevens aangeeft. De gegevens die worden getransformeerd, kunnen slechts op één manier worden geconverteerd via versleuteling en kunnen niet worden omgekeerd. Het meest voorkomende type functie in één richting dat wordt gebruikt, is een cryptografische hash. Een hash is een kleine set gegevens die wiskundig is gekoppeld aan een grotere set gegevens waaruit de hash wordt berekend. Als de grotere set gegevens wordt gewijzigd, wordt de hash ook gewijzigd. Hashes zijn bijvoorbeeld handig als controlesom om te controleren of de gegevens niet zijn gewijzigd tijdens de verzending. Een cryptografische hash is een hash die voldoet aan bepaalde eigenschappen. Een cryptografische hash moet bijvoorbeeld zodanig worden gemaakt dat het wiskundig onherstelbaar is in een redelijke hoeveelheid tijd om de grotere set gegevens van alleen de hash af te afleiden. Op dezelfde manier is het wiskundig onmogelijk om twee sets grote gegevens te vinden die dezelfde hash genereren.

Er zijn veel verschillende soorten functies in één richting. Alle hash-functies zijn per definitie eenrichtingsfuncties. Gewone cryptografische functies die doorgaans omkeerbaar zijn, kunnen echter ook worden gebruikt om een eenrichtingsfunctie te maken. Dit kan worden gedaan door de gegevens en de sleutel in een cryptografische functie te verwisselen en de vaste waarde (de sleutel) te versleutelen met behulp van de gegevens als sleutel. Dit is hoe de LM-hash wordt berekend. De LM-hash wordt als volgt berekend:

1. Het wachtwoord wordt aangevuld met NULL-bytes tot exact 14 tekens. Als het wachtwoord langer is dan 14 tekens, wordt het vervangen door 14 NULL-bytes voor de resterende bewerkingen.
2. Het wachtwoord wordt geconverteerd naar alle hoofdletters.
3. Het wachtwoord wordt gesplitst in twee 7-bytesleutels (56-bits).
4. Elke sleutel wordt gebruikt om een vaste tekenreeks te versleutelen.
5. De twee resultaten van stap 4 worden samengevoegd en opgeslagen als lm-hash.

Het LM OWF-algoritme is opgenomen in Windows voor achterwaartse compatibiliteit met software en hardware die geen nieuwere algoritmen kunnen gebruiken.

De NT-hash is gewoon een hash. Het wachtwoord wordt gehasht met behulp van het MD4-algoritme en opgeslagen. De NT OWF wordt gebruikt voor verificatie door domeinleden in zowel Windows NT 4.0 als eerdere domeinen en in Active Directory-domeinen.

Noch de NT-hash noch de LM-hash wordt gezouten. Salting is een proces dat het wachtwoord combineert met een willekeurige numerieke waarde (de zogenaamde "salt") voordat de eenrichtingsfunctie wordt berekend.

Wachtwoorden die zijn opgeslagen in Active Directory

Wachtwoorden wanneer ze niet in gebruik zijn worden opgeslagen in verschillende attributen van de Active Directory-database (NTDS.DIT-bestand). Deze kenmerken worden vermeld in de volgende tabel:

Active Directory-kenmerk	Inhoud
unicodePwd	Versleutelde NT-hash
dbcsPwd	Versleutelde LM-hash
ntPwdGeschiedenis	Versleutelde NT-hashes - Wachtwoordgeschiedenis
lmPwdGeschiedenis	Versleutelde LM-hashes - wachtwoordgeschiedenis
aanvullende inloggegevens	Kerberos-sleutels, WDigest, enzovoort.

Opmerking

De opslag van LM-hashes is standaard uitgeschakeld sinds Windows Vista en Windows Server 2008.

Wanneer deze is opgeslagen in het DIT-bestand, wordt de NT-hash beveiligd door twee versleutelingslagen. In Windows Server 2016/Windows 10 en latere versies wordt het eerst versleuteld met DES voor achterwaartse compatibiliteit en vervolgens met CNG BCrypt AES-256 (zie CNGBCRYPT_AES_ALGORITHM). Eerdere Windows-versies versleutelen NT-hashes met behulp van twee lagen DES + RC4-versleuteling.

Zie MS-SAMR: supplementalCredentials en Supplemental Credentials Structures voor meer informatie over aanvullende referenties.

Wachtwoorden die zijn opgeslagen in de lokale SAM

Op domeinleden en werkstations worden wachtwoordhashes voor lokale gebruikersaccounts opgeslagen in een lokale SAM-database (Security Account Manager) die zich in het register bevindt. Ze worden versleuteld met dezelfde versleutelings- en hash-algoritmen als Active Directory. De wachtwoorden in het aanvullende kenmerkCredentials voor lokale gebruikersaccounts worden ook opgeslagen in de lokale SAM-database sinds Windows Server 2016.

Referenties in cache

Windows slaat ook een wachtwoordverificator op bij domeinleden wanneer een domeingebruiker zich aanmeldt bij dat domeinlid. Deze verificator kan worden gebruikt om een domeingebruiker te verifiëren als de computer geen toegang heeft tot de domeincontroller. De wachtwoordverificator wordt ook wel een in de cache opgeslagen referentie genoemd. Het wordt berekend door de NT-hash te nemen, de gebruikersnaam eraan samen te voegen en vervolgens het resultaat te hashen met behulp van de MD4-hashfunctie.

Hoe wachtwoorden werken in Windows

In Windows en vele andere besturingssystemen is één methode voor het verifiëren van de identiteit van een gebruiker het gebruik van een geheime wachtwoordzin of wachtwoord.

U wordt aangeraden beveiligde meervoudige verificatie te gebruiken, zoals SmartCard, FIDO en Windows Hello voor Bedrijven. Wachtwoordverificatie is echter nog steeds vereist in sommige scenario's.

Voor het beveiligen van uw netwerkomgeving moeten sterke wachtwoorden door alle gebruikers worden gebruikt. Dit helpt voorkomen dat kwaadwillende gebruikers een zwak wachtwoord raden, hetzij via handmatige methoden of met behulp van hulpprogramma's, om de referenties van een aangetast gebruikersaccount te verkrijgen. Dit geldt met name voor beheerdersaccounts. Wanneer u een complex wachtwoord regelmatig wijzigt, vermindert dit de kans op een geslaagde wachtwoordaanval.

Instellingen voor wachtwoordbeleid bepalen de complexiteit en levensduur van wachtwoorden. Wachtwoordbeleid is van invloed op Windows-wachtwoorden, niet noodzakelijkerwijs functiewachtwoorden.

De mogelijkheid van gebruikers om hun wachtwoorden te wijzigen, wordt bepaald door het wachtwoordbeleid en de beschikbare interfaces. Gebruikers kunnen bijvoorbeeld op elk gewenst moment hun wachtwoord wijzigen op basis van het wachtwoordbeleid dat wordt beheerd door de systeembeheerder of domeinbeheerder. Met functies zoals Windows Vault, BitLocker en Encrypting File System kunnen gebruikers wachtwoorden wijzigen die specifiek zijn voor die functie.

Hoe wachtwoorden worden gebruikt in Windows

Wanneer een gebruiker zich aanmeldt, wordt het wachtwoord dat de gebruiker typt, geconverteerd naar twee typen éénrichtingsfuncties en opgeslagen in het geheugen door het LSASS-proces (Local Security Authority Subsystem Service). Als de gebruiker een lokaal account gebruikt voor verificatie, wordt de NT OWF vergeleken met de lokaal opgeslagen NT-hash en als de twee overeenkomen, wordt de gebruiker aangemeld. Als de gebruiker verificatie uitvoert op basis van een Active Directory-domein met behulp van een hostnaam voor toegang tot een resource, wordt de NT-hash gebruikt in een Kerberos-aanmelding bij het Key Distribution Center (KDC), wat doorgaans de domeincontroller is.

Kerberos kan niet worden gebruikt in de volgende situaties:

• Verifiëren voor een domein met alleen Windows NT 4.0 of eerder
• Toegang tot een resource op een Active Directory-domeinlid met behulp van een IP-adres in plaats van een hostnaam
• Toegang tot een resource op een computer die geen lid is van een Active Directory-domein
• Toegang tot een resource op een computer die lid is van een Active Directory-domein, maar die niet wordt vertrouwd door uw domein
• Toegang tot een resource op een computer waarop Kerberos niet wordt ondersteund

In deze situaties maakt het verificatieproces gebruik van twee verschillende protocollen, LAN Manager en NTLM genoemd. Het proces begint met de client die een uitdaging aanvraagt van de verificatieserver. Nadat de uitdaging is ontvangen, berekent de client een reactie op deze uitdaging. Dit wordt gedaan door eerst de twee hashes van het wachtwoord op te vullen met nulwaarden tot 168 bits. De 168 bits van elke hash worden vervolgens gesplitst in drie 56-bits DES-sleutels. De zes DES-sleutels worden vervolgens gebruikt om de uitdaging te versleutelen. De drie coderingsteksten die worden geproduceerd met behulp van de LM-hash, worden samengevoegd en worden het LAN Manager-antwoord. De drie coderingsteksten die worden geproduceerd met behulp van de NT-hash, worden samengevoegd en worden het NTLM-antwoord.

De functies die worden gebruikt om het antwoord te berekenen, kunnen worden gewijzigd door de instelling LM-compatibiliteitsniveau in de netwerkbeveiliging: groepsbeleidsinstelling LAN Manager-verificatieniveau . Als deze waarde is ingesteld op 1 of lager, verzendt de client de oorspronkelijke LAN Manager- en NTLM-antwoorden. Als deze is ingesteld op 2, wordt alleen het NTLM-antwoord verzonden. Als deze is ingesteld op 3 of hoger, wordt een nieuwe versie van beide protocollen gebruikt. De NTLM-versie heet NTLMv2. De LAN Manager-versie wordt vaak LMv2 genoemd. Beide protocollen gebruiken de NT-hash om het antwoord te berekenen en beide gebruiken een uitdaging aan de clientzijde, in plaats van of naast de servervraag. Als de instelling LM-compatibiliteitsniveau is ingesteld op 1 of hoger, wordt het NTLM-antwoord bovendien tijdstempels toegewezen om herhalingsaanvallen te voorkomen. Zie Netwerkbeveiliging: LAN Manager-verificatieniveau voor informatie over de instelling LM-compatibiliteitsniveau.

Sterke wachtwoorden

Wachtwoorden bieden de eerste verdedigingslinie tegen onbevoegde toegang tot uw organisatie. Vanaf Windows Server 2003 controleert Windows de complexiteit van het wachtwoord voor het beheerdersaccount tijdens de installatie van het besturingssysteem. Als het wachtwoord leeg is of niet voldoet aan de complexiteitsvereisten, wordt u in het dialoogvenster Windows Setup gevraagd een sterk wachtwoord voor het beheerdersaccount te maken. Als u dit wachtwoord leeg laat, hebt u geen toegang tot dit account via het netwerk.

Zwakke wachtwoorden bieden aanvallers gemakkelijke toegang tot uw computers en netwerk, terwijl sterke wachtwoorden aanzienlijk moeilijker te kraken zijn. In de volgende tabel worden zwakke en sterke wachtwoorden vergeleken.

Zwak wachtwoord	Sterk wachtwoord
Blanco	Is ten minste zeven tekens lang
Bevat gemakkelijk vindbare of bekende informatie, zoals gebruikersnaam of domeinnaam	Bevat 'geheim' of willekeurige informatie
Lijkt op eerdere wachtwoorden	Verschilt aanzienlijk van eerdere wachtwoorden
Bevat een volledig woordenlijstwoord	Bevat een combinatie van de volgende tekens: - Hoofdletters - Kleine letters -Cijfers - Symbolen inclusief spaties

Een voorbeeld van een sterk wachtwoord is J*p2leO4>F.

Een wachtwoord kan voldoen aan de meeste criteria van een sterk wachtwoord, maar is nog steeds vrij zwak. Bijvoorbeeld Hello2U! is een relatief zwak wachtwoord, ook al voldoet het merendeel van de criteria voor een sterk wachtwoord en voldoet ook aan de complexiteitsvereisten van het wachtwoordbeleid. H!elZl2o is een sterk wachtwoord omdat het woordenboekwoord wordt afgewisseld met symbolen, cijfers en andere letters. Het is belangrijk om gebruikers te informeren over de voordelen van het gebruik van sterke wachtwoorden en om hen te leren hoe ze wachtwoorden kunnen maken die daadwerkelijk sterk zijn.

U kunt wachtwoorden maken die tekens bevatten uit de uitgebreide ANSI-tekenset. Als u uitgebreide ANSI-tekens gebruikt, wordt het aantal tekens dat u kunt kiezen wanneer u een wachtwoord maakt, verhoogd. Het kan langer duren voordat de software die wachtwoorden kraakt, wachtwoorden met deze uitgebreide ANSI-tekens kraakt dan wanneer het andere wachtwoorden betreft. Voordat u uitgebreide ANSI-tekens in uw wachtwoord gebruikt, test u deze grondig om ervoor te zorgen dat wachtwoorden met uitgebreide ANSI-tekens compatibel zijn met de toepassingen die uw organisatie gebruikt. Wees vooral voorzichtig met het gebruik van uitgebreide ANSI-tekens in wachtwoorden als uw organisatie verschillende besturingssystemen gebruikt. Deze systemen kunnen bijvoorbeeld standaardiseren in ISO-8859-15. De daadwerkelijke protocolimplementatie in Windows gebruikt vaak UNICODE of UTF8 in plaats van daadwerkelijke ANSI-codering.

Voorbeelden van wachtwoorden die tekens uit de uitgebreide ANSI-tekenset bevatten, zijn kUµ!¶0o en Wf©$0k#»g¤5ªrd.

Wachtwoordzinnen in Windows

Een wachtwoordzin is een andere vorm van wachtwoord op basis van tokens waarin de tokens woorden zijn in plaats van symbolen uit een tekenset. Een voorbeeld van een wachtwoordzin is een zin die speciale tekens, cijfers, hoofdletters en kleine letters bevat. De belangrijkste verschillen tussen wachtwoordzinnen en wachtwoorden zijn:

• Een wachtwoordzin heeft meestal spaties; wachtwoorden niet.
• Een wachtwoordzin is veel langer dan de overgrote meerderheid van woorden en, belangrijker, langer dan een willekeurige reeks letters die een gewone persoon kon onthouden.

Wachtwoordzinnen die voldoen aan de tekenlimiet die in het beleid zijn ingesteld, zijn over het algemeen moeilijker te kraken dan wachtwoorden omdat ze meer tekens bevatten. Het is de LM- en NT-hash waarin het wachtwoord of de wachtwoordzin wordt opgeslagen, en de LM-hash is de zwakkere van de twee.

Er zijn verschillende manieren om ervoor te zorgen dat de LM-hash niet wordt opgeslagen; een van deze is het gebruik van wachtwoorden of wachtwoordzinnen die langer zijn dan 14 tekens. U kunt ook de netwerkbeveiliging gebruiken: Sla de hashwaarde van LAN Manager niet op bij de volgende groepsbeleidsinstelling voor wachtwoordwijziging . Als u deze beleidsinstelling gebruikt, worden opslag-LM-hashes voor alle accounts globaal uitgeschakeld. De wijziging wordt van kracht wanneer het wachtwoord de volgende keer wordt gewijzigd. Omdat het effect van het beleid niet onmiddellijk is, ziet u niet onmiddellijk mogelijke interoperabiliteitsproblemen die worden veroorzaakt door het niet opslaan van LM-hashes.

Lokaal wachtwoordbeleid dat beschikbaar is in Windows

U kunt een instelling voor wachtwoordbeleid implementeren waarmee vereisten voor wachtwoordcomplexiteit worden afgedwongen. Zie Wachtwoord moet voldoen aan complexiteitsvereisten voor meer informatie over deze beleidsinstelling. Zie Een wachtwoordbeleid toepassen of wijzigen voor meer informatie over het toepassen van een wachtwoordbeleid. Zie Wachtwoordbeleid voor informatie over alle beschikbare instellingen voor wachtwoordbeleid.

Fijnmazig wachtwoordbeleid dat beschikbaar is via Active Directory Domain Services (AD DS)

Vanaf Windows Server 2008 kunt u fijnmazige wachtwoordbeleidsregels gebruiken om meerdere wachtwoordbeleidsregels op te geven en verschillende wachtwoordbeperkingen en accountvergrendelingsbeleidsregels toe te passen op verschillende sets gebruikers binnen één domein. Als u bijvoorbeeld de beveiliging van bevoegde accounts wilt verhogen, kunt u strengere instellingen toepassen op de bevoegde accounts en vervolgens minder strikte instellingen toepassen op de accounts van andere gebruikers. Of in sommige gevallen wilt u mogelijk een speciaal wachtwoordbeleid toepassen voor accounts waarvan de wachtwoorden worden gesynchroniseerd met andere gegevensbronnen.

Er bestaan twee nieuwe objectklassen in het AD DS-schema om fijnmazige wachtwoordbeleidsregels op te slaan:

• Container voor wachtwoordinstellingen
• Wachtwoordinstellingen

Zie AD DS: Fine-Grained Wachtwoordbeleid voor meer informatie over deze beleidsregels.