Strumenti per sviluppatori · Codificatore e decodificatore Base64
Come viene creata e decodificata l'intestazione di autenticazione di base HTTP con Base64
· Come funziona
base64 sicurezza
L'intestazione Authorization: Basic è solo nome utente: password eseguita tramite Base64. Questo post mostra come viene creato il valore, come decodificarne uno da un registro delle richieste e perché la codifica non nasconde nulla.
Il 401 che persiste anche se le credenziali sono corrette: un valore di intestazione che decodifica in una stringa leggermente errata
Un HTTP API restituisce 401 Unauthorized e prevede un'autorizzazione: intestazione Basic. Il valore è la parola dello schema Basic, uno spazio e una stringa Base64. Un prefisso mancante, un prefisso codificato o un ritorno a capo inosservato modifica ciò che il server riceve anche quando il nome utente e la password visibili sembrano corretti.
Decodifica quella stringa e legge nome utente: password (letteralmente due punti tra due). I byte nomeutente:password sono codificati UTF-8 quindi codificati Base64, producendo il valore dell'intestazione. Se le credenziali sono admin:s3cret, i byte UTF-8 sono 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (lettere ASCII più due punti), la codifica Base64 produce YWRtaW46czNjcmV0 e l'intestazione è Autorizzazione: Base YWRtaW46czNjcmV0.
La ricetta di RFC 7617: 'user:pass', UTF-8, Base64 — i passaggi esatti e il ruolo dei due punti
Questo è completo HTTP Schema di autenticazione di base definito in RFC 7617. È semplice, standardizzato e non offre alcuna sicurezza di per sé: chiunque legga l'intestazione può immediatamente decodificarla per leggere la password. Questo è il motivo per cui HTTPS è obbligatorio per l'autenticazione di base. La codifica è un requisito di trasporto, non una funzionalità di sicurezza. La password viaggia come UTF-8 byte, come qualsiasi altro dato; Base64 è solo la notazione utilizzata nel protocollo HTTP.
Se è necessario decodificare l'intestazione Basic dal registro di rete, il processo è semplice: rimuovi Basic, decodifica Base64 il resto e ottieni nome utente: password. I due punti sono delimitatori tra nome utente e password. RFC 7617 specifica che le credenziali sono ID utente: password e i primi due punti sono il separatore. Se la password contiene due punti, i secondi due punti sono solo un altro carattere nella password. Il colon è strutturale perché il ricevente necessita di un confine inequivocabile. Cerca i primi due punti dopo la decodifica; tutto prima identifica l'utente e tutto dopo è la password. I due punti mancanti indicano quindi una coppia di credenziali non valida, non un problema con l'alfabeto Base64.
Esempio funzionante: codifica admin:s3cret e decodifica di un'intestazione da un registro: entrambe le direzioni, incluso un bug di fine riga
Se il nome utente è admin e la password è pass:word, le credenziali sono admin:pass:word, che codifica in YWRtaW46cGFzczp3b3Jk. Quando lo decodifica, deve essere diviso solo sui primi due punti, fornendo il nome utente admin e la password pass:word. La divisione su ogni due punti dividerebbe la password in modo errato. Il parametro charset in RFC 7617 indica che le credenziali sono UTF-8 codificate. Ciò significa che i caratteri nonASCII nei nomi utente o nelle password vengono convertiti in UTF-8 byte prima della codifica Base64.
Se il nome utente è café (e accentata), i byte UTF-8 sono 0x63 0x61 0x66 0xC3 0xA9 (quattro byte per le lettere ASCII più due per i caratteri accentati) e le credenziali complete café:password contengono byte per café, quindi i due punti byte 0x3A, quindi la password. L'output Base64 codifica fedelmente tutti i byte. Il decodificatore deve saper interpretare i byte decodificati come testo UTF-8, non Latin-1.
Password contenenti due punti, spazi e non-ASCII: perché i primi due punti si dividono e a cosa serve il parametro charset
Un esempio funzionante: inizia con admin:s3cret. Converti in UTF-8 byte: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. In decimale: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 codifica questi 12 bytes: raggruppa in quattro gruppi di tre (produci quattro gruppi di quattro caratteri Base64).
Il valore codificato è YWRtaW46czNjcmV0. L'intestazione dell'autorizzazione è Autorizzazione: Base YWRtaW46czNjcmV0. Il lato della password può contenere altri due punti senza spostare il primo confine. Anche gli spazi e il testo nonASCII sopravvivono quando entrambi i peer concordano sulla codifica del testo. ToolAcre può verificare i byte UTF-8 che emette, ma un server più vecchio che prevede un set di caratteri diverso rimane un problema di interoperabilità al di fuori della trasformazione Base64.
Perché non è sicuro senza TLS: la decodifica mostra la password a chiunque veda l'intestazione
Per decodificare l'intestazione ricevuta, rimuovere Basic, decodificare Base64 YWRtaW46czNjcmV0 per recuperare i byte, interpretare come testo UTF-8 per ottenere admin:s3cret, dividere sui primi due punti per estrarre nome utente e password. Un errore comune è trascinare una nuova riga da echo. Se esegui echo admin:s3cret | base64 nella shell Unix, echo aggiunge una nuova riga per impostazione predefinita, quindi codifica admin:s3cret con una nuova riga (13 bytes invece 12).
L'output Base64 è diverso: YWRtaW46czNjcmV0Cg== (riempimento e caratteri extra). L'intestazione di autorizzazione con questo valore avrà esito negativo perché la password include il carattere di nuova riga. La correzione è l'utilizzo di echo -n o tramite pipe tramite printf o uno strumento che non aggiunge i ritorni a capo. Il codificatore e decodificatore Base64 evita questo: codifica esattamente ciò che incolli, senza ritorni a capo nascosti. TLS modifica la minaccia di trasporto, non il formato delle credenziali. All'interno di una connessione protetta l'intestazione è crittografata con il resto della richiesta; una volta che il software lo registra o lo visualizza, il valore Base64 espone nuovamente le credenziali riutilizzabili a chiunque sia in grado di decodificarlo. La redazione è ancora importante in ogni punto di osservazione.
Errori comuni: un ritorno a capo da echo, un prefisso "Basic" mancante e una doppia codifica del valore
Un altro errore è mancante del prefisso Basic. Il valore dell'intestazione dell'autorizzazione non è valido solo su Base64; è il nome dello schema (Basic o Bearer o altri) seguito da uno spazio e quindi dalla credenziale. Alcuni sistemi non riescono a riconoscere YWRtaW46czNjcmV0 come credenziale ma riescono con Basic YWRtaW46czNjcmV0. Se stai eseguendo il debug di 401, controlla se il server sta analizzando correttamente l'intestazione di autorizzazione.
Lo schema non fa distinzione tra maiuscole e minuscole nello standard HTTP ma molte implementazioni fanno distinzione tra maiuscole e minuscole; controlla la documentazione API. La doppia codifica è un'altra modalità di errore. Se codifica Base64 una stringa già codificata Base64, l'output è una stringa diversa. La codifica YWRtaW46czNjcmV0 produce WVdkbWFXNDZjek5qY3JldA== (completamente diverso). Alcuni sistemi potrebbero applicare accidentalmente la codifica due volte: una volta durante l'impostazione delle credenziali e un'altra durante la costruzione dell'intestazione. Una nuova riga da un comando di shell è particolarmente facile da perdere perché può essere codificata come parte della credenziale anziché rifiutata come spazio bianco attorno a Base64. L'intestazione risultante viene decodificata in modo pulito in una password con un byte aggiuntivo, producendo un 401 che assomiglia a un errore di autenticazione lato server.
Cosa non copre: schemi Digest e Bearer e richieste di credenziali del browser
Il decodificatore prevede un singolo livello di Base64, quindi la doppia codifica causa una mancata corrispondenza. Questo è il motivo per cui la registrazione dei valori delle credenziali in formato Base64 (non in testo normale) può creare confusione: se qualcuno applica la decodifica una volta, vedrà nome utente e password; se applicati due volte, vedono l'offuscamento. L'autenticazione del digest (RFC 7616) e l'autenticazione del portatore (per i token OAuth) utilizzano schemi diversi, ciascuno con formati di credenziali diversi.
Il digest richiede che il server invii il nonce, il client calcoli l'hash e l'intestazione includa l'hash più il nome utente, non la password. Il portatore è in genere JSON Web Token (JWT), che è codificato Base64url ma senza prefisso nome utente. L'autenticazione di base è più semplice di entrambe ma completamente insicura senza TLS perché le credenziali sono leggibili nell'intestazione. Digest e Bearer utilizzano lo stesso campo di intestazione Authorization ma assegnano un significato completamente diverso ai loro valori. Le richieste di credenziali del browser aggiungono l'interfaccia utente e il comportamento di memorizzazione nella cache oltre a Basic. Questo articolo si ferma alla costruzione e all'ispezione del payload delle credenziali di base anziché al confronto di tali sistemi di autenticazione.
Conclusione: l'autenticazione di base è Base64, non protezione: in che modo il codificatore e decodificatore Base64 ti consente di controllare il valore di un'intestazione localmente senza inviare le credenziali ovunque
Se API supporta più schemi di autenticazione, scegli il più sicuro disponibile. Il codificatore e decodificatore Base64 può aiutare a eseguire il debug degli errori di autenticazione di base: incolla la stringa delle credenziali (nome utente, due punti e password) e lo strumento produce immediatamente il valore Base64. Confronta il risultato con l'invio dell'intestazione ed è visibile una mancata corrispondenza. Al contrario, incolla il valore dell'intestazione dal registro di rete, rimuovi il prefisso Basic, decodifica per vedere cosa ha visto il server.
Per imparare, incolla admin:s3cret e osserva l'output, quindi modifica la password per vedere come cambia Base64. Comprendere come viene creata l'intestazione chiarisce perché la decodifica richiede la conoscenza del formato RFC e perché i due punti sono elementi strutturali, non Base64. Un controllo locale dovrebbe utilizzare credenziali inventate, non una password live copiata dalla produzione. Codifica la coppia, sposta nuovamente l'output nel pannello di input e decodificalo. La punteggiatura corrispondente e i caratteri finali esatti dimostrano la rappresentazione andata e ritorno prima che l'intestazione venga inviata ovunque.