Herramientas de desarrollo · Codificador y decodificador Base64
Cómo se construye y decodifica el encabezado de autenticación HTTP básico con Base64
· Cómo funciona
base64 seguridad
El encabezado Autorización: Básico es solo nombre de usuario: contraseña ejecutado a través de Base64. Esta publicación muestra cómo se crea el valor, cómo decodificar uno de un registro de solicitudes y por qué la codificación no oculta nada.
El 401 que persiste aunque las credenciales sean correctas: un valor de encabezado que se decodifica en una cadena sutilmente incorrecta
Una API HTTP devuelve 401 No autorizado y espera un encabezado Autorización: Básico. El valor es la palabra de esquema Básico, un espacio y una cadena Base64. Un prefijo faltante, un prefijo codificado o una nueva línea inadvertida cambia lo que recibe el servidor incluso cuando el nombre de usuario y la contraseña visibles parecen correctos.
Decodifica esa cadena y lee nombre de usuario: contraseña (literalmente dos puntos entre dos). Los bytes nombre de usuario:contraseña están codificados UTF-8 y luego codificados en Base64, lo que produce un valor de encabezado. Si las credenciales son admin:s3cret, UTF-8 bytes son 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (letras ASCII más dos puntos), la codificación Base64 produce YWRtaW46czNjcmV0 y el encabezado es Autorización: Básica YWRtaW46czNjcmV0.
La receta del RFC 7617: 'user:pass', UTF-8, Base64: los pasos exactos y la función de los dos puntos
Este es el esquema de autenticación HTTP básico completo definido en RFC 7617. Es simple, estandarizado y no ofrece seguridad por sí solo: cualquiera que lea el encabezado puede decodificarlo inmediatamente para leer la contraseña. Es por eso que HTTPS es obligatorio para la autenticación básica. La codificación es un requisito de transporte, no una característica de seguridad. La contraseña viaja como UTF-8 bytes, igual que cualquier otro dato; Base64 es solo una notación utilizada en el protocolo HTTP.
Si necesita decodificar el encabezado Básico del registro de red, el proceso es sencillo: elimine el Básico, decodifique el resto en Base64 y tendrá el nombre de usuario:contraseña. Los dos puntos son el delimitador entre el nombre de usuario y la contraseña. RFC 7617 especifica que las credenciales son ID de usuario: contraseña y los primeros dos puntos son el separador. Si la contraseña contiene dos puntos, los segundos dos puntos son solo otro carácter de la contraseña. Los dos puntos son estructurales porque el receptor necesita un límite inequívoco. Busca los primeros dos puntos después de la decodificación; todo lo anterior identifica al usuario y todo lo posterior es la contraseña. Por lo tanto, la falta de dos puntos indica un par de credenciales con formato incorrecto, no un problema de alfabeto Base64.
Ejemplo resuelto: codificar admin:s3cret y decodificar un encabezado de un registro: ambas direcciones, incluido un error de nueva línea final
Si el nombre de usuario es admin y la contraseña es contraseña, las credenciales son admin:contraseña, que codifica YWRtaW46cGFzczp3b3Jk. Al decodificarlo, debe dividirse solo en los primeros dos puntos, dando el nombre de usuario admin y la contraseña: contraseña. Dividir cada dos puntos dividiría incorrectamente la contraseña. El parámetro charset en RFC 7617 indica que las credenciales están codificadas UTF-8. Esto significa que los caracteres que no son ASCII en nombres de usuarios o contraseñas se convierten a UTF-8 bytes antes de la codificación Base64.
Si el nombre de usuario es café (e acentuada), UTF-8 bytes son 0x63 0x61 0x66 0xC3 0xA9 (cuatro bytes para letras ASCII más dos para caracteres acentuados) y las credenciales completas café:contraseña tienen bytes para café, luego dos puntos, byte 0x3A y luego contraseña. La salida Base64 codifica fielmente todos los bytes. El decodificador debe saber interpretar los bytes decodificados como texto UTF-8, no como texto latino-1.
Contraseñas que contienen dos puntos, espacios y no ASCII: por qué se dividen los primeros dos puntos y para qué sirve el parámetro charset
Un ejemplo resuelto: comience con admin:s3cret. Convertir a UTF-8 bytes: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. En decimal: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 codifica estos 12 bytes: agrupa en cuatro grupos de tres (produce cuatro grupos de cuatro caracteres Base64).
El valor codificado es YWRtaW46czNjcmV0. El encabezado de autorización es Autorización: Básica YWRtaW46czNjcmV0. El lado de la contraseña puede contener otros dos puntos sin mover ese primer límite. Los espacios y el texto que no es ASCII también sobreviven cuando ambos pares coinciden en la codificación del texto. ToolAcre puede verificar los UTF-8 bytes que emite, pero un servidor antiguo que espera un juego de caracteres diferente sigue siendo un problema de interoperabilidad fuera de la transformación Base64.
Por qué esto no es seguro sin TLS: la decodificación muestra la contraseña a cualquiera que vea el encabezado
Para decodificar el encabezado recibido, elimine Basic, Base64 decodifica YWRtaW46czNjcmV0 para recuperar bytes, interprete como texto UTF-8 para obtener admin:s3cret, divida en los primeros dos puntos para extraer el nombre de usuario y la contraseña. Un error común es arrastrar una nueva línea desde el eco. Si ejecuta echo admin:s3cret | base64 en el shell de Unix, echo agrega una nueva línea de forma predeterminada, por lo que codifica admin:s3cret con una nueva línea (13 bytes en lugar de 12).
La salida de Base64 es diferente: YWRtaW46czNjcmV0Cg== (relleno y caracteres adicionales). El encabezado de autorización con este valor fallará porque la contraseña incluye un carácter de nueva línea. La solución es usar echo -n o canalizar printf o una herramienta que no agregue nuevas líneas. El codificador y decodificador Base64 evita esto: codifica exactamente lo que pegas, sin nuevas líneas ocultas. TLS cambia la amenaza de transporte, no el formato de la credencial. Dentro de una conexión protegida, el encabezado se cifra con el resto de la solicitud; una vez que el software lo registra o lo muestra, el valor Base64 vuelve a exponer la credencial reutilizable a cualquiera que pueda decodificarla. La redacción sigue siendo importante en todos los puntos de observación.
Errores comunes: una nueva línea de eco, falta el prefijo 'Básico ' y codificación doble del valor
Otro error. Falta el prefijo básico. El valor del encabezado de autorización no es válido solo para Base64; es el nombre del esquema (Básico o Portador u otros) seguido de un espacio y luego la credencial. Algunos sistemas no reconocen YWRtaW46czNjcmV0 como credencial, pero tienen éxito con YWRtaW46czNjcmV0 básico. Si está depurando 401, verifique si el servidor está analizando el encabezado de Autorización correctamente.
El esquema no distingue entre mayúsculas y minúsculas en el estándar HTTP, pero muchas implementaciones sí lo hacen; consulte la documentación de la API. La doble codificación es otro modo de falla. Si Base64 codifica una cadena que ya está codificada en Base64, la salida es una cadena diferente. La codificación YWRtaW46czNjcmV0 produce WVdkbWFXNDZjek5qY3JldA== (completamente diferente). Algunos sistemas pueden aplicar accidentalmente la codificación dos veces: una durante la configuración de credenciales y otra al crear el encabezado. Es especialmente fácil pasar por alto una nueva línea de un comando de shell porque puede codificarse como parte de la credencial en lugar de rechazarse como espacios en blanco alrededor de Base64. El encabezado resultante se decodifica limpiamente en una contraseña con un byte adicional, lo que produce un 401 que parece un error de autenticación del lado del servidor.
Lo que esto no cubre: esquemas de resumen y portador, y solicitudes de credenciales del navegador
El decodificador espera una sola capa de Base64, por lo que la doble codificación provoca una falta de coincidencia. Esta es la razón por la que registrar valores de credenciales en formato Base64 (no en texto sin formato) puede resultar confuso: si alguien aplica la decodificación una vez, ve el nombre de usuario y la contraseña; si se aplica dos veces, ven confusión. La autenticación implícita (RFC 7616) y la autenticación de portador (para tokens OAuth) utilizan esquemas diferentes, cada uno con diferentes formatos de credenciales.
El resumen requiere que el servidor envíe el nonce, el cliente calcule el hash y el encabezado incluya el hash más el nombre de usuario, no la contraseña. El portador suele ser el token web JSON (JWT), que está codificado en Base64url pero sin el prefijo de nombre de usuario. La autenticación básica es más simple que ambas pero completamente insegura sin TLS porque las credenciales se pueden leer en el encabezado. Digest y Bearer utilizan el mismo campo de encabezado de Autorización pero asignan significados completamente diferentes a sus valores. Las solicitudes de credenciales del navegador agregan interfaz de usuario y comportamiento de almacenamiento en caché además del Básico. Este artículo se detiene en construir e inspeccionar la carga útil de credenciales básicas en lugar de comparar esos sistemas de autenticación.
Conclusión: la autenticación básica es Base64, no protección: cómo el codificador y decodificador Base64 le permite verificar un valor de encabezado localmente sin enviar la credencial a ninguna parte
Si la API admite múltiples esquemas de autenticación, elija el más seguro disponible. El codificador y decodificador Base64 puede ayudar a depurar fallas de autenticación básica: pegue la cadena de credenciales (nombre de usuario, dos puntos y contraseña) y la herramienta produce el valor Base64 inmediatamente. Compare el resultado con el envío del encabezado y verá una discrepancia visible. Por el contrario, pegue el valor del encabezado del registro de red, elimine el prefijo básico y decodifique para ver qué vio el servidor.
Para aprender, pegue admin:s3cret y observe el resultado, luego modifique la contraseña para ver cómo cambia Base64. Comprender cómo se construye el encabezado aclara por qué la decodificación requiere conocer el formato RFC y por qué los dos puntos son un elemento estructural, no Base64. Una verificación local debe utilizar una credencial inventada, no una contraseña activa copiada de producción. Codifique el par, mueva la salida nuevamente al panel de entrada y decodifíquela. La puntuación coincidente y los caracteres finales exactos demuestran la representación de ida y vuelta antes de que el encabezado se envíe a cualquier parte.