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 acht tekens lang moeten zijn en maximaal vierenzestig 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 (138)

[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.

[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.

[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.

[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]

[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.

[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).

[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.............

[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.

[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.

[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]

[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)

[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.

[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]

[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.

[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

[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.

[mjtdevries]

Het NIST komt al jaren met dat advies, maar iedereen vereist nog steeds complexe wachtwoorden. Dan kan jij lekker eigenwijs doen om dat niet te willen, maar je bent afhankelijk van de toko die complexe wachtwoorden vereist. Je kunt dan als Don Quichotte tegen windmolens gaan vechten en zeggen dat de rest van de wereld buitenspel staat.
Of je kunt het gewoon accepteren en daar complexe wachtwoorden genereren en lange niet complexe wachtwoorden instellen voor andere accounts waar je wel zelf in control bent.

[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".

[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]

[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.

[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.

[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.

[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.

[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.

[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]

[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.

[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]

[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.

[jaapzb]

Waarom adviseren ze een maximale lengte? Ik genereer meestal gewoon een wachtwoord van 50 ish tekens en gooi die in mijn password manager, maar gezien het wachtwoord (als het goed is) gehashed word, moet het niet echt uitmaken of het 50 of 150 tekens zijn, toch?

[P_Tingen]

De frontend moet die lange invoer ook accepteren. Een tijd geleden heb ik het voor elkaar gekregen om me op een site te registreren met een ww van een paar duizend tekens lang (gewoon omdat het kon).

Maar vervolgens kon ik dat ww niet kwijt in het inlogscherm

[harmster]

Zodat grapjassen niet een ASCII versie van Jurassic Park uploaden. Maar de caps waar ik vaak tegenaan loop zijn echt te laag.

Ik vraag me ook af waarom het NIST een max van 64 voorstelt.

[aikebah]

Ze adviseren een minimale maximum lengte voor omgevingen die een maximum-lengte hanteren.

Een maximum-lengte hanteren kan best weer een goede maatregel zijn tegen een compute-gebaseerde denial-of-service attack op je login infrastructuur (te lange wachtwoorden meteen afwijzen ipv eerst de secure hash berekenen om dan te constateren dat dat niet overeenkomt met de opgeslagen password hash van het account kan best duur worden bij een 1TB wachtwoord).

[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 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.

[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).