Base64 decoderen

Op volgorde van hoe vaak: een JWT, een Basic Auth-header, de waarde uit een Kubernetes-secret, een payload van een webhook. Drie van die vier zijn inloggegevens, en de vierde draagt meestal gegevens van mensen.

Daarom zit er geen server achter deze pagina. Dat is geen houding: het is het rechtstreekse gevolg van waar ze voor wordt gebruikt. Een hulpmiddel dat dit op afstand decodeert heeft het wachtwoord gezien en heeft het in zijn verzoeklogboek staan, en geen enkele juridische mededeling verandert dat feit.

Een JWT bestaat uit header, payload en handtekening, gescheiden door punten en elk in URL-veilige Base64. De eerste twee delen zijn JSON en lezen zonder meer; het derde is de handtekening en is geen tekst, dus decoderen levert daar niets bruikbaars op.

Het ongemakkelijke gevolg is dat de inhoud van een token niet geheim is: iedereen die het heeft, kan lezen van wie het is, wanneer het verloopt en welke rechten het opgeeft. De handtekening voorkomt wijzigen, niet lezen. Persoonsgegevens in de payload van een JWT zetten is dus: ze publiceren aan iedereen die het token te zien krijgt.

Een Base64-tekst kan net zo goed een PNG, een PDF of een ZIP bevatten als een zin. Worden die bytes als tekst gelezen, dan komen er vervangingstekens uit, en veel hulpmiddelen geven dat gewoon terug — waardoor het lijkt alsof de Base64 stuk was terwijl er niets mis mee was.

Hier wordt onderscheid gemaakt: is de tekst geldige Base64 maar vormen de bytes geen tekst, dan wordt dat gezegd, met hoeveel bytes het zijn. Dat is het bruikbare antwoord, want het sluit de zoektocht naar een coderingsfout die niet bestaat en verlegt de vraag naar wat voor gegevens het dan wel zijn.

JWT’s halen de isgelijktekens aan het eind met opzet weg, omdat de specificatie voor URL-veilige Base64 dat toestaat. Veel bibliotheken weigeren daarentegen te decoderen zonder padding en geven een foutmelding die niets uitlegt.

Deze decoder vult haar zelf aan waar dat nodig is, zodat een token uit een header werkt zoals het is. Faalt je eigen code op een waarde die het hier wel doet, dan is dat meestal precies de reden, en de oplossing is aanvullen tot het volgende viervoud voordat je het aan de bibliotheek geeft.

Het standaardalfabet gebruikt `+` en `/`; het URL-veilige gebruikt `-` en `_`. Hier worden ze allebei aangenomen zonder te vragen, want weten welk van de twee je hebt gekregen hoort geen voorwaarde te zijn om een tekst te lezen die iemand je heeft toegestuurd.

In de andere richting is het wel goed om het te weten. Bouw je een waarde die in een adres gaat reizen en gebruik je het standaardalfabet, dan breekt de schuine streep het pad en wordt de plus als spatie gelezen: de waarde komt aan, maar veranderd, en de fout duikt ver van de plek van herkomst op.

E-mail knipt Base64 in regels van 76 tekens en PEM-certificaten in 64, omdat hun standaarden dat eisen. Een waarde die uit een `.pem`-bestand of uit de body van een mail komt, arriveert dus met regeleindes erin.

Die worden genegeerd, samen met de losse spaties die ontstaan bij kopiëren uit een terminal. Er hoeft vooraf niets schoongemaakt te worden: hoort iets van wat je hebt geplakt niet bij het alfabet, dan krijg je te horen wat er aan de hand is, in plaats van een halve decodering die er goed uitziet.

Dat een tekst zich laat decoderen betekent niet dat de inhoud klopt. Een verlopen JWT leest even goed als een geldige, en een vervalste handtekening decodeert precies als een echte, want de handtekening controleren vraagt om de sleutel en die heeft deze pagina niet en wil ze niet.

Het dient om te lezen, niet om te vertrouwen. Wil je weten of een token geldig is, dan moet het systeem dat het heeft uitgegeven dat zeggen; wat deze pagina beantwoordt is wat erin staat, en dat is een andere vraag — meestal de eerste.

Staan er ruitjes met een vraagteken in het resultaat, dan vormden de bytes geen geldige UTF-8. Dat kan betekenen dat het binaire gegevens zijn — een bestand en geen tekst — of dat de tekst oorspronkelijk in Latin-1 is gecodeerd en nu als UTF-8 wordt gelezen.

De twee gevallen zijn aan het patroon uit elkaar te houden: een bestand levert vanaf de eerste byte onzin op, terwijl een Latin-1-tekst prima leest behalve precies bij de trema’s en de accenten. Dat tweede geval is de klassieker van slecht gemigreerde Nederlandse gegevens, en het duikt eerder op in een database met de verkeerde collatie dan in een Base64.

Een `Secret` in Kubernetes bewaart zijn waarden in Base64, en dat brengt veel mensen in verwarring: het is niet versleuteld in rust tenzij dat apart is ingericht, en iedereen met leesrecht op de resource leest het wachtwoord in één stap.

Het helpt dus om scherp te hebben wat wat beschermt. De Base64 zit er zodat binaire waarden in YAML passen, niet om ze te verbergen. De echte bescherming zijn de rechten in het cluster en, waar nodig, versleuteling in rust — en een waarde uit een `Secret` die in een onlinehulpmiddel wordt geplakt, is een wachtwoord dat het cluster heeft verlaten.

Van alle pagina’s op deze site krijgt deze de meeste inloggegevens en persoonsgegevens te zien: webhook-payloads met namen en adressen, tokens die een persoon aanwijzen, dumps van configuratie. Omdat het decoderen op de pagina gebeurt, wordt niets daarvan aan ons verstrekt.

Dat is wat het hulpmiddel bruikbaar maakt in een omgeving met serieus intern beleid. Een dienst die op afstand zou decoderen had het persoonsgegeven ontvangen en zou het in zijn logboeken hebben staan, en dat is precies het geval dat zulk beleid wil voorkomen. Het netwerktabblad toont het in een minuut aan.

Coderen staat op een eigen pagina. Wie codeert bouwt iets en moet één ding kiezen: het alfabet. Wie decodeert leest iets dat is binnengekomen en heeft een heel andere vraag, namelijk wat te doen als het antwoord geen tekst is of niet klopt.

De twee delen dezelfde motor en leggen andere dingen uit, omdat de foutbeelden verschillen. Samengevoegd zou elke bezoeker de helft moeten doorwaden die hem niet aangaat, en zouden juist de details sneuvelen waarvoor hij is gekomen.