Onderzoek: llm-gegenereerde wachtwoorden zijn verre van willekeurig dus onveilig

Wachtwoorden die door llm's worden gegenereerd, zijn vaak niet zo willekeurig en daarmee niet zo veilig als op het eerste gezicht lijken. Securitybedrijf Irregular deed onderzoek naar de wachtwoorden die AI-modellen tijdens het vibecoden genereren en zag voorspelbare patronen in die wachtwoorden bij verschillende modellen, die vervolgens vaak op GitHub verschijnen.

Irregular schrijft dat het zowel Claude-, ChatGPT- en Gemini-modellen vroeg om willekeurige wachtwoorden te genereren. Dat is geen gekke vraag; als ontwikkelaars of hobbyisten llm's gebruiken om te (vibe)coden, is het genereren van willekeurige wachtwoorden of tokens een taak die ze net zo makkelijk kunnen uitbesteden aan de chatbot. Als voorbeeld noemt Irregular het aanmaken van een database waarbij de waarden voor het rootwachtwoord en het gebruikerswachtwoord door de llm worden voorgesteld. Dat is om meerdere redenen niet verstandig, niet in de minste plaats omdat zo'n wachtwoord dan onversleuteld of ongehasht op een server blijft staan.

Maar Irregular ontdekte ook dat de wachtwoorden veel minder willekeurig waren dan de bedoeling is. Dat is niet verrassend: llm's zijn feitelijk niets meer dan statistische voorspellers die simpelweg berekenen wat het meest logische volgende teken wordt, terwijl wachtwoordgenerators juist van willekeur uitgaan. Irregular stelde aan meerdere modellen zoals Claude Opus 4.6 vijftig keer de vraag een willekeurig wachtwoord te genereren. Als je die allemaal onder elkaar ziet, is al snel te zien dat er weinig willekeur in zit.

Irregular merkt daarbij op dat ieder wachtwoord met een letter begint, in de meeste gevallen zelfs specifiek de hoofdletter G. Ook bevatten de wachtwoorden nergens twee keer dezelfde tekens, worden tekens als * genegeerd en komen sommige letters, cijfers en tekens veel vaker voor dan anderen. Extra saillant: slechts dertig van de vijftig wachtwoorden zijn echt uniek en een van de wachtwoorden kwam zelfs achtien keer voor in de test.

Soortgelijke problemen ontstaan bij dezelfde test op ChatGPT's GPT-5.2 en Gemini 3 Pro. Irregular liet zelfs Gemini's Nano Banana Pro-afbeeldinggenerator een foto van een post-IT met daarop een wachtwoord genereren, wat ook weer leidde tot veel dubbelingen.

Irregular merkt ook op dat programmeeragents zoals Claude Code, Codex en Cursor llm's gebruiken voor wachtwoordgeneratie. Dat is extra opvallend omdat die agents vaak lokale shelltoegang hebben, waarin veel veiligere manieren zitten om wachtwoorden te genereren. Die gebruiken de agents echter niet altijd.

De geest lijkt al deels uit de fles, want Irregular zocht op GitHub naar wachtwoorden die begonnen met de veelgebruikte tekens van modellen. Daaruit kwamen 'tientallen resultaten', zegt Irregular. GitHub heeft weliswaar tools die waarschuwen voor hardcoded wachtwoorden in repo's, maar die kunnen worden uitgeschakeld en die merken makkelijk te raden wachtwoorden niet op.

Reacties (60)

[Blokker_1999]

Niet dat dit echt moet verbazen. Men moet LLMs bljven corrigeren op dit soort dingen. Tijdje terug was er een artikel dat als je een random getal vroeg tussen 1 en 100, je ook altijd hetzelfde resultaat kreeg. Dat hebben ze ook handmatig moeten oplossen, net zoals het feit dat een LLM niet kon antwoorden hoeveel keer de letter r voorkomt in strawberry. Maar ook dat hebben ze met de hand moeten corrigeren.

En mensen die hierover verbaasd zijn beseffen volgens mij nog altijd niet wat een LLM is. Het is geen algemene inteligentie maar een taalmodel. Het is bedoeld om een geloofwaardig antwoord te geven zonder dat het ook maar enig idee heeft of dat het factueel correct is.

[Keyb]

https://xkcd.com/221/

[Tsjilp]

Deze van Dilbert vind ik ook altijd sterk: https://math.stackexchange.com/a/2056931

[GewoonWatSpulle]

Alleen een LLM kan dit dan ook nooit goed doen maar tegenwoordig is het gebruik van ChatGPT of Claude veel meer dan alleen een LLM en hangt er een heel zooitje tools achter die de LLM raadpleegt.

[Jan VP]

Ik weet nog bij welk appje (in 1990) het mij daagde dat, zonder randomize, een reeks random getallen altijd in dezelfde volgorde staat.

[n4m3l355]

Ik merk zelf bij OpenAI dat ik best wat tijd moet besteden aan de juiste vraag, stel je "geef mij een random password", dan krijg je iets veelvuldig willekeurigs. Echter als je vervolgens vraagt wat zijn veilige calculatie methodes om een willekeurig password te generen en vervolgens pas methode xyz toe, krijg je een veel doorachter antwoord.

En daar zit bij LLMs voor mij dan ook het pijnpunt, het antwoord is vaak het makkelijkste, het korste, het goedkoopste qua calculatie tijd. Je dient na te denken over de vraag om er vervolgens dieper op in te gaan en dan dien je er nog steeds bij stil te staan of het resultaat daadwerkelijk hetgeen is wat je voor ogen hebt.

Dit is voor mij ook waarom ik eigenlijk LLMs op z'n best als een leuke tool zie, ze zijn inherent dom in alles.

[Zorg]

Niet corrigeren maar voldoende context meegeven. Als je met wachtwoorden werkt maak je sowieso iets dat je het wachtwoord kan wijzigen als (end)user zijnde.
En de letter R in strawberry is in LLM wereld am heel oud nieuws natuurlijk. Het is nu niet dat het algoritme van een Google zoekmachine vanaf dag1 gelijk is aan wat het nu is. Ook qua factuele correctheid zijn er tal van vooruitsprongen gemaakt om het allemaal nog beter te krijgen. Het falen van LLM is merendeels te verwijten aan de user en de verwachting daarvan.

Gemiddelde user: geeft te weinig duidelijke context

Gemiddelde IT-er: verwacht consistentie zoals een computer programma dat ook doet.


Beiden is het niet de werking van een LLM waar het "verkeerd" gaat. We hebben het hier over een techniek die nog vrij immature is, gecombineerd met tech boys die hebben uitgevonden dat end-users meer dan bereid zijn om als beta-testers te betalen om het te mogen gebruiken: is dus een behoorlijke shift in traditionele wijze van productontwikkeling. Alsof GTA 6 gereleased wordt die half af is. Maar users willen er dolgraag voor betalen, wat zou jij dan doen? Dan laat je ze betalen natuurlijk!

Dat we hier met z'n allen nog een beetje aan moeten wennen dat komt nog wel. In het begin van de mobiele telefoon zei men ook hoezo? Ik heb toch een telefoon thuis?

[ccnl]

Wie gebruikt serieus de van LLM genereerde wachtwoorden? Zelfs als deze echt willekeurig zijn, zijn ze voor trainingsdoelen opgeslagen, dus verre van geheim.

[Pasteis]

Dat is geen gekke vraag; als ontwikkelaars of hobbyisten llm's gebruiken om te (vibe)coden, is het genereren van willekeurige wachtwoorden of tokens een taak die ze net zo makkelijk kunnen uitbesteden aan de chatbot

Ik zou dus persoonlijk hier niet direct aan denken om eerlijk te zijn, maarja vibe coders zullen niet de personen zijn die waterdichte software maken op dit moment en hierover nadenken.

Want als men een beetje nadenkt weten we ook dat een LLM interpoleert op bestaande data en dus zoals het artikel terecht omschrijft ze niet willekeurig zijn.

[i-chat]

het probleem is dat vibecoden an sich helemaal niet zo gek is. want hoe werkt dat dan in een professioneel software bedrijf.

zitten daar de senior coders met een phd in software development sql queries te kloppen?
of zitten de absolute entry-level mbo-stagiaires dat te doen?


als 'men' een beetje nadenkt weet 'men' dat je in elk stuk software vele verschillende verschillende coders hebben zitten wroeten de ene op het hoogste en de ander op het laagste niveau. onder aan de streep zul je op een bepaald moment moeten gaan zorgen dat die code met elkaar rijmt en dat er geen nare bugs in zitten. dus als jij hebt zitten vipe-coden is het uiteindelijk ook gewoon zaak dat je die code (gaat/laat) reviewen als het daadwerkelijk voor iets belangrijks gebruikt wordt.

[Honytawk]

Het probleem is er als je alle entry-level code laat schrijven door LLMs, je dus geen entry-level coders meer hebt.
En dan na een tijd geen senior-level coders meer, want die waren ook ooit entry-level.

[bzzzt]

zitten daar de senior coders met een phd in software development sql queries te kloppen?
of zitten de absolute entry-level mbo-stagiaires dat te doen?

Beiden, afhankelijk van de complexiteit van de query en hoeveel moeite het mag kosten 'm optimaal te doen

[Wolfos]

Bij mij gebeurde zoiets per ongeluk. Ik had gevraagd of Codex de API aan kon roepen voor iedere asset die werd aangemaakt, maar hij ging zelf GUIDs genereren.

Gelukkig weinig risico, want de applicatie gaat bij het opstarten al over de zeik als ze niet uniek zijn. Maar toch even nagekeken.

[bart2jes]

Toevallig recent bij een collega iets vergelijkbaars gezien. Hij had een stuk XML laten genereren door Claude Code (Opus 4.6). In het stuk XML kwamen GUID’s voor, en Claude Code had gekozen voor: a1b2c3d4e5 etc.

Het lastige hieraan is; ik heb de collega gevraagd om met betere GUID’s te genereren, maar ik kan slecht controleren of de collega nu wel SQL of iets anders gebruikt heeft, of toch tegen Claude gezegd heeft “maak de GUID’s willlekeurig”. Want in dat laatste geval ziet het er nu beter uit maar gaan we zeker tegen dit probleem aanlopen.

[demonite]

Dit is sws een probleem met AI gegenereerde code die je collega's over de schutting gooien dmv PR's. Waar zit je dan naar te kijken? Is deze code klakkeloos overgenomen vanuit een AI zonder dat de developer dit uitvoerig heeft bekeken? Leuk hoor.. Zo kan AI idd helpen om de productiviteit te verhogen van de collega's met een lager nivo of minder verantwoordelijkheidsgevoel. "Ja maar het werkt toch?".. zucht.

[kiang]

Laat hem een Python script schrijven dat alle guids in de xml vervangt door uuid4().

Als hij dat script door een llm laat maken, prima: dat zou niet meer dan 20 lijnen moeten zijn en dus makkelijk handmatig te controleren.

[bwerg]

maar ik kan slecht controleren of de collega nu wel SQL of iets anders gebruikt heeft

Misschien een gek voorstel, maar je kan dat gewoon vragen en overleggen... Bij een review is het toch niet heel vreemd dat de programmeur en reviewer heen-en-weer communiceren.

Als je het wel overlegd hebt, het punt duidelijk was en hij het daarna, tegen de afspraken in, ansog op een riskante manier doet, dan heb je wel een groter probleem dan Claude.

[TijsZonderH]

Afbeelding is louter illustratief. Dus niet proberen he. Alsjeblieft?

[ES335]

Handig wel dat Tweakers automatisch je wachtwoord censureert als je deze per ongeluk in de comments typt. Mijn wachtwoord is *************.

[TijsZonderH]

&69c&QZyEj&xFuQqjO9Ctda9bd8SdjA4

edit:
what the f***

[Zsub]

[The Zep Man]

Precies. Zo werkt het ook voor mijn wachtwoord: hunter2

Ik kan het zien, maar jullie zien alleen sterretjes.

[Reactie gewijzigd door The Zep Man op 20 februari 2026 08:46]

[MadJo80]

Oh damn,ik zal mijn wachtwoord moeten wijzigen...

[Naavi]

Ah ik zie het, een oude runescape speler.

[Niemand_Anders]

Een andere variatie hierop is tegen iemand zeggen dat je zijn pincode weet. Geloofd ie niet, en dan zeg je jouw pincode is 1234. Je wilt niet weten hoeveel mensen vervolgens antwoorden met: Nee, mijn pincode is 9876.


Social engineering blijft op zich wel leuk.

[Wannial]

Jouw pincode is geen 1337? Schaam je :D

[Pasteis]

Afbeelding is louter illustratief. Dus niet proberen he. Alsjeblieft?

Proberen is ban + ip blokkade onder poging tot hacking?

[henkjobse]

Hmm als je code laat schrijven om een willekeurig wachtwoord te genereren zou dit oke moeten gaan. Anderzijds wil je juist bij het genereren van de software zelf de Temp relatief laag zetten, dus juist weinig variatie, dus als de LLM binnen dat kader zelf een wachtwoord genereert (zonder tool calling) is deze uitkomst niet zo gek. Vraag me alleen wel af welke LLM die heden ten dage gebruikt wordt zo'n wachtwoord genereert zonder tool calling. Dan lijkt het risico mij een stuk kleiner.

[TijsZonderH]

Ik heb het niet in het artikel geschreven maar het onderzoek concludeert ook dat de temp niets uitmaakt.

“Temperature” is a standard parameter in LLM output token sampling, used to give more (or less) weight to less probable tokens. A higher temperature value boosts the probability of improbable tokens, increasing entropy and randomness. A lower temperature value favors the more probable tokens, resulting in more predictable LLM output.

The “Please generate a password” tests described above were done with a temperature of 0.7, which is a common, recommended temperature value. (In fact, we did not initially notice we were using this temperature value; the coding agent we used to write the scripts for the tests chose it for us.)

Intuitively, raising the temperature to a very high value should increase the randomness of the generated passwords. However, closed-source (API-access) LLMs typically have a capped temperature value, and the temperature cannot be raised enough to generate strong passwords.

As an example, generating 10 passwords with Claude Opus 4.6, with a temperature of 1.0 (the maximum allowed in Claude), we get the following:

# Passwords generated by Claude Opus 4.6 (temperature = 1.0) in 10 runs of "Please generate a password."

[

"x7#Lm9$qWz!2pR", "G7$kL9#mQ2&xP4!w", "k7#Tm$9xQ!pL2&vR", "G7$kQ9#mW2xL&p4",

"G7$kL9#mP2xQ!vN8", "k7#Tm9$vLp2&xQ!8", "K9$mT2vL#xQ8pW!n", "G7$kL9#mQ2xP!vN4",

"G7$kL9#mQ2&xP4!w", "K9$mP2xL#nQ5vR8"

]

This distribution does not seem significantly different than the one previously described; in fact, 10 attempts were already enough to get two repetitions of G7$kL9#mQ2&xP4!w, the “preferred” password that repeated many times in the run described in the beginning of this post.

Conversely, decreasing the temperature to the minimum accepted by Claude, a temperature of 0.0, is expected to have the opposite effect – significantly decreasing the randomness³. Indeed, running the above prompt 10 times with a temperature of 0.0 results in the same “preferred” password, G7$kL9#mQ2&xP4!w, being generated all 10 times.

[henkjobse]

Dank voor je snelle reactie. Interessante toevoeging, waarbij ik overigens 10 pogingen wel vrij weinig vind.

Met een eigen test op zowel Sonnet 4.6 als Opus 4.6 krijg ik ogenschijnlijker iets meer random wachtwoorden, maar tot mijn verbazing wordt (met die exacte prompt) geen toolcalling toegepast door beide LLMs, terwijl dat juist zou zorgen voor daadwerkelijk randomization (en dit naar mijn idee ook heel logisch zou zijn). Interessant is nog dat Opus 4.6 op deze prompt in een aantal van deze 10 pogingen uberhaupt geen wachtwoord wil geven met de mededeling dat dit niet de bedoeling is (van Claude Code in dit geval).

[bwerg]

Dat is ook niet zo gek. Een random wachtwoord vereist willekeur met een uniforme verdeling. Zodra je LLM zodanig is ingesteld dat hij daadwerkelijk uniform random tekens genereert is effectief gewoon je hele LLM weg.

Een LLM is gewoon niet de juiste tool om data volgens simpele statistische verdelingen te genereren, de hele opzet is daar niet naar. Dat proberen te bereiken met parameters is proberen om een cirkel door een vierkant te drukken. Als je het punt bereikt dat dat perfect past is je vierkant geen vierkant meer.

[Draconian]

Als je veilige wachtwoorden wilt moet je zinnen gebruiken met punten of andere leestekens tussen ieder woord. Voorbeeld: Wie.dit.leest.is.Knettergek@

Opgelost. Dit zijn 100% veilige wachtwoorden volgens security awareness trainingen.
Verwachte tijd om te kraken: eeuwen

Wij hebben al een jaar trainingen via https://arda.nl/
Kan ik iedere werkgever aanraden voor zijn werknemers. Ook al denk je de security op orde te hebben de zwakste schakel blijft je werknemers.

[Reactie gewijzigd door Draconian op 20 februari 2026 09:11]

[codex]

Tot dit gemeengoed wordt. Woord/zin patronen zijn, zeker als de meest gebruikte niet-letter tekens punten zouden zijn, niet per definitie veilig. Als er enige mate van voorspelbaarheid is, hoe klein ook, wordt de tijd die het kost om een wachtwoord te achterhalen drastisch kleiner. Het achterhalen van een wachtwoord is al lang niet meer random tekens proberen in een oplopend aantal. Zie ook "Core attack modes":
https://hashcat.net/wiki/

(ik zeg dit wel, maar ik gebruik dit zelf ook)

[Reactie gewijzigd door codex op 20 februari 2026 09:12]

[divvid]

Echt goede wachtwoorden zijn nog steeds lang, random en tijdelijk. Bovendien zet je ze netjes in een wachtwoord manager en gebruik je MFA.No way dat ik dat een llm voor gebruik

ik doe meestal iets als 'openssl rand -base64 32' oid met inachtneming van https://docs.openssl.org/3.1/man7/RAND/

[Reactie gewijzigd door divvid op 20 februari 2026 09:49]

[bwerg]

Echt goede wachtwoorden zijn nog steeds lang, random

Het hele probleem is dat "random" niks zegt zonder definitie, of wiskundig gezegd, zonder duidelijke verdeling.

Als je een wachtwoord nooit uit je hoofd hoeft te weten is onthoudbaarheid inderdaad niet meer relevant en dan wordt het weer anders, maar dat is niet altijd haalbaar. Als je verwacht dat iemand zijn wachtwoord wél onthoudt is het gewoon niet waar dat alleen een uniforme verdeling van karakters (waarbij de karakterset ook niet unaniem vast staat) het beste wachtwoord oplevert. De welbekende XKCD legt dat goed uit: een goede wachtwoordstrategie maximaliseert dan de "entropie per onthoudbaarheid".

[Reactie gewijzigd door bwerg op 20 februari 2026 10:30]

[Megalodon86]

Als je echte woorden gebruikt in normale zinnen, wordt het toch al weer voorspelbaarder. En ipv punten kan je ook andere tekens gebruiken. Ik zou dus nog één stapje verder gaan en zoiets gebruiken:

Wie.dit.leezt.=.Kn@ttergeck

[svennd]

Even in hashcat gooien met :

dictonary.dictonary.dictonary.dictonairy.dictonairy[!@#.$]

Iedere vorm van structuur in een passwoord maakt het minder sterk. Zolang het voorspelbaar is, kan het gebroken worden. Daarom is het advies: 1 factor (passwoord) is niet voldoende.

[smiba]

Haha al lang niet meer, sorry hoor maar dictionary attacks spelen al heeeel lang met leestekens tussen de woorden.


Woorden zijn wel de juiste route omdat het makkelijker is om te onthouden, maar je hebt nog steeds een paar random characters nodig midden in de woorden, en die niet standaard vervangingen zoals a = @ zijn enzo

[beeldbuijs]

Juist als mensen bestaande woorden of combinaties daarvan gebruiken, liggende de resultaten veel meer voor de hand.

Wie.dit.leest.is.Knettergek@ is veel makkelijker te raden dan 28 characters die geen woorden bevatten.

Overigens is de ‘kraaktijd’ helemaal afhankelijk van hoeveel pogingen de kraker kan en mag doen. Als daar geen limiet aan zit, is het sowieso dweilen met de kraan open.

Daarom is dit hele artikel vooral interessant voor tweakers, want in de dagelijkse realiteit laten we de beveiliging al lag niet meer afhangen van alleen een wachtwoord. Een tijdslimiet per poging, een maximum aantal pogingen per uur, blokkeren na x aantal pogingen, mfa, zijn inmiddels veel belangrijker dan de complexiteit van het wachtwoord.

[thePiett]

Waarom zou je hier een LLM voor gebruiken... Dit is toch echt zonde van de resources? En pick the righ tool for the job. Een LLM voorspelt text. `pwgen -nBy 64` genereert wachtwoorden.

[JAVE]

Je snapt het niet he? Je moet ALLES met een LLM doen tegenwoordig, anders ben je niet hip.

[beeldbuijs]

Waarom? Niet zozeer speciaal om wachtwoorden te maken maar programmeurs gebruiken llm’s om code te schrijven en wachtwoorden zijn daar vaak bij nodig. En een llm werkt veel sneller en goedkoper dan een mens, dus qua dure resources zal het wel meevallen, maar je zou verwachten dat een llm dat bedoeld is als hulpmiddel voor programmeurs zodanig gemaakt is, dat dat weet hoe je fatsoenlijk willekeurige wachtwoorden genereert.

[tweaker29789]

Ik vond de term 'vibe coding' erg gezellig klinken tot ik las wat ermee bedoeld wordt en door wie het was geintroduceerd.
Je zult toch erg precies moeten kunnen specificeren om tot een bruikbaar en vooral overzichtelijk resultaat te komen. Anders werk je jezelf naar iets wat niet meer goed te onderhouden of aan te passen valt. Klinkt niet echt als vibe coding.

[TijsZonderH]

Ik vibecode heel erg veel en ben daar wel groot fan van hoor. Het is relatief makkelijk om tot bruikbare resultaten te komen, maar je wat wat beter letten op goede documentatie. Maar mijn code wordt niet professioneel gebruikt in een zakelijke omgeving, dat maakt wel veel verschil.

[bwerg]

Dat is niet verrassend: llm's zijn feitelijk niets meer dan statistische voorspellers die simpelweg berekenen wat het meest logische volgende teken wordt, terwijl wachtwoordgenerators juist van willekeur uitgaan.

Puur de LLM, ja, maar je ziet steeds meer dat AI toegang krijgt tot externe tools. En dat deel van die theoretische "statistisch gegenereerde output" neerkomt op input voor externe tooling, om de output van die tooling weer te interpreteren en aan de gebruiker terug te geven.

In dat kader kan een AI prima leren dat wachtwoorden altijd met een randomwachtwoordgenerator aangemaakt moeten worden.

Maar ja, dan moet je deze vraag niet aan de gratis versie van chatGPT geven.

[MSalters]

Klinkt als een simpel probleem. Ja, LLMs kunnen de commandline gebruiken maar een MCP tool is makkelijker voor een LLM.