"Base64, JWT y Hashing: Qué Son Realmente (Sin Título en Informática)"

La Brecha Entre Usar Algo y Entenderlo

Al principio de mi carrera, estaba depurando un problema de autenticación cuando un desarrollador senior preguntó: "¿Está expirado el JWT?"

Dije que sí, que lo había comprobado. Lo que no admití: había pegado el token en un sitio web, visto el timestamp de expiración, y aún no entendía del todo qué estaba mirando. ¿Era seguro? ¿Podía alguien leer ese token? ¿Estaba cifrado? ¿Por qué cualquier sitio web podía decodificarlo si supuestamente estaba "firmado" y era "seguro"?

Esta guía es para esa versión de mí. Tres conceptos que aparecen constantemente en el desarrollo web, que la mayoría de tutoriales asumen que ya conoces, y que en realidad son sencillos una vez explicados con claridad.

Base64: No es Cifrado. No es Compresión. Solo Traducción.

Lo más importante que debes saber primero: Base64 no es un mecanismo de seguridad. No oculta tus datos. Cualquiera puede decodificarlo al instante. Si alguna vez pensaste "esto parece codificado así que probablemente sea seguro ponerlo en una URL" — no lo es.

Base64 es una forma de representar datos binarios usando solo caracteres ASCII imprimibles. Eso es todo. La razón práctica de su existencia: los datos binarios rompen cosas. Los emails, las cabeceras HTTP, las URLs, los atributos HTML — estos sistemas fueron diseñados para texto. Los datos binarios crudos, con sus bytes nulos y caracteres de control, pueden corromperse o alterarse al pasar por sistemas basados en texto.

Base64 convierte binario a un alfabeto seguro de 64 caracteres: A–Z, a–z, 0–9, + y /. La salida es aproximadamente un 33% más grande que la entrada, pero garantizada de viajar intacta a través de cualquier sistema de texto.

Dónde lo Verás Realmente

Autenticación HTTP Basic: cuando te autenticas con usuario:contraseña, las credenciales se codifican en Base64 y se envían en la cabecera Authorization: Basic. Por eso Basic Auth sobre HTTP plano es peligroso — cualquiera que intercepte la petición puede decodificar las credenciales al instante. HTTPS es obligatorio.

Tokens JWT: cada una de las tres secciones de un token JWT está codificada en Base64url (una variante que reemplaza + y / por - y _ para ser segura en URLs).

Data URIs: <img src="data:image/png;base64,iVBORw0KGgo..."> — incrustar datos de imagen directamente en HTML o CSS en lugar de hacer una petición HTTP separada.

Adjuntos de email: la codificación MIME usa Base64 para que los archivos binarios puedan viajar a través de servidores de correo diseñados solo para texto.

Pruébalo tú mismo: pega cualquier texto en el Codificador Base64 y mira el resultado. Luego pega la cadena codificada de vuelta para decodificarla. Nota que la versión "codificada" no oculta nada — solo usa un alfabeto diferente.

JWT: Tres Cadenas Base64 y una Firma

Un JSON Web Token se ve así:

Exactamente dos puntos. Tres secciones.

Cabecera — la parte antes del primer punto. Se decodifica en metadatos sobre el token: qué algoritmo de firma se usó, qué tipo de token es.

Payload — la sección del medio. Se decodifica en los claims reales: ID de usuario, email, roles, tiempo de expiración. Esto es lo que lee tu backend para identificar al usuario.

Firma — la parte después del segundo punto. Una prueba criptográfica de que el token no fue manipulado.

Lo que Sorprende a la Mayoría de Desarrolladores

El payload está codificado en Base64url. No está cifrado. Cualquiera que tenga el token puede decodificar el payload y leer su contenido — ID de usuario, email, roles, expiración, lo que sea que hayas puesto ahí.

Pega cualquier JWT en el Decodificador JWT y ve exactamente qué hay dentro. No se requiere ninguna clave.

Esto sorprende a la gente porque la cadena parece un galimatías opaco. No lo es. El modelo de seguridad del JWT es: "Puedo verificar que este token fue genuinamente emitido por mi servidor (verificación de firma), así que puedo confiar en los claims que contiene. Pero esos claims en sí mismos no son secretos."

La implicación práctica: no pongas contraseñas, datos de pago ni información personal sensible en payloads JWT. Pon solo lo necesario para identificar y autorizar al usuario.

Qué Garantiza Realmente la Firma

La firma se crea tomando la cabecera + el payload + una clave secreta que solo conoce tu servidor, y pasándolos por una función de hash. Cuando tu servidor recibe un token, recalcula la firma usando el mismo secreto. Si la firma recalculada coincide con la del token, el token es genuino y no modificado.

Si alguien modifica el payload para cambiar el ID de usuario 123 por 456, la verificación de firma falla.

Por eso tu clave secreta de firma JWT debe mantenerse genuinamente secreta. Si un atacante la obtiene, puede falsificar tokens y suplantar a cualquier usuario.

Hashing: Funciones de Una Sola Dirección

Una función hash toma cualquier entrada y produce una salida de tamaño fijo. Dos propiedades la hacen útil para seguridad:

Determinista: la misma entrada siempre produce la misma salida.

Una sola dirección: no puedes revertir el hash para obtener la entrada original. No existe un dehashear().

Un carácter de diferencia. Hash completamente diferente. Sin relación matemática entre entradas similares y salidas similares.

Por Qué las Contraseñas se Hashean, No se Cifran

Si las contraseñas estuvieran cifradas, podrías descifrarlas con la clave correcta. Si un atacante roba tu base de datos y tu clave de cifrado, cada contraseña de usuario queda expuesta.

Con hashing: almacenas el hash, no la contraseña. Cuando un usuario inicia sesión, hasheas lo que escribió y lo comparas con el hash almacenado. Nunca necesitas recuperar el original — solo verificar un intento.

Incluso si un atacante obtiene tu base de datos, solo tiene hashes. Para conseguir una contraseña, tiene que adivinar y verificar, lo cual es mucho más lento.

MD5, SHA-256, bcrypt — Por Qué Importa Cuál Usas

MD5 era el estándar a principios de los 2000. Ahora está roto para propósitos de seguridad. Una GPU moderna puede calcular miles de millones de hashes MD5 por segundo, lo que significa que un atacante con tu base de datos puede crackear contraseñas simples en minutos. Nunca uses MD5 para contraseñas.

SHA-256 es apropiado para verificación de integridad — confirmar que un archivo no fue corrompido, generar firmas HMAC para webhooks. Pero es demasiado rápido para contraseñas. El hashing rápido es malo para contraseñas porque hace los ataques de fuerza bruta baratos.

bcrypt está diseñado específicamente para contraseñas. Es intencionalmente lento — puedes ajustar cuántas rondas de cálculo realiza — e incluye un "salt" incorporado (datos aleatorios) que garantiza que dos contraseñas idénticas produzcan hashes completamente diferentes.

La regla: usa bcrypt (o Argon2, o scrypt) para contraseñas. Usa SHA-256 para todo lo demás que necesite verificación de integridad.

Referencia Rápida

Entender estas tres cosas correctamente evita una clase de errores de seguridad que parecen correctos en la revisión de código y solo se descubren en producción — cuando el daño ya está hecho.

Las herramientas: Base64, Decodificador JWT, Generador de Hash. Úsalas para probar tu comprensión, no solo para obtener resultados.