Base64 coderen

Base64 versleutelt niet en comprimeert niet: het herschrijft bytes met maar 64 tekens die vrijwel elk transport overleven. Het neemt drie bytes, bekijkt die als 24 bits en verdeelt ze in vier stukjes van zes, en elk stukje wordt één teken uit de tabel.

Daar komt de prijs vandaan: het resultaat is altijd een derde groter dan het origineel. Dat is wat het kost om door een kanaal te komen dat alleen tekst begrijpt, en het is de reden dat een mailbijlage zwaarder weegt dan het bestand dat erin zit — e-mail is vanbinnen nog altijd een tekstprotocol.

Het standaardalfabet gebruikt `+` en `/` voor de laatste twee tekens. Allebei betekenen ze iets binnen een URL: de schuine streep scheidt padsegmenten en de plus wordt in een query string als spatie gelezen. Een waarde in standaard-Base64 die in een adres wordt gezet, komt dus veranderd aan.

De URL-veilige variant vervangt die twee door `-` en `_`, die nergens in een adres iets betekenen. Het is wat JWT’s gebruiken, en het is de reden dat een token uit een header geen schuine strepen of plussen bevat. Gaat de waarde in een URL reizen, dan is dat de keuze; anders is het standaardalfabet wat al het overige verwacht.

Base64 werkt per drie bytes. Als de invoer geen veelvoud van drie is, blijft er één of blijven er twee over, en die opvulling wordt met één of twee isgelijktekens gemarkeerd. Daarom eindigt een resultaat op `=`, op `==` of op niets, en daarom is de lengte altijd een veelvoud van vier.

Die padding is in sommige specificaties optioneel en in andere verplicht, wat een terugkerend misverstand oplevert: JWT’s laten haar met opzet weg, terwijl veel bibliotheken zonder haar weigeren te decoderen. Weigert iets een waarde die er goed uitziet, dan is het aantal tekens het eerste om naar te kijken.

Base64 codeert bytes en geen tekens, dus eerst moet worden besloten hoe de tekst bytes wordt. Hier is dat altijd UTF-8, waar een `ë` twee bytes is en een `é` ook, en een emoji vier. De Base64-tekst is navenant langer dan wanneer de tekst alleen ASCII was.

Daar zit de gebruikelijkste vergissing bij het vergelijken met een ander hulpmiddel: gebruikte de tegenpartij Latin-1, dan was de `ë` één byte in plaats van twee en komt het resultaat niet overeen. Geen van beide coders heeft een fout gemaakt — ze codeerden verschillende teksten, en het misverstand zit een laag dieper.

De header `Authorization: Basic` is precies `gebruiker:wachtwoord` in Base64, en verder niets. Iedereen die de header ziet, draait hem in een seconde terug, want er is geen sleutel: het is een codering en geen versleuteling.

Wat die inloggegevens beschermt is HTTPS en alleen HTTPS. Daarom staat Basic Auth over gewone HTTP gelijk aan het wachtwoord in leesbare vorm versturen, en daarom is zo’n header in een schermafdruk, in een ticket of in een logbestand een blootgelegd wachtwoord. Dat het onleesbaar oogt verandert daar niets aan.

Een afbeelding in Base64 binnen een `src` scheelt een verzoek, en dat is verstandig bij een klein pictogram of een SVG van een paar kilobytes. Daarboven houdt het op: het bestand groeit een derde, het zit in de HTML en wordt dus niet apart gecachet, en de browser moet het verwerken voordat er iets getekend wordt.

Waar het omslagpunt precies ligt hangt van de pagina af, maar de vuistregel houdt stand: onder een paar kilobytes wint de data-URI bijna altijd, boven enkele tientallen verliest hij bijna altijd. Een grote ingesloten afbeelding maakt van elk bezoek een volledige download van de opgeblazen HTML.

Het duikt met enige regelmaat op als manier om een sleutel te «verstoppen» in de code van een app, in een configuratiebestand of in een script. Het verstopt niets: de weg terug is één knop, en de scanners die naar gelekte secrets zoeken herkennen Base64-reeksen juist omdat het een bijzonder makkelijk patroon is.

Wat het wél doet, is de waarschuwing weghalen voor wie er vluchtig overheen kijkt, en dat is het probleem: een sleutel in leesbare vorm valt op en wordt hersteld, een sleutel in Base64 komt door een code review heen. Moet er echt iets verborgen blijven, dan is er versleuteling nodig met een sleutel die ergens anders woont — of je zet het er niet in.

E-mail knipt Base64 in regels van 76 tekens omdat een standaard uit 1996 dat eist, en certificaten in PEM-vorm gebruiken 64. Die opmaak is volkomen geldig, maar veel moderne decoders verslikken zich in de regeleindes als die er niet eerst uit gehaald worden.

Deze pagina levert één doorlopende regel, en dat is wat vrijwel elke hedendaagse API verwacht. Moet je het resultaat in iets plakken dat de regelopmaak eist, dan doe je dat knippen zelf — en decodeer je iets met regeleindes erin, dan negeert de decoder van deze site ze.

Elke tekst laat zich in Base64 coderen: er bestaat geen ongeldige invoer, en dus ook geen mogelijke fout in deze richting. Dat is prettig en er zit een val in, want een Base64-tekst kan prima onzin bevatten en er toch onberispelijk uitzien.

De controle hoort er dus vóór: codeer je JSON, valideer het dan eerst; codeer je een identifier, kijk dan of het de juiste is. Een verkeerd gevormde waarde ziet er gecodeerd precies zo uit als een goede, en de fout komt aan de andere kant boven, waar hij veel duurder is om te vinden.

Wat in dit veld geplakt wordt is meestal precies wat je liever niet verplaatst: inloggegevens, een payload met klantgegevens, de inhoud van een configuratiebestand. Omdat het coderen op de pagina gebeurt, is er geen verstrekking aan ons en dus ook geen verwerking in onze opdracht van die inhoud.

Je controleert het in het netwerktabblad: terwijl je het hulpmiddel gebruikt, vertrekt er geen enkel verzoek dat je invoer draagt. Wat er wel is staat in de privacyverklaring — het bezoek en de advertentie- en statistiekverzoeken. De inhoud van het veld zit daar niet bij, en bij dit soort waarden is dat het enige wat telt.

Decoderen heeft een eigen pagina, en die scheiding is geen kwestie van gemak. Wie codeert is iets aan het bouwen en heeft één beslissing te nemen: welk alfabet. Wie decodeert is iets aan het lezen dat is binnengekomen en heeft een ander probleem: wat te doen als er geen tekst uit komt.

De twee pagina’s delen dezelfde motor en leggen andere dingen uit omdat de fouten anders zijn. Ze samenvoegen zou elke bezoeker dwingen de helft te lezen die hem niet aangaat, en zou juist de details weglaten waarvoor hij gekomen is.