NIST-advies: schrap complexe wachtwoorden en verplichte regelmatige wijzigingen

Het nieuwe advies voor wachtwoorden van standaardenorganisatie NIST stelt dat complexe wachtwoorden en verplichte, regelmatige wijzigingen onnodig en zelfs onveilig kunnen zijn. Het bijgewerkte advies gaat daarmee in tegen standaardpraktijken die al jaren worden gehanteerd.

Het National Institute of Standards and Technology (NIST) geeft in zijn nieuwe richtlijnen voor wachtwoorden opvallend andere best practices voor betere beveiliging. Naast het afraden van complexe wachtwoorden en het afschaffen van regelmatige gedwongen wijzigingen van wachtwoorden adviseert de Amerikaanse organisatie nu ook om te stoppen met beveiligingsvragen en hints daarvoor.

Het afdwingen van complexe wachtwoorden, met bijvoorbeeld cijfers en leestekens, kan gebruikers ertoe brengen om van 'password' dan 'password1' of 'password1!' te maken, geeft het NIST als voorbeeld. Het opleggen van regelmatige wachtwoordwijzigingen kan dit nog verergeren. Gedwongen wijzigingen van wachtwoorden zouden volgens het nu definitieve advies alleen moeten gebeuren nadat een hack of datalek heeft plaatsgevonden.

Het NIST geeft echter ook beveiligingsadviezen voor wachtwoorden die al langer gebruikelijk zijn, zoals het gebruik van langere wachtwoorden en wachtzinnen. Het NIST adviseert dat wachtwoorden minimaal 8 tekens lang moeten zijn en maximaal 64 tekens. De bovenkant van dat bereik geniet de voorkeur, omdat langere wachtwoorden minder snel zijn te kraken.

Daarbij wijst het NIST wel op het grotere gevaar van kraakaanvallen die offline worden uitgevoerd, waarmee beperkingen voor het aantal inlogpogingen worden omzeild. Offline aanvallen zijn mogelijk wanneer kwaadwillenden versleutelde wachtwoorden hebben buitgemaakt via bijvoorbeeld een databaselek.

Hoe wachtwoorden zijn opgeslagen in een database kan bepalend zijn voor de succeskansen van offline kraakpogingen, aldus de standaardenorganisatie. Hashing, salting en gebruik van rekenkundig zware algoritmes zijn technieken om de kraakkansen voor aanvallers te verkleinen. Wachtwoorden die offline aanvallen kunnen weerstaan moeten zelfs met zulke maatregelen vele malen complexer zijn dan wachtwoorden die alleen online aanvallen kunnen doorstaan, waarschuwt het NIST. Het Zwitserse, op privacy gerichte Proton zet de complexe materie van de nieuwe NIST-wachtwoordadviezen uiteen in een blogpost. Securitynieuwssite SecurityBoulevard biedt een uitgebreidere uitleg.

Reacties (185)

[Klauwhamer]

Ik vind het ook hemeltergend wanneer je te maken hebt met portaaltjes die complexiteit afdwingen en daarmee mijn wachtwoordmanager met gegenereerd wachtwoord dwars zitten. Probeer ook altijd een klacht uit te sturen met een voorbeeld, dat bijvoorbeeld "DitIsMaarEenVoorbeeldVanEenPassphrase" wordt geweigerd omdat het niet "complex" genoeg is, maar "Welkom01!" wél wordt geaccepteerd. Dwing een minimale lengte af (>16) en be done with it. Ook dat periodiek verplicht wijzigen: wégwezen. Dat doe je bij het vermoeden van gecompromitteerd zijn.

[Majhool]

Eens. Besef dat dit wel nieuwe inzichten zijn. Die portalen en sites gebruiken keurig de oude standaard. Dus nu met z'n allen aanmoedigen dat ze naar deze nieuwe NIST standaard gaan.

[jotheman]

Dat klopt dus niet. Bijvoorbeeld Microsoft heeft al geruime tijd (rond de 5 jaar) al deze aanbevelingen, dat is/was gewoon weinig bekend. De laatste jaren is dit pas breder in media en standaarden doorgewerkt, maar de "wijsheid" dat periodieke wijzigingen en dergelijke averechts werken is echt al jaren oud.

Ik merk alleen wel dat het pas heel langzaam doordringt her en der (ook op IT afdelingen) maar vooral ook: niemand durfde tot voor kort de heilige huisjes (het wachtwoordbeleid) af te breken/te doorbreken

[deadinspace]

Eens. Besef dat dit wel nieuwe inzichten zijn. Die portalen en sites gebruiken keurig de oude standaard. Dus nu met z'n allen aanmoedigen dat ze naar deze nieuwe NIST standaard gaan.

NIST adviseert minstens sinds 2017 al geen teken-vereisten en periodieke wijzigingen meer:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different
character types or prohibiting consecutively repeated characters) for memorized secrets.
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
However, verifiers SHALL force a change if there is evidence of compromise of the
authenticator.

Deze inzichten zijn echt niet zo nieuw. Bedrijven lopen vaak gewoon hopeloos achter.

[Reactie gewijzigd door deadinspace op 1 oktober 2025 20:12]

[Blokker_1999]

Er is wel 1 belangrijke bedenking die men niet mag vergeten. Het is niet omdat je complexiteit niet gaat vereisen dat je complexiteit niet mag toestaan. Als mensen speciale tekens aan hun wachtwoord of wachtzin willen toevoegen, laat hen dat aub doen. Het maakt het voor een aanvaller ook weer moeilijker om een bruteforce aanval te proberen.

[Majhool]

Hoeveel bedrijven kennen NIST? Zelfs in de IT loopt men vaak achter ISO/NEN en vooral achter Microsoft aan.

[Opxah]

Dank je voor deze toevoeging. Een deel van het artikel is dus eigenlijk geen nieuws maar een herhaling van advies wat al eerder gepubliceerd is.

[Klauwhamer]

Mwah, Bill Burr (de bedenker van dit soort complexiteitseisen) heeft in 2017 al ruiterlijk toegegeven er naast te hebben gezeten met z'n advies (dat stamt uit 2003). Dus zo "nieuw" is het niet; het is vooral dat er teveel bedrijven zijn zonder oog voor dit soort details (of zonder functionerende CISO).

[Bor]

het is vooral dat er teveel bedrijven zijn zonder oog voor dit soort details (of zonder functionerende CISO).

Of de CISO doet zijn / haar werk goed en komt op basis van een goede analyse tot de conclusie dat er in zijn of haar geval wel redenen zijn om complexiteit af te dwingen.

Mensen reageren altijd of het "one to rule them all" is als het op wachtwoord eisen aankomt. Dat is niet zo. De NIST guidelines zijn in mijn ogen ook niet echt geschikt om uit te cherry picken rond bv alleen de complexiteitseisen maar meer een gehele set maatregelen en eisen die als geheel zorgen voor een bepaald assurance level.

[Klauwhamer]

Welke goede analyse leidt volgens jou tot beleid van "minimaal 8 karakters, 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 'speciaal karakter'" in plaats van "minimaal 16 karakters en/of 100 bits entropie"..? Want dat is waar het hier defacto over gaat.

En nogmaals; het gaat hier specifiek om wachtwoordcomplexiteit van een wachtwoord. Dat is specifiek 3.1.1 van de NIST-publicatie, dus ja, het is maar een héél klein onderdeel van een raamwerk om authenticatie goed in te richten. Het dient geen doel om het te hebben over "cherry picken" als je alleen een punt kunt maken door de doelpalen te verschuiven.

[Bor]

Welke goede analyse leidt volgens jou tot beleid van "minimaal 8 karakters, 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 'speciaal karakter'" in plaats van "minimaal 16 karakters en/of 100 bits entropie"..? Want dat is waar het hier defacto over gaat.

Nee, dat is het niet als je puur naar complexiteitseisen kijkt.

In jouw eigen vergelijking zou het zijn:
- minimaal 8 karakters, 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 'speciaal karakter'"
of
- minimaal 8 karakters

Je verschuift in jouw voorbeeld het onderwerp ineens naar complexiteit en lengte.
Een wachtwoord / passphrase van 16 karakters met complexiteit is doorgaans sterker dan een wachtwoord / passphrase zonder.

[Reactie gewijzigd door Bor op 1 oktober 2025 17:02]

[Klauwhamer]

Nee, want in mijn oorspronkelijke post hanteer ik een strengere norm dan NIST door minimaal 16 karakters te willen. Entropie volgt daar logischerwijs uit (passphrase en/of wachtwoordmanager) maar goed, laat ik het simpeler voor je maken: welke goede analyse leidt tot "minimaal 8 karakters, 1 hoofdletter, 1 kleine letter, 1 cijfer, en 1 'speciaal teken'" als solide beleid? Laat mijn tegenhanger gemakshalve maar even achterwege.

[Blokker_1999]

En dat is dus niet correct. Want een aanvaller weet niet wat jij gedaan hebt. Die weet alleen dat het wachtwoord minimaal 8 karakters bevat maar niet of er hoofdletters in zitten, cijfers in zitten, leestekens inzitten, ... . En omdat een aanvaller dat niet weet moet deze er van uit gaan dat die er wel in ziten. Dat is de reden waarom men vandaag net de vereiste voor complexiteit laat vallen en kiest voor lengte.

[uiltje]

Dingen die continue te kraken zijn of dingen waarvan het wachtwoord offline kan worden geraden.

Entropy kan je alleen berekenen als je de bron kent. Een eis om 100 bits entropie te vereisen bij het invullen is natuurlijk lariekoek. In de praktijk kent geen door de mens verzonnen wachtwoord zo'n hoge entropie.

In de meeste gevallen wil je inderdaad geen hoge eisen stellen. Ik ben altijd sterk voorstander geweest van sites die inschatten of je een "sterk" wachtwoord hebt gekozen, dan krijgen mensen zelf de verantwoording en de feedback.

Natuurlijk is passwordless nog beter. Want vergeleken met de rest van IT security & cryptografie zijn wachtwoorden sowieso niet heel sterk.

[Klauwhamer]

DoerakjeBotervlootjeRaamkozijn. Hier heb je een wachtwoord dat én makkelijk is, én zelfverzonnen is, én 132-bits entropie heeft volgens KeePass. Wanneer ik een locker heb versleuteld met deze passphrase en 256-bits AES krijg jij 'm met geen enkel array of tool open. En nu komt het: je hóeft geen eisen te stellen omdat je met iedere wachtwoordmanager al helemaal goed met het genereren van goede wachtwoorden. Er is geen reden om voor minder dan 20 karakters te gaan.

Mijn ervaring is juist dat sites die een "schatting" doen van je wachtwoord volstrekt onbetrouwbaar zijn ten opzichte van de klassieker "Welkom01!".

[Reactie gewijzigd door Klauwhamer op 1 oktober 2025 17:12]

[uiltje]

Ja, natuurlijk, maar de truc is omdat op een goede manier te vereisen. Want "WachtwoordWachtwoordWacht" lijkt me nou weer niet zo brilliant.

KeePass kent geen NL woorden, da's never nooit niet 132 bits entropie. Dat is het probleem, als je niet weet hoe het gegenereerd is weet je per definitie niet de entropie.

[Blokker_1999]

Maar hier zit dus net de clue van het verhaal. Je hebt niets te vereisen buiten de minimale lengte. Maar net omdat je niets te vereisen hebt weet een aanvaller ook niet of je nu gekozen hebt voor "WachtwoordWachtwoordWacht", "W8w00rdWachtwoordWachtw00rd" danwel "802hg028nerj0^+5hg85gn@#%"

Stel je even voor dat je voor een wachtzin zou kiezen. Waarom zou dat slecht zijn? Omdat het woorden zijn? Heb je al eens nagegaan hoeveel woorden er in een woordenboek staan?

De EFF heeft een lijst met lange woorden die je kunt gebruiken om wachtzinnen mee te genereren. Daar staan meer dan 7000 woorden op. Wil jij dus een wachtzin maken met 5 woorden, dan kom je ineens tot 7000^5 mogelijkheden die je moet proberen. En dan moet je nog rekening gaan houden met de kans dat er substituties in ziten, opzettelijke schrijfffouten, enzoverder.

[Bor]

Voor de duidelijkheid; wat Keepass weergeeft als "strength" (ik neem aan dat je daar op doelt?) is geen pure "cryptografische" entropie hè. Sterker nog; het is eigenlijk helemaal geen pure entropie. Het is slechts een schatting van de sterkte gebaseerd op diverse zaken:

KeePass uses an advanced algorithm for estimating the quality/strength of passwords. It searches for patterns, like e.g. popular passwords (based on a built-in list of about 10000 most common passwords; variations by upper-/lower-case and L33t substitutions are detected), repeated sequences, numbers (consisting of multiple digits), constant difference sequences, etc. For each pattern combination covering the whole password, the cost (number of bits required to encode the data and the order of the pattern identifiers) is calculated. For encoding pattern identifiers, an optimal static entropy encoder is used. Each single password character forms a pattern of length 1 and is encoded using a character space-dependent damped static entropy encoder. The minimum pattern combination cost is used as the final quality estimation.

Dat is dan vanaf versies KeePass 1.26 / 2.23 and newer. Daarvoor was de berekening simpeler.

Bron; Keepass

Het houdt bijvoorbeeld geen rekening met nederlandse woorden.

Wachtwoord sterkte hangt niet alleen af van de entropie.

[Reactie gewijzigd door Bor op 1 oktober 2025 18:17]

[Majhool]

Dat meneer Burr baalt van zijn eisen van destijds, betekent niet dat er meteen geupdate beleid is. De mening van 1 persoon (expert) brengt dat gelukkig niet teweeg. Maar, dat we nu wel eens over mogen naar het nieuwe beleid is wel duidelijk...

[Klauwhamer]

Dat is juist het probleem: Burr was helemaal geen (cryptografisch) expert. Hij baseerde zich op één of ander oud document uit de jaren '80 en had verder alleen maar goede bedoelingen maar nul autoriteit op dit gebied. Hij heeft dit notabene zelf ook benadrukt.

[Majhool]

ja, en hij had / heeft ook geen gelijk meer. En dat is in de afgelopen jaren doorgedrongen in de adviezen van experts (NIST) en langzaam ook bij de CISO's en nu moet het daadwerkelijk geïmplementeerd worden. Even geduld a.u.b. (helaas).

[bwerg]

Aanvullend, de welbekende XKCD komt uit 2012. En dat was ook toen echt geen nieuw inzicht.

Informatietheorie is echt al een heel stuk ouder dan dat.

Er zijn trouwens ook gewoon slimme wachtwoordcheckers die meerdere vormen van 'complexiteit' goedkeuren, op basis van entropie. Ofwel een kort wachtwoord met veel gekke tekens erin, ofwel een langer wachtwoord met minder tekens, zoals een pass phrase.

[Thijs_Rallye]

Welke XKCD bedoel je, battery horse staple of the $5 pipe wrench . Beide relevant wel.

[sympa]

Helemaal eens. En dan gekoppeld met "geen wachtwoord hergebruiken" over verschillende systemen. En "schrijf ze niet op". En dan verwachten dat iedereen sterke wachtwoorden gebruikt.

Ik denk dat de reden is dat je misbruik van in de schoenen van de gebruiker kan schuiven. De security officer zegt "mijn regels waren goed".

[heuveltje]

Dit dus echt in mijn optiek

Mijn werk is daar echt in doorgeschoten. Vanuit de LISO
Elke 6 weken wachtwoord wijzigen, voor elke (externe) account is een ander ww nodig. Meerdere verzoeken een product te koppelen aan onze MS SSO zijn afgekeurd omdat het te onveilig zou zijn. opslaan van wachtwoorden in browser kan maar heel beperkt. De (online) Wachtwoord manager is opgezegd vanwege te onveilig.

Dit allemaal om "de security te verhogen". Met als gevolg dat elke gebruiker hier een schrift in de laptop tas heeft zitten met alle wachtwoorden. Maar ja das niet digitaal, dus dat is zijn probleem niet.............

[roawser]

Ik weet niet goed wat hier nou zo nieuw aan is want in hun eigen vorige versie van dit NIST document uit 2022 stond het ook al.

[Majhool]

Nieuwe richtlijn, met oude adviezen. Mogelijk wat aanscherpingen en verduidelijkingen.

Het inzicht 'beter lang dan complex' dringt langzaam door. Dat duurt jaren. Gebruikers discussiëren liever 10 dagen over waarom een lang wachtwoord niet kan, dan dat ze 10 minuten nadenken over een langer wachtwoord.

[Reactie gewijzigd door Majhool op 1 oktober 2025 15:32]

[bazzi]

Dat dacht ik ook al. Heb toen met het CISO team van een groot Nederlands bedrijf gezeten, maar ze waren toen nog niet zo ver… Ben benieuwd of ze nu al verder zijn…

[jaxxil]

Zo nieuw zijn die inzichten ook weer niet, deze xkcd komt uit 2011.

[mjtdevries]

Waarom zou je last hebben van verplichte complexiteit als je een gegenereerd wachtwoord hebt? Dan laat je dat wachtwoord toch gewoon complex genereren? Ik kan me niet voorstellen dat er een wachtwoordmanager is die dat niet ondersteunt.

[Klauwhamer]

Het betekent een wijziging op de default. KeePass heeft bijvoorbeeld 256-bits hex keys makkelijk bereikbaar via de UI: 669FF61567F47108416A27487134A3CD43EDDB7A4C8CE424098F33132F640A03 valt dan af omdat er geen lowercase en/of speciaal karakter in zit. En dat moet je er dan weer handmatig in zetten. En opnieuw copypasten en opslaan. Onhandig. En nu dus nogmaals ook tegen de richtlijnen van NIST in.

[Bor]

Het betekent een wijziging op de default. KeePass heeft bijvoorbeeld 256-bits hex keys makkelijk bereikbaar via de UI: 669FF61567F47108416A27487134A3CD43EDDB7A4C8CE424098F33132F640A03 valt dan af omdat er geen lowercase en/of speciaal karakter in zit.

Ja, dan cherry pick je wel een voorbeeld dat niet voldoet. In Keepass kan je gewoon de eisen aanklikken in de password generator welke Keepass dan zal gebruiken voor het maken van een nieuw wachtwoord. Een Hex key bevat alleen hexadecimale getallen. Daar zit by design geen upper en lower case of andere tekens / letters bij.

Het betekent een wijziging op de default.

Wat is dan de default? Een hex key is dat niet persé. Sterker nog, de defacto "default" is nog steeds een complex wachtwoord Een hex key is slechts één voorkomende vorm.

[Reactie gewijzigd door Bor op 1 oktober 2025 15:33]

[Klauwhamer]

Goed, ik had preciezer moeten zijn: default KeePass biedt dat. En ja, KeePass biedt ook templates aan om dingen te genereren. Maar dat is helemaal niet het punt, Bor. Het punt is dat complexiteitseisen onzinnig zijn behoudens de lengte van een wachtwoord. Met een functionerende CISO worden dit soort kwesties gewoon opgepikt door ontwikkelaars en naar produktie gebracht. En ik ben niet te beroerd om te klagen hierover.

[Bor]

Je gaat veel te kort door de bocht. Een functionerende CISO kijkt naar risico's en maatregelen, classificatie van informatie etc.

Het gaat juist niet om het zo maar overnemen van een maatregel omdat Klauwhamer het zegt maar om het goed kijken wat bij de organisatie en haar gebruikers maar bij de te beschermen informatie past.

Het totale pakket bepaalt de maatregelen die je treft. Zo maar zeggen dat complexiteitseisen "onzinnig" zijn is echt véél te kort door de bocht.

[Reactie gewijzigd door Bor op 1 oktober 2025 17:17]

[Klauwhamer]

Je hebt steeds niet goed gelezen. Ik ben enorm voorstander van complexiteitseisen: lengte en/of entropie. Daarnaast: je hebt het steeds over cherrypicken maar het gaat hier specifiek om wachtwoorden en niet het totale pakket aan maatregelen. Niet doelpalen verschuiven als je anders geen punt kunt maken.

[Bor]

Lengte en/of entropie is doorgaans niet wat onder "complexity requirements" wordt verstaan natuurlijk. Het eea draagt bij aan het ander.

[Reactie gewijzigd door Bor op 1 oktober 2025 16:41]

[Klauwhamer]

Lengte wordt expliciet vernoemd (zie 3.1.1.2.)

Password Verifiers
The following requirements apply to passwords.

Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.
Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
Verifiers and CSPs SHALL NOT permit the subscriber to store a hint (e.g., a reminder of how the password was created) that is accessible to an unauthenticated claimant.
Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).

Ze is niet normatief op entropie maar er wordt geregeld naar gerefereerd en er wordt doorverwezen naar een publicatie met recommendations rondom entropie.

[Bor]

Lengte wordt expliciet vernoemd

Als onderdeel van de password verifier; "The following requirements apply to passwords"
De lengte staat er niet als complexiteitseis. Steker nog, wat we doorgaans onder complexiteit scharen komt los aan bod:

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

Lengte maakt een wachtwoord langer maar niet noodzakelijkerwijs complexer.

aaaaaaaaa -> quality 7 bits.
aaaaaaaaaaaaaaaaaa -> quality nog steeds 7 bits
a!c)fhe7@ -> quality 55 bits.

[Reactie gewijzigd door Bor op 1 oktober 2025 18:21]

[Klauwhamer]

Tsja, ik kan je verder niet helpen hoor. Je hebt gelijk. Behalve dan op Appendix A na van 800-63B. Maar hey, ik ben verzadigd.

[Reactie gewijzigd door Klauwhamer op 1 oktober 2025 17:06]

[Bor]

Lees de NIST er nog eens op na. De lengte en complexiteit / composition rules worden niet voor niets apart behandeld. Ik vind het nergens anders. In je qoute van 1 oktober 2025 16:46 toon je dit notabene zelf aan.

Vrijwel geen enkel systeem hanteert lengte als onderdeel van complexiteit.

[Reactie gewijzigd door Bor op 1 oktober 2025 18:20]

[mjtdevries]

Dat is dan vooral nogal kortzichtig van KeePass. Feit is nou eenmaal dat voorlopig nog heel veel applicatie een complex wachtwoord zullen vereisen.
Een wachtwoord manager moet je leven makkelijker maken en als er dan geen vinkje is om een complex wachtwoord te genereren dan is dat gewoon een miskleun van de wachtwoord manager.

[sympa]

En dan kleun je weer aan tegen banken die maar een beperkte set tekens accepteren, of enterprise-portals die geen komma in een wachtwoord accepteren.

[mjtdevries]

Ik gebruik Bitwaren en die gebruikt volgens mij geen kommas. Sommige tekens zijn gewoon niet verstandig om te gebruiken.
"&" wil ook wel eens geweiger worden door overijverige intrusion detection systemen. Erg handig als je bedrijfsnaam een & heeft

[Bor]

Feit is nou eenmaal dat voorlopig nog heel veel applicatie een complex wachtwoord zullen vereisen.

Klopt, het voorbeeld van Klauwhamer is ook nog eens niet de default Keepass password policy maar een standaard optie om te generen buiten de automatisch gegenereerde wachtwoorden om; een soort template voor deze "standaard".

[Klauwhamer]

Het probleem is afdwingen van stompzinnige complexiteitregels die meer kwaad dan goed doen. Je moet niet de boel gaan omdraaien of je wentelen in "het is nou eenmaal zo". Het is zorgplicht goede authenticatie te faciliteren en dat doe je níet met complexiteitseisen anders dan een minimale lengte. En daar is de kous mee af.

[Bor]

Het is zorgplicht goede authenticatie te faciliteren en dat doe je níet met complexiteitseisen anders dan een minimale lengte.

Veel te kort door de bocht wat mij betreft. Goede authenticatie zoekt een balans tussen veiligheid en gebruiksgemak waarbij de mate van veiligheid recht moet doen aan de waarde van de informatie die je beschermt. Het is uiteindelijk een risico analyse; zo zal je top geheimen zwaarder willen beveiligen dan informatie met weinig waarde. Bij de bescherming van informatie met hogere waarde kan je strengere eisen stellen.

[Klauwhamer]

Het ging hier om wachtwoorden -als onderdeel van authenticatie-. Prima dat jij 't breder wil trekken dan dat, maar dat maakt niet dat mijn stelling te kort door de bocht is. Dat is slechts het gevolg van eenzijdig een bredere scope toepassen -- wat je overigens ook niet specificeert anders dan holle bijvoegelijk naamwoorden.

[mjtdevries]

Dan wens ik je veel geluk met je gelukzalige gevoel dat jij het bij het rechte eind hebt en de rest van de wereld stompzinnig is, maar waarbij je vervolgens dan handmatig je gegenereerde wachtwoord moet aanpassen omdat je manager niet de moeite heeft gedaan om die hele simpele functionaliteit te bouwen.

[Blokker_1999]

Maar dan moet je alweer weten dat die gebruiker Keepass gebruikt en dit type van wachtwoorden laat genereren, anders heb je er ook weer niets aan.

[Sissors]

Ik heb gehad dat ik met Chrome wachtwoord manager meerdere wachtwoorden moest genereren, of zelfs het uberhaupt niet lukte om aan de complexiteit te komen. Er moesten meerdere cijfers in het wachtwoord zijn (dus niet één, maar minstens twee, die lukte dan na meerdere pogingen).

[mjtdevries]

Zo'n voorwaarde voor complexiteit ben ik gelukkig nog nooit tegen gekomen. Wie verzint zoiets?
Als een enkel cijfer als volgnummer niet geaccepteerd word, dan gebruik je toch gewoon een dubbel cijfer?

[PhilipsFan]

Omdat veel sites ook nog allerlei idiote eisen toevoegen, waarvan de meeste de complexiteit juist verminderen.

• Soms is het gegenereerde wachtwoord te lang
• Soms bevat het gegenereerde wachtwoord speciale tekens die niet mogen
• Soms wil een site speciale tekens die de wachtwoordmanager niet wil gebruiken
• De eisen voor complexiteit zijn niet overal gelijk

Bovendien is 'verplichte' complexiteit geen complexiteit. Het is een misverstand dat het verplicht gebruik van een hoofdletter complexiteit toevoegt. Integendeel, als 1 karakter verplicht een hoofdletter moet zijn, dan is de complexiteit juist minder.

Check het volgende eenvoudige voorbeeld van een wachtwoord van 2 karakters (hoofd- of kleine letters). Je hebt dan (26x2)*(26*2) = 2704 mogelijkheden. Moet een karakter verplicht een hoofdletter zijn, dan heb je nog maar (26*2)*26 = 1352 mogelijkheden. De complexiteit volgt juist uit het feit dat karakters hoofdletters MOGEN zijn, maar je niet weet of dat daadwerkelijk het geval is.

Hetzelfde geldt voor leestekens, daarvan zijn er 30 (als ze allemaal mogen, sommige sites staan er slechts 10 toe), dus een verplicht leesteken leidt nog steeds tot een verlies aan totale complexiteit.

[mjtdevries]

Wat voor wachtwoord managers gebruiken jullie dat simpele features zoals het bepalen hoe lang het gegenereerde wachtwoord mag zijn, niet ingebouwd zijn? Dat is echt het simpelste dat je kan bedenken als je een tool bouwt die wachtwoord kan genereren.

Integendeel, als 1 karakter verplicht een hoofdletter moet zijn, dan is de complexiteit juist minder.

Je kunt mij niet wijsmaken dat je ooit een situatie tegen bent gekomen waarbij je 1 maar dan ook maar alleen 1 hoofdletter mocht gebruiken. Het is altijd "minimaal" 1 hoofdletter en dan voegt het wel degelijk complexiteit toe.

En een verplicht leesteken voegt wel degelijk complexiteit toe, aangezien dat betekent dat je voor elk tegen van het wachtwoord die 30 tekens ook moet meenemen.
Als het 1x 1 leesteken in het wachtwoord zou zijn, dan zou je gelijk hebben. Maar dat is nooit wat vereist word.

[PhilipsFan]

Ik gebruik de ingebouwde functie van iOS om wachtwoorden te genereren en bewaren bij het registreren op een website. Die gebruikt hoofd- en kleine letters, cijfers en het streepje als leesteken. Ik heb al meegemaakt dat sites dat niet voldoende vonden, die wilden een 'echt' leesteken.

Dat laatste wat je zegt, klopt niet. Een _verplicht_ leesteken vermindert de complexiteit juist, omdat je minder mogelijkheden hebt. Wat jij (vermoedelijk) bedoelt, is dat de _mogelijkheid_ van leestekens de complexiteit vergroot, maar dan moeten gebruikers die wel regelmatig gebruiken.

[mjtdevries]

En omdat gebruikers die leestekens niet gebruiken tenzij je het verplicht stelt, zorgt het verplichten van een leesteken dus juist wel voor meer complexiteit.
Jij gaat uit van de zuiver theoretische situatie, ik ga uit van de praktijk.

[PhilipsFan]

Je hebt wel gelijk, als je het niet verplicht stelt, dan doen gebruikers het niet. Maar als je het wel verplicht stelt, dan doen gebruikers gewoon een uitroepteken achter hun reeds bestaande wachtwoord en heb je alsnog geen extra complexiteit.

Wachtwoorden zijn gewoon niet meer van deze tijd.

[mjtdevries]

Als hacker zou ik er vanuit gaan dat de laatste 3 tekens van een wachtwoord bestaan uit twee getallen voor het tellertje en een leesteken. En dan kan het leesteken voor of achter het tellertje staan.

Uiteraard geen idee of dat werkelijk zo is, maar ik zou echt niet verbaast zijn als dit voor héél veel wachtwoorden geldt.
En de hoofdletter zal vaak ook beperkt zijn tot het eerste teken van het wachtwoord.

Dan nog kun je je afvragen bij hoeveel hacks er nou echt sprake van is geweest dat een zwak password gehacked is.
Als ik de zaken kijk die in het nieuws komen, dan is het vrijwel altijd dat een password gecompromiteerd is door phishing of iets dergelijks en niet door brute-forcing en zelfs niet door dictionary attacks.

Dus wellicht zijn wachtwoorden niet meer van deze tijd, maar is je zorgen maken dat ze op dergelijke wijze gehacked worden ook niet meer van deze tijd?

[Skit3000]

Het beste wachtwoord is een wachtwoord dat uniek is. Ik denk dat die regeltjes zijn ingevoerd om mensen zo ver te krijgen een uniek wachtwoord te bedenken, maar in de praktijk gebruiken ze daarna datzelfde wachtwoord overal.

Misschien is de beste oplossing nog wel als sites de ingevoerde wachtwoorden (gehasht) publiceren. Op die manier kan elke andere website controleren of een wachtwoord al eens gebruikt is, en daarmee gebruikers dwingen iets echt unieks te kiezen.

[Klauwhamer]

Een wachtwoord hoeft helemaal niet uniek te zijn. Als jij een sleutel op straat vindt, heb je alsnog precies niets zonder corresponderende voordeur, waar ook nog 'ns MFA op kan zitten in de vorm van een portier die je gezicht kent.

[Reactie gewijzigd door Klauwhamer op 1 oktober 2025 14:24]

[japie06]

Vaak zijn huissleutels ook niet zo uniek. Sommige merken hebben maar misschien 10-12 varianten.

[player-x]

Vaak zijn huissleutels ook niet zo uniek. Sommige merken hebben maar misschien 10-12 varianten.

Dat valt ook wel weer mee, want er zijn zoveel verschillende merken, met nog eens een berg verschillende types, dat het nog steeds wel heel toevallig moet zijn dat dat je met de gevonden sleutel het juiste slot vindt.
Vesper (25), M&C (151), Nemef (43), Mauer (96), DOM (248), EVVA (43), Iseo (20), Pfaffenhain (20), ABUS (40), AXA (33), Mul-T-Lock (27)

[sympa]

Nou,een huisslot heeft 5 of 6 pennetjes. Elk pennetje heeft iets van 5 verschillende mogelijke hoogtes. Ze mogen natuurlijk niet allemaal gelijk. Dan heb je tussen de 1000 en 5000 mogelijkheden.

[Skit3000]

Klopt, maar hier past diezelfde sleutel Welkom1! met jouw mailadres in elk slot (bankzaken, email, online opslag, webshops, etc). Zijn je gegevens dus eenmaal ergens gelekt, kan je er van uit gaan dat je gegevens bij al die andere diensten ook uitgelezen zijn.

Als wachtwoorden uniek zijn per persoon voorkom je dat, maar dat kan je natuurlijk niet afdwingen (want hoe kan de Wehkamp weten welk wachtwoord jij hebt gebruikt toen je je vakantie naar Turkije boekte bij Tui). Globale unieke wachtwoorden kan je wel afdwingen, door ze gewoon allemaal te publiceren (gehasht, zonder het betreffende mailadres er bij).

Technisch gezien zijn globale unieke wachtwoorden dus de beste oplossing, zolang we op deze wereld nog wachtwoorden blijven gebruiken (want er zijn betere oplossingen).


Toevoeging: Unieke wachtwoorden forceren zorgt er natuurlijk wel voor dat mensen die wachtwoorden niet kunnen onthouden en op gaan schrijven. Dat is natuurlijk ook niet optimaal, maar een wachtwoordmanager of zelfs gewoon een stuk papier met daar al je wachtwoorden in wordt waarschijnlijk veel minder snel gestolen dan datzelfde wachtwoord dat je op honderden sites gebruikt.

[Reactie gewijzigd door Skit3000 op 1 oktober 2025 14:34]

[player-x]

Heb ergens gewerkt waar ze beveiliging echt heel serieus namen, als je daar naar binnen wou, moest je een badge, vingerafdruk en in een camera kijken voor gezichtherkenning, en dat kostte je 3sec extra om binnen te komen.

En om in te loggen op een werk PC, gebruikte je een simpele niet veranderende 8 teken paswoord + badge en vingerafdruk, goede beveiliging hoeft dus helemaal niet extreem complex en omslachtig te zijn.
Beveiligd met iets dat je weet, iets persoonlijks dat je niet kan veranderen en iets dat je hebt.

En voor privé, Bitwarden + biometrics werkt ook prima op mobiel of PC, en een vingerprintlezer koop je al voor €15, en werkt ook nog eens prima met Windows Hello, er is niets gebruiksvriendelijke dan biometrics, en een stuk veiliger dan paswoorden.

Zelf gebruik Bitwarden plus een stel Yubikey's, om alles veilig te houden.

[Thijs_Rallye]

Ik voel er weinig voor mijn biometrics te delen met Microsoft. Dat het makkelijk is geloof ik meteen.

[player-x]

Je biometrics blijven gewoon lokaal hoor, op je eigen machine, net als op je telefoon, daar zijn twee goede redenen voor.

1. Een kopie van je vingerafdruk heeft veel lagere waarde voor MS, tegenover de potentiële PR klachten.
2. De GDPR-regelgeving en potentiële boetes beschermt je tegen misbruik.

Bij dat bedrijf dat ik werkte, daar gebruikte ze wel een biometrisch server, en ze ze hadden een TDLR met precies wat ze met de data deden, en ik kon een kopie krijgen van hun belijd, hoe ze aan wettelijke privacy wetgeving voldeden.

De overheid neemt biometrisch data best serieus, ik weet van een bedrijf waar ze hun vingerafdruk in-klok systeem geheel moesten veranderen, om aan de wet te voldoen.

Maar als je MS toch niet er mee vertrouwd, een Yubikey is een prima en veilig alternatief, gebruik het zelf ook, maar voor andere praktische redenen.

[Thijs_Rallye]

Dank je wel voor de toelichting.

[karelvandongen]

Alleen vraag ik me dan wel af hoe goed de rest van de beveiliging was. Want wat je vaak ziet, is dat dan bv de schoonmaaksters een algemeen pasje hebben, omdat die toch niet van belang zijn in de ogen van veel managers.. Of dat er een algemene toegang is voor alle service personen. Of voor bezoekers. Omdat by dit soort groepen de toegang vaak maar zeer tijdelijk is, wordt er heel vaak niet goed over na gedacht hoe dit in te regelen. Veel echte hackers/crackers komen dan ook als bv monteur van kpn aanzetten . Na bijvoorbeeld eerst een naam van een werknemer te hebben opgezocht etc.

[player-x]

Laat ik het zo zeggen, je komt daar echt niet binnen, als je daar niks te zoeken hebt, en zonder bewijs van goed uitmuntend gedrag, collega was daar geweigerd na een vrijwillig/verplicht onderzoek van Buro Jansen & Janssen (hij had te veel schulden), terwijl hij wel bij de kerncentrale Borssele binnen kwam.

En en voor elke ruimte moest je minimaal badgen, overal camera's waarmee ze controle hielden, en in server en R&D ruimtes hadden we bewaking bij ons, en als we dingen aan hun systemen koppelde, was dat altijd in samenwerking met/door hun IT, het ging zelfs zo ver dat de kantine een aparte contractors gedeelte had, waarschijnlijk tegen het overhoren van shop talk.

Dus ja, in NL hebben we ook bedrijven met paranoïde top level geheimen.

[Robtimus]

Wachtwoorden publiceren heeft denk ik weinig zin. Vaak worden wachtwoorden gehast opgeslagen (bcrypt, etc.). De plain-text waarde kan dan niet meer makkelijk worden achterhaald. Maar als die hash goed is geimplementeerd is die ook uniek, omdat er een nieuwe salt voor elk gebruik voor wordt gebruikt (zie b.v. https://www.php.net/manual/en/function.password-hash.php, sinds PHP 8 wordt een expliciete salt zefs genegeerd). Hetzelfde wachtwoord "Welkom01!" heeft dan voor elk account toch een unieke hash.

[Skit3000]

Alleen bepaal je als eindgebruiker niet hoe een dienst jouw wachtwoord op slaat. Als de standaard is om deze dmv een bepaald algoritme te hashen én de uitkomst hiervan te publiceren, dan forceer je direct ook het veiligheidsniveau.

[WargamingPlayer]

Daarom is het ook van belang om lange wachtwoorden te gebruiken. Helaas zijn er nog omgevingen waar bijvoorbeeld spaties niet zijn toegestaan of leestekens als eerste letter.

Zelf werk ik het liefst met zinnen. Bijvoorbeeld: “Ik koop liever bij Amazon dan bij jullie!” Of “‘t is wel een hele mooie webshop.”

[desalniettemin]

In een passphrase gebruik ik bestaande woorden en verhaspel die. Wachtkamer, wordt dan wagdcaamur of hele rare woorden zoals bv kavoggeldieboeswacker, of skahelmiedietute.

[Reactie gewijzigd door desalniettemin op 1 oktober 2025 15:59]

[pimlie]

Een betere manier is om de entropie te berekenen en een minimaal aantal bits te vereisen. Formule is:

Entropie = log2(poolGrootte ^ lengte)

Waarbij poolGrootte het aantal mogelijke karakters is. Dus [a-z] = 26 en [a-zA-Z0-9] is 62. Voor leestekens kan je 32 aanhouden.

Welkom01! heeft dan een entropie van 59 bits, en DitIsMaarEenVoorbeeldVanEenPassphrase heeft 211 bits.

Zie bv hier voor een online tool en bits vereisten voor sterke/zeer sterke wachtwoorden: https://nowcalculate.com/other/password-entropy-calculator

-- edit --
Nog beter is waarschijnlijk om een van de zxcvbn bibliotheken te gebruiken. Zie bv: https://github.com/zxcvbn-ts/zxcvbn

[Reactie gewijzigd door pimlie op 1 oktober 2025 18:48]

[mjtdevries]

Gaat de berekening er dan vanuit dat je elk teken gaan bruteforcen, of houdt die er ook rekening mee dat je bij passphrases bestaande woorden gebruikt en dat nog steeds tot heel veel mogelijkheden leidt, maar toch aanzienlijk minder entropie?

[pimlie]

Als je je daar zorgen over maakt, dan zou je dus inderdaad als poolGrootte het aantal woorden in het nederlands en/of engels kunnen nemen en als lengte het aantal woorden. Nederlands kent ongeveer 275.000(?) woorden, dan zou de entropie op 145 bits uitkomen voor het voorbeeld indien je willekeurige woorden zou gebruiken. Als je een echte zin gebruikt zoals in het voorbeeld hier, dan zal dat nog minder zijn als je rekening gaat houden met de kans dat 2 woorden elkaar opvolgen.

Daarom is correcthorsebatterystaple wellicht beter als voorbeeld. Liefst ook nog ergens een hoofdletter, een leesteken bv als koppelteken, of een voor jou logische/unieke maar afwijkende spelling.

[Sissors]

En was de reden om die irritante wachtwoordeisen mee te komen. Die moeilijk voor mensen te onthouden zijn en makkelijk te kraken zijn. Welkom01! heeft absoluut geen 59 bit entropie. Ja als je blindelings gaat bruteforcen. Maar een dictionary attack, plus voeg toe dat veruit de meeste mensen de eerste letter een hoofdletter doen om aan de hoofdletter eisen te voldoen, plus dat een uitroepteken aan het einde ook niet echt origineel is, en dat ding is in no time gekraakt. Plus dat volgens Nordpass dat ding al 93000 keer gelekt is!

Vroeger weleens een website gehad die helemaal liet zien hoe je wachtwoord het snelste gehackt kon worden (als in, iets kwam uit een woordenboek, daar kwam dan bovenop standaard substituties, etc). Die kan ik niet meer vinden, maar deze komt in de buurt: https://www.passwordmonster.com/

En dan om het in het Engels te houden: Welcome01! geven ze 19 seconde voor. Zonder dat uitroepteken is het 5 seconde, dus tja, leuk om door wachtwoordeisen te komen, maar meer ook niet. Doe je bijvoorbeeld Welco!me01, dan is het 1 jaar! Want dan zit je niet in standaard dictionary attacks. W3lcome01! maar er een minuut van, want een standaard vervanging. W2lcome01! is 2 maanden, want geen standaard vervanging.

En fwgqacvteg is exact even lang, alleen lower case, oftewel alle alarmbellen gaan af. Alleen die is nu 43 jaar, want daar werkt een dictionary attack niet tegen.

[pimlie]

Je hebt gelijk, heb mijn post geupdate.

De standaard bibliotheek om bij de entropie berekening ook rekening te houden met dictionary attacks lijkt zxcvbn te zijn

[BasSchouten]

De passphrase die je daar noemt heeft ook geen hele hoge entropie en is niet heel goed bestand tegen complexere dictionary attacks.

Maar het belangrijke punt is denk ik wachtwoord managers. Ik erger me dus mateloos aan sites die alleen 'bepaalde' speciale tekens accepteren... Want dan moet ik mijn password manager weer fine tunen. Laat password managers gewoon hun werk doen.

Mijns inziens zou dat het advies moeten zijn - iedereen leren werken met password managers.

[Klauwhamer]

169 bits volgens KeePass. Volgens mij adviseren de meeste bronnen minimaal 60 bits entropie -- waar ik geen fan van ben omdat het makkelijk in triple digits te krijgen is. Voorts diende het slechts als voorbeeld, waar "Welkom01" maar liefst 55 bits entropie geniet volgens KeePass.

[BasSchouten]

Ik zou me kunnen vergissen maar ik vermoet dat die 169 bits geen rekening houdt met dictionary attacks. Welcome01 is namelijk ook vele male minder dan 55 bits in de praktijk.

[JumpStart]

Om nog maar te zwijgen over "HOOO! Er mag géén spatie in het wachtwoord zitten!!!111"

Want toestaan van spaties maakt het daadwerkelijk wachtzinnen en dragen bij aan de complexiteit. Daar zou iedere back-end gewoon goed mee om moeten kunnen gaan.

[Stoney3K]

Ik vind beveiligingsvragen nog veel meer een draak van een systeem, vooral omdat ze vaak heel ongelukkig zijn gesteld en brak zijn geïmplementeerd.

Zo kan ik mijn PayPal account niet meer in omdat ik mijn wachtwoord nog wel weet, maar PayPal heel hardnekkig wil weten wat ik 15 jaar geleden heb ingevuld als mijn favoriete huisdier, case sensitive.

[Reactie gewijzigd door Stoney3K op 1 oktober 2025 15:32]

[Zebby]

Nog irritanter zijn websites met een cap op MAXIMUM, of in ieder geval een max die lager is dan bv 128/256 karakters. ING had heel lang een max van 20, zo te lezen is dat nu 160 geworden gelukkig.

https://www.ing.nl/de-ing/veilig-bankieren/5-bs/hoe-sterk-is-jouw-wachtwoord

Ja je wilt een maximum zodat grapjassen niet The Bee Movie als script uploaden. Wel leuk is om te testen met bijvoorbeeld een emoticon. In principe moet dat gewoon kunnen. Zo niet kun je nog testen of je langs de front-end checks kan komen, of de back-end het wel wilt accepteren.

Heb bij XS4ALL een keer een bug gehad dat hij in de front-end het wachtwoord afsneed na X karakters bij inlog, maar in back-end wel vol had opgeslagen.

[mjtdevries]

Die bug ben ik ook tegengekomen bij meerdere banken die maar 8 tekens accepteerden. En dat was helaas niet erg lang geleden.

[Vaevictis_]

Of een gegeneerd complex wachtwoord van 25 tekens "mag max. 12 tekens lang zijn".

Why??

[teek2]

Het is nog erger als je er niet doorheen komt met je 32 random tekens, en daarna blijkt dat ze hem afkorten to 16 of 12. Ik heb het een paar keer meegemaakt, maar durf niet meer te zeggen wat het was.

Hoe dan ook, ze salten en hashen dan niet, want dan zou elk opgeslagen wachtwoord dezelfde lengte hebben en zou het niks uitmaken.

[dragon2]

Yup. Greenchoice ineens van de week. Lastpass, niet goed. Grrr.

[magician2000]

Vergeet niet de wachtwoordlengte die bij een (flink?) aantal website bijvoorbeeld maximaal 12 mag zijn. Iets wat een grote beperking is in de complexiteit van een wachtwoord/phrase.

[Blokker_1999]

Of nog een belangrijke, een maximale lengte. Hoezo mag mijn wachtwoord niet langer dan 25 karakters zijn? Waar komt die arbitraire limiet vandaan? Jij wil dat ik mijn persoonlijke data bij jouw kom opslaan, maar je biedt me niet eens de mogelijkheid voor een veilig wachtwoord?

[Mushroomician]

Waarom maximaal 64?
Ik snap best dat er niet veel winst is te behalen vanaf deze lengte, maar is meer dan direct onveiliger?

[aikebah]

Niet maximaal 64, maar 'als je een maximum hanteert dan moet dat maximum minimaal 64 zijn'

edit:
En voor waarom een maximum: denk je eens in hoeveel extra tijd je nodig gaat hebben voor het hashen van een 1TB wachtwoord om hem te kunnen controleren tegen de opgeslagen secure hash. Bij een bepaal maximum kun je iedere inlogpoging langer dan maximum voor wachtwoord gewoon meteen afkappen zonder moeilijk rekenwrk.

[Reactie gewijzigd door aikebah op 1 oktober 2025 21:13]

[baseoa]

"niet veel", nou ja, zeg maar niks. Boven de 21 willekeurige tekens is er eigenlijk niks willekeurigers meer want je hebt dan al meer energie nodig om de md5 van zo'n wachtwoord te kraken dan de zon opwekt in een jaar. Of zoiets was het. Iig zijn 128 bits willekeurigheid altijd voldoende met huidige technieken

Nou is het niet nuttig om een limiet op 21 te zetten omdat mensen lang niet altijd willekeurige tekens gebruiken, maar bij de 64 zit je niet meer aan iets dat iemand serieus gaat intikken (ook niet met een wachtwoordzin), en als je het toch al copy-paste, kun je ook willekeurige tekens gebruiken

Überhaupt een limiet hebben is tegen DoS-aanvallen

[Reactie gewijzigd door baseoa op 1 oktober 2025 21:46]

[NostraDavid]

Dat zal meer zijn omdat hashen natuurlijk wat CPU gebruikt, en er zal IEMAND zijn die het grappig vindt om er 1GB aan tekst in te rossen. Dat, en het netwerk krijgt dat ook te verduren, en het geheugen, etc.

Ik gok dat 64 karakters genoeg is dat het effectief onkraakbaar is (ja ja, liggend aan hashing algo, en of er een salt wordt gebruikt, etc... maar je weet wat ik bedoel).

[enetrati]

Ik vind het nog steeds apart dat er nog steeds gesproken wordt over wachtwoorden. Waarom niet gewoon het advies voor hardware-based authenticatie zoals Yubikey? Dan ben je als individu en als organisatie van het gezeur af.

[Ventieldopje]

Het hoeft tegenwoordig niet eens meer echt hardware based te zijn en is het redelijk eenvoudig om Passkeys te implementeren. Die kun je opslaan op een hardware token, maar ook in je password vault of waar dan ook.

[bzuidgeest]

Dit is advies voor wachtwoorden wanneer je deze gebruikt. Nog meer dan genoeg applicaties die dat als enige optie hebben.

Hardware based met yubi ondersteuning is maar een minderheid. Dat is nog buiten de kostprijs van de hardware. Twee keys voor elke gebruiker, plus de veilig opslag van de tweede key. (de tweede key om bij data te kunnen als de eerste kapot gaat)

Als je geen wachtwoorden meer hebt in je organisatie dan kan je dit advies dus negeren. Dan is het niet voor jou.

[CH4OS]

Omdat hardware keys ook weer hun nukken hebben. Kwijtraken is daar een voorbeeld van, vooral als de hardware key in verkeerde handen valt. Ik denk dat passkeys en biometrie dan beter werken.

[-Vasa-]

Omdat dit voor grote organisaties die dit moeten implementeren voor hun volledige populatie enorm duur is.

Als dit al wordt afgedwongen is dit vaak slechts voor het gepriviligeerde deel van de gebruikers zoals managers, HR-medewerkers en natuurlijk IT-mensen.

De aanschafkost voor de hardware is op dat vlak dan nog niet eens het meest zware, maar de voortdurende ondersteuning die nodig gaat zijn om bijvoorbeeld een arbeiderspopulaite van 4000 mensen te ondersteunen die naar hun planning moeten kunnen kijken om te zien in welke shiften ze staan bijvoorbeeld.

[Blokker_1999]

De kost is het probleem niet. We geven je elke paar jaar een laptop van 1000+ Euro, we geven je elke paar jaar een nieuwe telefoon, je rijdt met een wagen van de zaak. Denk je echt dat een security key van enkele tientallen Euro dan ineens een dealbreaker gaat zijn?

Nee, het zit hem meer in de praktische kant van de zaak. Nog te veel software dat er niet mee werkt bijvoorbeeld. Als je niet volledig wachtwoordloos kunt gaan, wees dan voorzichtig of je gaat de druk op je helpdesk net sterk verhogen.

[-Vasa-]

De niet-hardware kost is toch wat ik zeg dat het duurste zal zijn? Dat dat in het niets valt is relatief naturlijk, niet iedere medewerker bij een groot bedrijf heeft een laptop van het werk, maar wordt wel verwacht in te kunnen loggen op een aantal platformen via hun eigen toestellen. (Al is vaak dan ook syndicaal geregegeld dat er punten zijn waar mensen dit kunnen nakijken via kiosken e.d.)

[Memori]

Daarmee scrap je het hele "something you know" factor van toegangscontrole. Je kan het wel combineren met (simpele) wachtwoorden of PIN-codes.

[Caayn]

Dit advies geldt toch al een tijdje? Woordenboekwoorden daargelaten maar voor een computer maakt het geen zak uit of een teken "1", "!", "i" of een"l" is. Maar voor het onthouden van het wachtwoord, en derhalve zwakker maken/geitenpaadjes (post-its, hergebruik etc.) maakt het veel uit.

Wachtwoordmanagers heb je uiteraard maar daar heb je pas toegang toe nadat je bent ingelogd en op sommige omgeving/bedrijven kan dat best een paar accounts verder zijn voordat je een wachtwoordmanagers kan opstarten.

[Reactie gewijzigd door Caayn op 1 oktober 2025 14:14]

[Majhool]

Dit advies is aangevuld met een advies over beveiligingsvragen en hints. Voor het gebruik van 'rainbowlists' en 'brute force' maakt het wel uit of je diakritische tekens gebruikt. Maar, de lengte van het wachtwoord is veel belangrijker, dus 'lange wachtwoorden' (zinnen) is nu het advies.

Ik twijfel over het aanbevelen van wachtwoordmanagers, het is niet heel gebruikersvriendelijk (denk aan digibeten) en het is een digitaal sleutelkluisje. One key to rule them all... niet per se veilig.

[R_Zwart]

Dat laatste inderdaad. Zeker als je dan ook "lekker makkelijk" een online passwordmanager gebruikt. Als je het al gebruikt dan zou je het eigenlijk op een apparaat moeten bewaren zonder internettoegang. En dan noemen we het gewoon een notitieboekje. Ik denk eerlijk gezegd dat een papieren boekje voor de overgrote meerderheid het veiligst is. De meeste mensen zijn niet zo belangrijk dat er fysiek ingebroken gaat worden voor een boekje. En als het dan nog een beetje slim opschrijft in een boekje dan werp je nog een extra hindernis op voor als iemand het toch in handen krijgt.

[to01]

Ik denk dat een Caesar cypher (+/-1) voor de meeste inbrekers/spiekers niet gespot wordt, helemaal als je wachtwoorden met willekeurige tekens gebruikt. vereist natuurlijk wel een beetje gezeik wanneer je het zelf moet lezen :p

[sympa]

Rainbows kunnen prima meenemen dat een l een 1 wordt, of een e een 3. Je maakt het wel ietsje beter als je Nederlandse woorden neemt in je phrase, en als je er verbasteringen of spelfouten in stopt.

[trab_78]

Ik ben het niet eens met je opmerkingen over wachtwoordmanagers. Ja, het opzetten is even wat werk, maar daarna is inloggen op een willekeurige website echt wel gebruikersvriendelijk. Ook het aanmaken van een nieuw wachtwoord gaat best makkelijk.

En wat betreft One key to rule them all: ja, als je passwordmanager gekraakt wordt, heeft met alle wachtwoorden. Maar passwordmanagers zijn niet makkelijk te kraken, het is namelijk hun core business. Dus die zullen echt wel zorgen dat ze hun zaakjes op orde hebben. Het alternatief is voor de meeste mensen overal hetzelfde wachtwoord gebruiken. Dus effectief heb je dan ook One key to rule them all...

[Majhool]

Ik geef aan dat ik twijfel. Voor digibeten is 'inloggen' en 'website' al een probleem en het aanmaken van een wachtwoord al helemaal. Van hen wordt wel verwacht dat ze inloggen bij overheid, zorg en de klaverjasvereniging.

Ja en het is makkelijk om te verkondigen dat het vast een keer misgaat bij zo'n password manager. Maar het gaat vast een keer mis.

En het gaat ook wel mis / er zitten kwetsbaarheden in:

https://www.agconnect.nl/business/security/passwordmanagers-lekken-wachtwoorden-via-clickjacking(Dit kan ook zonder 'autofill' natuurlijk)

En: In 2022 werd LastPass getroffen door een ernstige hack waarbij backups van kluisdata werden gestolen. Hoewel de data versleuteld was, konden metadata en URL’s van opgeslagen accounts worden ingezien. Dus even wachten op Q-day.

[trab_78]

Klopt natuurlijk. Maar als je dus overal hetzelfde wachtwoord gebruikt, is de kans veel groter dat dat uitlekt. Want er is elke dag wel een datalek bij een webshop, klaverjasvereniging of (semi)overheidsinstelling. En als de combinatie van jouw email en dat wachtwoord bekend is, kunnen hackers dat makkelijk proberen op 100 andere websites. Reden genoeg dus om voor elke website een ander wachtwoord te gebruiken. M.i. is de enige realistische manier waarop je dat kan doen met een password manager.

[Majhool]

Ik doe het zonder. Ik gebruik een onderdeel van de naam van de website / dienst in een eigen zin met een variabele. Maar dat kun je ook niet verwachten van digibeten. Misschien moeten we helemaal van dat wachtwoord af

[trab_78]

Eerder noemde je gebruikersvriendelijkheid als argument tegen password managers. Maar jouw methode is toch echt nóg minder gebruikersvriendelijk.

Dat gezegd hebbende: eens dat wachtwoorden een verre van ideale oplossing zijn. Ik heb alleen het idee dat het ideale alternatief nog niet gevonden is.

[Majhool]

ehm... dat zei ik toch ook

Passkeys (maar dan wel zuiver)

[trab_78]

Passkeys hebben in de huidige implementaties precies hetzelfde probleem als passeordmanagers.

[Majhool]

Nee, dat verschilt fundamenteel. De harde koppeling met een 2e factor, op de achtergrond, maakt het een stuk veiliger en gebruiksvriendelijker. Een passwordmanager is een sleutelkluisje en kan prima zonder 2FA.

[trab_78]

Dus als het wachtwoord van mijn passwordmanager uitlekt, dan kan iemand nog steeds niet mijn passkeys eruit halen en inloggen ermee?

[Majhool]

Passkeys zijn een 'sleutelpaar' en staan in principe niet in je password manager. Eén sleutel staat bij de website of dienst, de andere op jouw apparaat. Die lokale sleutel is beveiligd met bijv. biometrie. Je hebt beide sleutels nodig om binnen te kunnen komen. Bij het inloggen wordt een ‘uitdaging’ verstuurd naar je apparaat, dat met de privésleutel een antwoord ondertekent. Zo wordt je identiteit bevestigd zonder dat je een wachtwoord invoert.

[trab_78]

Passkeys zijn een 'sleutelpaar' en staan in principe niet in je password manager.

Ik heb 2 passwordmanagers op mijn systeem: 1Password (voor mijn werk) en Bitwarden (privé). Beiden slaan passkeys op en loggen me automatisch in op sites die passkeys gebruiken.

[Majhool]

Dat zijn denk ik niet de passkeys die ik bedoel. De 'nieuwe' methode gebruikt twee sleutels, waarvan één hardware sleutel (dus in een veilige chip op het device, of een externe (FIDO) chip)

[Majhool]

Ik heb even gezocht, 1Password kan inderdaad de passkeys opslaan. Qua veiligheid heeft het niet zoveel toegevoegde waarde, maar het zorgt er wel voor dat je overzicht hebt en dat je makkelijker kunt overstappen naar andere hardware.

[Klauwhamer]

De eerdere publicatie komt te vervallen door deze (800-63B (3.1.1)).

[Stoney3K]

Windows 2000 en 2003 Server hadden zelfs in het verleden de beperking dat wachtwoorden een maximumlengte hadden van 12 karakters.

Maar misschien was dat wel van voor de periode dat mensen al het juiste-paard-batterij-nietje hadden gevonden.

[Reactie gewijzigd door Stoney3K op 1 oktober 2025 15:35]

[Pinkys Brain]

Als je wachtwoord database gejat is heb je iets heel goed fout gedaan. Mag alleen maar gebeuren als de sysadmins hun laptops geroot zijn of er een zeroday in de SSH server zit.

De interface van een password server kan zo miniem zijn, dat daar geen fout in mag zitten en de SSH login gegevens en backup decryptie keys voor die server horen alleen maar in yubikeys of offline te bestaan.

Voor dit soort gegevens moet je gewoon extreem paranoide wezen, gemak dient de hacker. Als de passwords nog steeds in een grote database zitten met de rest van je website data wachtend op de eerste SQL injectie, doe je het fout.

[FrankHe]

Tegen een zeroday in je server kun je inderdaad niets beginnen, maar gelukkig is de kans daarop relatief gering. De kans is veel groter dat een programmeur verkeerde dingen heeft zitten bouwen in de business logica en de manier waarop gevoelige data word opgeslagen.

Iemand die tegenwoordig nog code schrijft die gevoelig is voor SQL injectie moet verplicht terug de schoolbanken in. Dat en vijftienjarige zo'n fout maakt in een schoolwerkstuk is nog tot daaraan toe, maar zodra je spullen codeert die daadwerkelijk in productie gaan dan mag daar simpelweg geen SQL zwakheid meer in zitten.

Een ander punt is social engineering, mensen binnen je organisatie die interne procedures niet serieus nemen en zonder na te denken gevoelige informatie weggeven. Dat is per definitie de zwakste schakel van iedere organisatie.

[Pinkys Brain]

SQL injectie blijft voorkomen, want ja ... alles met prepared statements is veels te moeilijk en een nieuwe manier om daarzonder SQL injectie toe te laten, die heuristics of zelfs AI niet zien aankomen heel makkelijk. Voor jouw niet misschien, maar al die anderen. Even gekeken, Fortiweb had er twee maanden terug nog een, zonder authenticatie ook.

Je moet realistisch zijn over programmeurs, ze blijven dezelfde fouten maken omdat bepaalde fundamentele zaken in IT zoals het gebruik van plain text APIs waar externe parameters als text worden doorgegeven blijven bestaan (SQL, shell, printf, en zelfs HTML, het is zo ingeburgerd dat praktisch niemand zelfs maar het fundamentele probleem kan onderkennen). Het vraagt onmenselijke discipline om het niet fout te doen en het leid tot zeer makkelijke exploits.

Daarom moet je compartmentaliseren en extreem paranoide zijn voor de belangrijkste data, waar passwords toch wel bij horen.

[Reactie gewijzigd door Pinkys Brain op 1 oktober 2025 22:20]

[FrankHe]

Zelfs met gebruik van prepared statements is het mogelijk om slechte en onveilige code te maken. Goed nadenken over welke data je verzamelt, of je die data eigenlijk wel wilt hebben, hoe je data vervolgens veilig opslaat. Blijkbaar worden beginselen nog steeds niet goed gevolgd.

Wat betreft wachtwoorden kun je ook enkele eenvoudige beginselen aanhouden. Gebruik een wachtwoordmanager en laat deze lange en daarmee veilige wachtwoorden genereren. Zo hoef je in beginsel weinig tot geen wachtwoorden te onthouden. Op die manier is ook de kans op het hergebruik van wachtwoorden zo goed als weggenomen. Wanneer alle wachtwoorden zijn gegenereerd dan zijn ze per definitie allemaal anders en dat is gewoon verreweg de veiligste keuze.

Er zal inderdaad een 'master wachtwoord' nodig moeten zijn om de wachtwoordmanager te ontgrendelen. Daar kun je tot op zekere hoogte omheen werken met bijvoorbeeld biometrische login, maar ook die zijn nooit helemaal 100% waterdicht. Het is in ieder geval geen geldige reden om geen wachtwoordmanager te gebruiken.

[Pinkys Brain]

Heel veel programmeurs zeggen hetzelfde om zichzelf te overtuigen dat ze geen prepared statements hoeven te gebruiken ... en daarom houd je SQL injecties. Dat er andere dingen fout kunnen gaan is geen reden om niet een van de aller grootste bronnen van exploits compleet uit te bannen.

[FrankHe]

Het gaat uiteraard om beide, in de eerste plaats prepared statements gebruiken, in de tweede plaats veilige businesslogica schrijven en die vervolgens correct in veilige code omzetten.

Helaas komt het nog met enige regelmaat voor dat iemand door simpelweg een numerieke id in een URL sequentieel op te hogen toegang weet te krijgen tot de gegevens van een wildvreemde. Absolute beginnersfouten die mensen blijkbaar nog steeds maken. Niet te vatten.

Dan kun je nog zo'n veilig wachtwoord hebben maar daar heb je vervolgens niets aan zodra de programmatuur van het platform niet de relevante checks heeft die nagaan of de gebruiker die de aanroep doet überhaupt wel bij die data mag.

[CPV]

Ja, de ultieme wereld en de werkelijkheid:

Mag alleen maar gebeuren als

Er mag zoveel niet, maar de werkelijkheid is, dat het wel gebeurt.

dat daar geen fout in mag zitten

Software hoor zonder fouten te zijn, maar dat zal nooit gaan lukken (behalve IEFBR14).

[Pinkys Brain]

De functionaliteit van een Privileged Access Management server die vanaf het netwerk voor de rest van de infrastructuur toegankelijk moet zijn kan in heel heel weinig regels code (admin zal meer nodig hebben, maar dat kan beter afgeschermd worden). Daarom zeg ik dat er geen fout in mag zitten, hoe minder code, hoe beter je ernaar kan kijken.

Maar ja, in plaats van goed na te denken over attack surface is IT meestal meer bezig met pleisters op open wonden. End point security, zero trust, traffic analysis, etc ...

PS. voor regels code van de password server zie ik encryptie/compressie/database even apart, omdat die als componenten verschrikkelijk uitgeplozen worden.

[vickypollard]

Bij mijn werkgever zijn de verplichte wachtwoordwijzigingen er gelukkig ook al een tijdje uit, bij mijn weten omdat dit advies al een tijdje bestaat (vanuit waar weet ik even niet meer). Ik weet daardoor alleen niet wat de huidige eisen aan een wachtwoord zijn

[Reactie gewijzigd door vickypollard op 1 oktober 2025 14:13]

[mjtdevries]

De huidige eis is vooral dat het lang moet zijn, want dan is het moeilijker te bruteforcen.
Dat is in weze ook waarom een wachtwoord complex moet zijn, want ipv 26 mogelijke opties per teken van je wachtwoord heb je er dan ineens 3x zoveel.

En het moet natuurlijk vooral iets zijn dat niemand kan raden. Vandaar ook geen beveiligingsvragen of hints daarvoor, want die vragen zijn meestal nogal dom gekozen. Het zijn vaak vragen die andere mensen ook kunnen weten.

[vickypollard]

Ik bedoelde dus de huidige eis bij mij werkgever

[FrankHe]

Met kleine letters, hoofdletters en cijfers kom ik al op 62 verschillende tekens.

Zodra je verplicht dat een 'wachtwoord' leestekens moet bevatten dan hoef je alvast alle wachtwoordcombinaties zonder leestekens niet te proberen in je bruteforce aanval. Zodra je niet met zekerheid weet of een wachtwoord al dan niet speciale tekens bevat, het mag wel maar het hoeft niet, dan kun je dus minder combinaties uitsluiten.

Persoonlijk zou ik zeggen, van de vier categorieën: kleine letters, hoofdletters, cijfers en bijzondere tekens, stel twee categorieën verplicht, niet drie en niet vier. Bij drie en vier categorieën wordt het namelijk gemakkelijker om grote hoeveelheden combinaties weg te strepen die je dan niet hoeft te proberen.

Ik zou inzetten op lengte, zelf vind ik 12 tekens wel de absolute ondergrens, dus die acht tekens uit dit advies wind ik echt te kort.

De wachtwoordhints moeten echt de prullenmand in net als die rete onveilige 'veiligheidsvragen'. Die dingen heb ik werkelijk nooit begrepen. De meisjesnaam van je moeder, naam basisschool, naam kat of hond. Dat is allemaal informatie die veel mensen online in sociale media laten slingeren waardoor dit wat mij betreft pertinent onveilige vragen zijn.

[Blokker_1999]

Wij kunnen er dan weer niet van af daar 1 van onze klanten het vereist.

[DigitalExorcist]

Microsoft raadt al jaren aan om regelmatige wijzigingen af te schaffen. Ja, complexe wachtwoorden moeten blijven (althans, complex in de zin van hoofdletters, leestekens en cijfers - niet dat iedereen 26-karakter-wachtwoorden moet gaan onthouden!).

[sympa]

En toch kan je beter een wat langer wachtwoord gebruiken dan de mensen forceren een 3 te tikken op de plek van de letter E.

[DigitalExorcist]

Ja maar er is een verschil tussen een complex wachtwoord van pakweg 16 karakters en 26+ .. de kans dat iemand het password van 26 karakters op een geeltje moet schrijven is groter.

Qua remote aanvallen is een geeltje natuurlijk honderd keer béter .. maar ja.. bij fysieke diefstal ben je de klos.

[Stoney3K]

Dat ligt er maar net aan, een wachtwoord van 16 karakters wat onuitspreekbare jibberish is, is veel lastiger te onthouden dan een groepje schijnbaar willekeurige woorden wat je als een zin op kan schrijven.

[The Zep Man]

Dit is niets nieuws. Uit de vorige revisie van de richtlijnen (2017) over wachtwoorden:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

[Reactie gewijzigd door The Zep Man op 1 oktober 2025 14:26]

[mjtdevries]

Het is een beejte gevaarlijk hoe het advies nu verwoord word. Het punt is natuurlijk niet dat je geen complexe wachtwoorden moet verplichten, maar dat het BETER is om lange wachtwoorden af te dwingen, dan complexe wachtwoorden. Dat is veiliger en makkelijker voor de gebruikers.

[aikebah]

Het advies is dat het afgeraden wordt om complexe wachtwoorden door allerlei eisen van hoe je de letters aan elkaar knoopt en welke karaktersubsets je gebruikt af te dwingen

The terms “SHOULD” and “SHOULD NOT” indicate that ..., or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited

Het gaat bij wachtwoorden namelijk om een authenticatiefactor die je geacht wordt te onthouden en de compositie-eis gaat ten koste daarvan, terwijl een vrije keus voor een lang wachtwoord prima kan zonder de onthoudbaarheid geweld aan te doen.

Mijn wachtwoord is geheim en niemand die hem weet.

Oeps... nu kan ik die niet meer gebruiken want hij is gepubliceerd

edit:
ik zie net dat ze het in de passwordsectie zelfs expliciet verbieden voir zelfgekozen wachtwoorden:

If the CSP disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2), the subscriber SHALL be required to choose a different password. Other composition requirements for passwords SHALL NOT be imposed

• The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

[Reactie gewijzigd door aikebah op 1 oktober 2025 21:01]

[mjtdevries]

Het advies is dat het afgeraden wordt om complexe wachtwoorden door allerlei eisen van hoe je de letters aan elkaar knoopt en welke karaktersubsets je gebruikt af te dwingen

Nee! dat is niet het advies.
En dat is precies waarom ik aangaf dat het nu op een gevaarlijke manier verwoord word, want jij gaat al meteen de fout in.
Het cruciale punt is dat je in plaats daarvan een langer wachtwoord moet gebruiken. Maar dat hebben mensen niet in de gaten.

Ze hadden beter als advies kunnen geven: Verplicht veel langere wachtwoorden. (minimaal 12 tekens) en dan kun je complexiteit eisen achterwege laten.
Dan was het veel duidelijke geweest wat de kern van de zaak is.

edit: en zelf gekozen wachtwoorden verbieden is natuurlijk tegen dictionairy attacks. Maar dan heb je weer het probleem dat je een moeilijk te onthouden wachtwoord krijgt dat mensen op een papiertje gaan schrijven.

[Reactie gewijzigd door mjtdevries op 2 oktober 2025 10:01]

[aikebah]

Dat is wel het crux van het advies dat in deze draad relevant is voor jouw opmerking van 'beter'.

Het is een aanscherping van eerder beleid: beleid is nu: kap met die wachtwoordcompositie-eisen (ja een verbod op eisen aan de samenstelling van het wachtwoord), want het is nu het voorschrijvende SHALL NOT, waar de vorige revisie nog het adviserende SHOULD NOT gebruikte.

Een check tegen blocklist is onder de nieuwe revisie de enige valide reden om zelfgekozen wachtwoorden (die voldoen aan de minimumlengte en optioneel de maximumlengte (die 64 of hoger zou horen te zijn)) af te wijzen.

Daarnaast is inderdaad ook (en terecht) de minimumlengte voor een wachtwoord, bij wachtwoord als enige factor, verhoogd van 8 naar 15 en voor plekken waar wachtwoord de enige factor is had dat eigenlijk al lang staand beleid moeten zijn.

[Sissors]

Het National Institute of Standards and Technology (NIST) geeft in zijn nieuwe richtlijnen voor wachtwoorden opvallend andere best practices voor betere beveiliging.

Het is toch gewoon een advies wat een opvolger is wat ze al jarenlang adviseren? Zo opvallend is het niet, behalve dat het helaas te makkelijk is om idiote wachtwoordeisen in te stellen, die dan maar voor "de zekerheid" aangevinkt worden. Als verantwoordelijke kan je direct vertellen aan jouw baas dat jij alles eraan hebt gedaan: Zowel speciale tekens als cijfers en hoofdletters zijn verplicht!

Snelle Google levert mij een samenvatting van de NIST 2020 adviezen op: https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/. Zo opvallend anders zijn de adviezen van dit jaar dus niet. Helaas voor NIST, en nog jammerder voor ons als gebruiker, worden die adviezen gewoon genegeerd door heel veel.

[Majhool]

Een nieuwe richtlijn mag best oude (goede) adviezen bevatten. Ik zie nog weinig wachtwoord policies die aan deze richtlijn voldoen, dus herhaling is prima!

Qua acceptatie van de richtlijn is er een issue dat eruit springt. Eindgebruikers denken dat het invoeren van een lang wachtwoord (20 tekens) omslachtiger is dan het invoeren van een 'moeilijk' wachtwoord (10 tekens). Ik betwijfel dat, maar het vormt wel een obstakel om dit in te voeren in omgevingen waar het wachtwoord (nog) vaak wordt gevraagd. (zoals: Onderwijs, Gezondheidszorg, (IT-)Beheer)

[TheGreatAtuin]

Verplichte link naar XKCD over wachtwoordcomplexiteit.

Gewoon 3-4 korte woorden zonder hoofdletters of speciale symptolen, appelsleuteltafel (uit de MMSE gevist) in combinatie met een 2FA systeem, en je hoeft nooit meer aan je ultraveilig wachtwoord te denken

[Bundin]

heh aye, ik weet jaren later 'correct horse battery staple' nog uit mijn geheugen te vissen voordat ik je linkje aanklik Werkt als een malle dus.

[Reactie gewijzigd door Bundin op 1 oktober 2025 14:28]

[iqcgubon]

Ha, wij hielden intern op het werk eens een quiz over wachwoorden. Een van de vragen was of "correct horse battery staple" een goed wachtwoord was. Ik duid aan: Ja.

"Fout! Dit wachtwoord komt van de bekende webcomic xkcd en kan dus niet meer veilig geacht worden."

He, kom op

[uiltje]

LOL, nou ja, ze hadden moeten zeggen "van het type als". Bij mijn eerste security werkgever stond letterlijk "Agent007" er in als goed wachtwoord. Uh, ja. Da's gelukkig alweer lang terug en na mijn kritiek meteen aangepast. Onze SO had van IT security geen kaas gegeten, was beter in operationele security.

[Stoney3K]

En voordat iemand gaat brullen "Ja maar dictionary aanvallen!", moet je je realiseren dat het Engelse woordenboek een paar ordes van grootte meer is dan de 26 (of misschien 128) mogelijke karakters waaruit een woord kan bestaan, dus een combinatie van 4 willekeurige woorden is al vrij veel entropie.

Als dat nog niet genoeg is dan kun je altijd vereisen dat elk woord minstens één hoofdletter en/of een cijfer bevat. "Corr3ct H0rse b4tterY St4ple!" is wat lastiger, maar nog altijd wel te onthouden, als je niet de cijfers ervoor of er achter plakt. Een dictionary attack proberen uit te voeren met al die mogelijke permutaties, die ook nog eens niet weet hoe lang het wachtwoord gaat zijn? Vergeet het maar.