Tokengenerator

Wat deze tool doet

Stel de tekensets in die je wilt, sleep de lengte naar ergens tussen 3 en 512, en klik op Genereren. Je krijgt een willekeurige tekenreeks, opgebouwd uit de random-bron van het besturingssysteem, klaar om te plakken in een API-client, een omgevingsbestand, een database-seed of een wachtwoordmanager. Genereer opnieuw en het nieuwe token verschijnt boven het vorige, zodat je er meteen een handvol kunt maken — een token, een databasewachtwoord en een ondertekeningssleutel — zonder de eerdere kwijt te raken terwijl je ze plakt.

Hoofdletters, kleine letters en cijfers staan standaard aan en symbolen staan uit, wat de combinatie is die op de meeste plekken werkt. De standaardlengte van 64 gaat bewust ver voorbij wat de meeste systemen vereisen: voor alles wat door een machine gelezen wordt in plaats van door een mens getypt, kosten extra tekens niets en nemen ze de vraag weg of het token wel lang genoeg is.

Waar er ruimte voor is, wordt gegarandeerd dat er minstens één teken uit elke ingeschakelde set voorkomt. Dat is niet voor de sterkte — het verandert nauwelijks iets — maar voor de validators die op minstens één cijfer staan en een verder prima token afwijzen dat er toevallig geen heeft.

Waar de willekeur vandaan komt

Elk teken hier komt van crypto.getRandomValues, de browserinterface naar de cryptografische random-bron van het besturingssysteem — dezelfde generator achter de sleutels die je machine gebruikt voor TLS. Dat is niet hetzelfde als Math.random, wat een snelle pseudowillekeurige reeks is zonder enige veiligheidsclaim, in sommige engines voorspelbaar geseed wordt, en de stille zwakte is geweest achter meer dan één gelekte tokengenerator.

Er is nog een detail dat een zorgvuldige generator onderscheidt van een onzorgvuldige. Een willekeurige byte terugbrengen naar een positie in de tekenset met een gewone rest — byte % 62 — is subtiel scheef, omdat 256 niet gelijk deelbaar is door 62: de eerste paar tekens van de set komen dan net iets vaker voor dan de rest. Deze pagina trekt een byte, gooit hem weg als hij in de ongelijke staart van het bereik valt, en trekt opnieuw. Dat heet rejection sampling, het kost een paar extra bytes, en het zorgt ervoor dat elk teken precies zo waarschijnlijk is als elk ander.

Het resultaat is een token waarvan de enige sterkteclaim rust op de lengte en de tekenset — geen verborgen patroon, geen tijdstempel, geen teller, niets afgeleid van wat je op de pagina aan het doen was.

Er verlaat niets je browser

Het token wordt op je eigen machine gemaakt en blijft daar. Niets van wat je genereert wordt een netwerkverzoek: er is geen upload, geen cookie, geen lokale opslag en geen log van wat er op het scherm verscheen. Herladen van de pagina wist de stapel, en het sluiten van het tabblad ruimt hem op.

Voor een generator is die eigenschap geen leuke bijkomstigheid — het is het hele punt. Een token dat op de server van iemand anders is gemaakt, is bij iemand anders bekend geweest, en geen enkele belofte over het niet bewaren ervan is van buitenaf te controleren. Een geheim dat over een netwerk gereisd heeft om jou te bereiken, is een geheim met een tweede kopie ergens, en de enige manier om zeker te zijn dat er geen tweede kopie is, is dat de waarde nooit ergens anders is geweest dan hier.

Je kunt het controleren in plaats van het op vertrouwen aan te nemen: open je netwerktabblad en klik op Genereren. Afgezien van de analytics-beacon die deze site bij elke paginalading verstuurt — een URL en een paginatitel, net als elke andere pagina hier — wordt er niets aangevraagd. Verbreek de netwerkverbinding volledig en de generator werkt nog steeds, wat het eenvoudigste bewijs is dat er aan de andere kant niets is om naartoe te sturen.

Hoe lang moet een token zijn?

Lengte is de instelling die ertoe doet. Elk extra teken vermenigvuldigt het aantal mogelijke tokens met de grootte van de tekenset, dus de sterkte groeit exponentieel met de lengte en slechts lineair met hoe exotisch het alfabet is. Symbolen toevoegen aan een token van 16 tekens levert ongeveer evenveel op als er twee of drie tekens aan toevoegen.

De gebruikelijke maat is entropie in bits, weergegeven naast de knop terwijl je de schuifregelaar versleept. Een ruwe schaal: 32 bits is triviaal te kraken en hoort alleen bij wegwerp-identifiers; 64 bits is buiten bereik van toevallige pogingen maar niet van een serieuze; 128 bits is de gangbare ondergrens voor alles wat echte toegang beschermt, en is wat een token van 22 tekens uit het volledige alfanumerieke alfabet je geeft; 256 bits is het niveau waarop het aantal mogelijkheden geen fysieke vergelijking meer heeft en geen hoeveelheid hardware nog helpt.

Praktisch advies: voor een API-sleutel, een sessiegeheim, een webhook-ondertekeningssleutel of een applicatiesleutel in een configuratiebestand is 32 tot 64 tekens juist, en de standaardwaarde van 64 is een goede plek om te blijven. Voor een database- of servicewachtwoord is 24 tot 32 tekens meestal de zoete plek tussen sterk en plakbaar. Korte lengtes — onder 12 — zijn voor identifiers, kortingscodes en testfixtures, niet voor iets dat toegang bewaakt. De schuifregelaar gaat tot 512 omdat sommige systemen een heel lang gedeeld geheim willen, en omdat er geen reden is voor de tool om een mening te hebben onder het punt waarop de browser het begint te voelen.

Waarom symbolen standaard uit staan

Symbolen voegen een beetje sterkte toe en heel veel wrijving, dus de schakelaar begint uit.

De wrijving is alledaags en kostbaar. Een token met $ of een backtick erin gedraagt zich anders zodra het in een shellscript of een Docker-omgevingsbestand terechtkomt, waar die tekens geïnterpreteerd worden in plaats van opgeslagen. Een token met @, : of / breekt een databaseverbindingsstring, want dat zijn precies de tekens die het URL-formaat gebruikt om de delen te scheiden. Configuratiebestanden in YAML of INI hebben hun eigen opvattingen over aanhalingstekens. Sommige enterprise-systemen wijzen tekens af die ze onveilig achten, kappen stilletjes af bij het eerste zo'n teken, of accepteren het token bij binnenkomst en normaliseren het bij het uitgaan — wat een credential oplevert die fout is op een manier die nergens gemeld wordt.

De set die hier gebruikt wordt, wanneer je hem wél inschakelt, laat bewust de aanhalingstekens en de backslash weg om precies die reden. Maar het echte antwoord staat in het vorige hoofdstuk: als je meer sterkte nodig hebt, voeg tekens toe in plaats van leestekens. Een alfanumeriek token van 64 tekens gaat al ver voorbij alles wat symbolen zouden redden, en het overleeft ongewijzigd geplakt te worden in elk van die plekken.

Schakel symbolen in wanneer een beleid ze vereist — genoeg wachtwoordregels doen dat nog steeds — of wanneer het token rechtstreeks een wachtwoordmanager ingaat en geen shell, verbindingsstring of configuratiebestand het ooit zal moeten parsen.

Tokens zijn geen wachtwoorden

De uitvoer hier past bij beide, maar de twee worden anders gebruikt en het is de moeite waard om duidelijk te zijn over welke je maakt.

Een token — een API-sleutel, een webhookgeheim, een applicatiesleutel — wordt door machines gelezen. Niemand typt het, dus lengte kost niets en er is geen reden om bescheiden te zijn: genereer lang, plak eenmalig, sla op in een secretmanager of een omgevingsvariabele, en nooit in een repository. Roteren zou een routinehandeling moeten zijn in plaats van een noodgeval, wat in de praktijk betekent dat het systeem dat het leest twee geldige waarden moet tolereren terwijl de wijziging uitrolt.

Een wachtwoord wordt door een persoon ingevoerd, althans af en toe, en wordt vrijwel altijd bewaard in een wachtwoordmanager. Willekeurig verslaat slim hier: een gegenereerde tekenreeks bevat geen persoonlijk detail, geen hergebruikt patroon, en niets wat een aanvaller kan raden uit wat hij al over je weet. Als je er wel een hardop moet voorlezen of vanaf een telefoonscherm moet typen, is een kortere lengte met kleine letters en cijfers veel vriendelijker dan een symboolrijke, en 20 willekeurige tekens is ruim voldoende.

Geen van beide wordt beter door memorabel te zijn, en geen van beide zou hergebruikt moeten worden. De reden dat wachtwoordhergebruik de duurste gewoonte in security is, is dat het één lek waar dan ook omzet in toegang overal, en een generator bestaat juist om ervoor te zorgen dat elke keer een verse waarde gebruiken niets kost.

Een uitgewerkt voorbeeld

Laat de standaardinstellingen staan — hoofdletters, kleine letters en cijfers, 64 tekens — en klik op Genereren. De koptekst meldt 64 tekens, noemt de drie sets, en rapporteert 62 tekens om uit te kiezen en ongeveer 381 bits entropie. Dat is een token met geen realistisch vooruitzicht om geraden te worden door welk middel dan ook, met welke hardware dan ook, binnen welk tijdsbestek dan ook, en het plakt ongewijzigd in een .env-bestand, een shellcommando, een verbindingsstring en een JSON-body.

Sleep de schuifregelaar nu naar 20 en genereer opnieuw: hetzelfde alfabet geeft ongeveer 119 bits, wat nog altijd voorbij het niveau is waarop brute force een serieus idee is, en het is kort genoeg om van een scherm af te lezen. Schakel symbolen in en het wordt ongeveer 129 bits — een echte winst, maar minder dan de vier extra tekens die je er in plaats daarvan aan had kunnen toevoegen, en nu moet de waarde in een shell tussen aanhalingstekens staan. Die vergelijking is het hele argument voor de standaardinstellingen op deze pagina.