Codificare in Base64

Il Base64 non cifra e non comprime: riscrive dei byte usando solo 64 caratteri che sopravvivono a quasi qualunque trasporto. Prende tre byte, li guarda come 24 bit e li ritaglia in quattro pezzi da sei, e ogni pezzo diventa un carattere della tabella.

Da lì viene il suo costo: il risultato occupa sempre un terzo in più dell’originale. È il prezzo per attraversare un canale che capisce solo testo, ed è il motivo per cui un allegato di posta pesa più del file che contiene — la posta, sotto sotto, è ancora un protocollo di testo.

L’alfabeto standard usa `+` e `/` per gli ultimi due caratteri. Tutti e due hanno un significato dentro una URL: la barra separa i segmenti di percorso e il più viene letto come spazio in una query string. Un valore in Base64 standard infilato in un indirizzo arriva quindi cambiato.

La variante sicura per URL sostituisce quei due con `-` e `_`, che non significano niente in nessun punto di un indirizzo. È quella che usano i JWT, ed è il motivo per cui un token copiato da un’intestazione non contiene né barre né segni più. Se il valore deve viaggiare in una URL, l’opzione è quella; altrimenti lo standard è ciò che tutto il resto si aspetta.

Il Base64 lavora tre byte alla volta. Quando l’input non è un multiplo di tre ne avanzano uno o due, e il riempimento viene segnalato con uno o due segni di uguale in fondo. È per questo che un risultato finisce con `=`, con `==` o con niente, e per questo la sua lunghezza è sempre un multiplo di quattro.

Quel padding è facoltativo in alcune specifiche e obbligatorio in altre, il che produce un malinteso ricorrente: i JWT lo omettono di proposito, mentre parecchie librerie si rifiutano di decodificare senza. Se qualcosa rifiuta un valore che sembra corretto, il numero di caratteri è la prima cosa da guardare.

Il Base64 codifica byte, non caratteri, quindi prima bisogna decidere come il testo diventa byte. Qui è sempre UTF-8, dove una `à` sono due byte — `c3 a0` — e così una `è` e una `ù`; un emoji ne vale quattro. La stringa Base64 è di conseguenza più lunga di quanto sarebbe se il testo fosse solo ASCII.

Lì sta l’errore più comune quando si confronta con un altro strumento: se dall’altra parte hanno usato Latin-1, la `à` era un byte invece di due e i risultati non coincidono. Non è un difetto di nessuno dei due codificatori — stavano codificando testi diversi, e il disaccordo è uno strato più in basso.

L’intestazione `Authorization: Basic` è esattamente `utente:password` in Base64, e nient’altro. Chiunque veda quell’intestazione la disfa in un secondo, perché non c’è nessuna chiave: è una codifica, non una cifratura.

Quelle credenziali le protegge HTTPS e solo HTTPS. Per questo Basic Auth su HTTP in chiaro equivale a mandare la password in chiaro, e per questo un’intestazione del genere dentro uno screenshot, un ticket o un log è una credenziale esposta. Che sembri illeggibile non cambia niente.

Un’immagine in Base64 dentro un `src` risparmia una richiesta, ed è ragionevole per un’icona piccola o per un SVG di pochi kilobyte. Da lì in poi smette di convenire: il file cresce di un terzo, viene incorporato nell’HTML e quindi non si mette in cache per conto suo, e il browser deve analizzarlo prima di disegnare qualsiasi cosa.

Il punto in cui il segno si inverte dipende dalla pagina, ma la regola spannometrica tiene: sotto qualche kilobyte la data URI quasi sempre vince, sopra qualche decina quasi sempre perde. Un’immagine grande incorporata trasforma ogni visita in uno scaricamento completo dell’HTML gonfiato.

Compare con una certa regolarità come modo per «nascondere» una chiave nel codice di un’app, in un file di configurazione o in uno script. Non nasconde niente: tornare indietro è un bottone, e gli strumenti che cercano segreti finiti nei repository riconoscono le stringhe Base64 proprio perché sono un pattern facilissimo da individuare.

Quello che fa davvero è togliere il campanello d’allarme a chi guarda di sfuggita, ed è quello il problema: un segreto in chiaro si vede e si corregge, uno in Base64 passa una revisione. Se qualcosa deve restare nascosto serve una cifratura con una chiave che stia altrove, oppure non metterlo lì.

Certe specifiche vogliono il Base64 spezzato: MIME manda a capo ogni 76 caratteri, i blocchi PEM ogni 64. Quegli a capo fanno parte del formato che li richiede e non del valore, e questa pagina non li mette perché quello che si incolla in un campo di solito va in un’intestazione, in un JSON o in una variabile d’ambiente, dove una riga sola è l’unica forma che funziona.

Nell’altro verso vale la regola opposta: un decodificatore serio ignora gli spazi bianchi, perché un PEM copiato da un terminale arriva per forza spezzato. Se qualcosa rifiuta un valore che a occhio è giusto, prova prima a togliere gli a capo — è il caso più frequente e il più facile da escludere.

Il Base64 non aggiunge nessun controllo: non c’è checksum, non c’è lunghezza dichiarata, non c’è modo di accorgersi che manca un pezzo. Una stringa troncata resta Base64 valido finché la lunghezza torna, e decodifica in byte che finiscono a metà parola senza che nessuno protesti.

È per questo che, quando si sposta un valore importante, la verifica va messa accanto e non dentro: un hash del contenuto, oppure il confronto della lunghezza in byte prima e dopo. Chi si aspetta che il Base64 «se ne accorga» ha in mano un formato di trasporto e lo sta usando come se fosse un formato di archiviazione.

Quello che digiti qui non lascia il dispositivo, quindi non c’è nessuna comunicazione di dati verso di noi. È il punto che conta quando nel campo finisce una password, un token o un payload con dentro il nome di un cliente: non serve un accordo di trattamento per qualcosa che non ci è mai arrivato.

Quello che rimane visibile è il resto del sito, e sta scritto nell’informativa: la visita, le richieste di pubblicità e, se acconsenti, di statistica. Distinguere le due cose è la parte onesta della faccenda — il contenuto del campo non si muove mai, il fatto che tu sia su questa pagina invece sì.

Codificare e decodificare sembrano lo stesso problema visto da due lati e non lo sono. Chi codifica sta costruendo qualcosa e ha una sola domanda: quale alfabeto. Chi decodifica ha in mano qualcosa di rotto e ne ha cinque, tutte diverse, e nessuna riguarda l’alfabeto.

Una pagina sola con un selettore risponderebbe male a entrambi, perché metà del testo sarebbe sempre fuori tema. La pagina per decodificare è a un clic da qui e parla dei suoi problemi: il padding mancante, i byte che non sono testo, i JWT. Questa parla dei tuoi.