Inicio Generador Auditoría Privacidad Enlace efímero Caja de archivos

Por qué la clave de descifrado va detrás del # de la URL

El error más fácil al enviar un secreto una vez no es el nombre del algoritmo, es meter la clave en la consulta. Por la especificación URI el navegador no envía el fragmento tras #; el access log suele quedarse con la ruta. Aquí se parte quién ve qué y se dan pasos que puedes comprobar.

Lo más rápido para pasar una contraseña de base de datos es un enlace. El problema: al abrirlo pasa por navegador, proxy, origen y un montón de logs. Lo que controlas no es «si el cifrado suena seguro», sino en qué capa aparece la clave.

Si la clave va en ?key=, forma parte de la petición HTTP y casi siempre entra en el access log. Si va tras #, el navegador la recorta antes de pedir el documento. No es una promesa de producto; es el trato del fragmento en la URI. Esta nota responde: por qué la clave debe ir tras el almohadilla y cómo ver que el servidor no recibió ese trozo.

Qué deja la clave en la consulta

La consulta (de ? a #) es parte del destino. Al pedir /s.html?id=abc&key=MYSECRET van ruta y consulta. Origen, Nginx, CDN, WAF y APM lo ven. El access log suele incluir el URI, así que key=MYSECRET comparte línea con el código y el tiempo.

Esa línea cuesta borrar: rotación a disco, copias, SIEM, «copia este 500». Un fallo de descifrado puede meter la URL con clave en un informe de caída. Puedes auditar el protocolo, no la norma interna del centro de datos.

Hay más copias: historial del navegador, capturas del «URL completo» y scripts que mandan location.href. El fragmento tapa la copia del servidor, no todas las del dispositivo. Tapar el servidor es el mínimo para que el envío de una vez tenga sentido.

Meter la clave en un POST tampoco basta si el JSON lleva claro o clave. La regla: lo que sale del navegador es un id y cifrado; lo que abre el cifrado no puede ir en un campo que entre en logs.

HTTPS no impide que el origen lea la consulta

TLS cubre a quien escucha en el camino. Tras terminar TLS, el origen ve la línea de petición en claro. La consulta es visible; el fragmento ni siquiera está en esa petición.

Adónde va en HTTP lo que hay tras #

Un URI se parte en esquema, host, ruta, consulta y fragmento. El fragmento empieza por #. La especificación pide al agente quitarlo antes de pedir el documento. La línea HTTP no tiene esa columna; proxy y origen no pueden escribirla en el access log.

Cuando la página carga, el script lee location.hash. Es una cadena en memoria del cliente, no un campo que devuelva el servidor. El orden típico: pedir el cifrado por el id y descifrar con AES-GCM y la clave local. El servidor solo toca cifrado.

El enlace efímero de MyPassGen sigue ese orden: AES-256-GCM en el navegador, clave de 256 bits en Base64URL tras #; se suben cifrado y metadatos de caducidad y lecturas. Quien lee no se registra. Tras la primera lectura el cifrado se quema. Son hechos del producto, no «prometemos no mirar».

Qué deberías ver en la petición y qué no

El POST de creación debe llevar cifrado, no el texto ni la clave que luego va tras #. El GET de lectura solo lleva el id; la URL en Red debe parar antes de #. Si buscas un trozo de la clave y aciertas una petición, la clave está mal colocada o un script mandó location.href entero.

Trozo de URL Ejemplo ¿Lo ve servidor / proxy? ¿Sirve para la clave?
Ruta/s.htmlSí, entra en el access logSolo el id del cifrado
Consulta?id=abc&key=…Toda, por defecto en el logNo; key= es escribir el log
FragmentoClave Base64URL tras #No está en HTTPSí, como canal «solo navegador»
CuerpoJSON al crearEl origen lo ve; algunos proxies muestreanSolo cifrado y metadatos no sensibles

«Cero conocimiento» aquí es estrecho: el servidor guarda y no puede abrir. No es «no guardamos nada» ni «quien tiene el enlace completo no abre». El enlace completo es la credencial; sin el trozo tras # no abre, otra copia es otra llave.

Comprobar en Red si la clave salió

01

Prepara un enlace con almohadilla. Uno recién creado o cualquier página local con #TESTKEY-solo-comprobar. Copia lo que va tras #.

02

Abre Red y Preserve log. La barra de direcciones sigue mostrando el URL completo; eso es la UI del navegador, no lo que salió a la red.

03

Abre el enlace. En el documento y el XHR, la Request URL debe parar antes de #. Puede haber id; no la clave del bloc.

04

Busca un trozo de la clave en todo el panel. Si no hay aciertos, al menos esta navegación no mandó el fragmento como HTTP.

05

Contrasta el error. Pon la misma clave en ?key= (valor de prueba). Esta vez la búsqueda debe acertar la URL. Las dos capturas juntos bastan.

06

Al crear, busca el original. El POST debe parecer cifrado, no el texto. Quien lee no inicia sesión.

Qué prueba esto y qué no

Red dice si esta operación metió clave u original en HTTP. No ve extensiones, XSS o un proxy de empresa. Basta para desmontar «la clave está en la consulta».

El fragmento tapa el log, no el reenvío del enlace

Poner la clave tras # evita que origen y proxy la lean por defecto. Siguen existiendo otros caminos.

El enlace completo descifra

Quien tiene ruta más fragmento abre el cifrado hasta que se queme o caduque. Historial, correo, pantalla compartida y mirar por encima del hombro no los cubre HTTP. El enlace efímero reduce reaperturas y claro en el servidor; no impide capturas ni reenvíos.

Referer, tarjetas de vista previa, analítica

Los navegadores modernos suelen omitir el fragmento en Referer, pero eso no salva un location.href entero en un evento. Al comprobar analítica, busca la misma clave. Algunos clientes recortan # al previsualizar: prueba en una ventana privada antes de fiarte.

Historial y scripts locales

El URL completo entra en el historial. XSS puede leer location.hash. Eso es endpoint y cadena frontend, distinto de «el servidor no debe tener la clave».

Qué debe quedarse tras # y qué puede ir al servidor

Debe quedarse en el dispositivo, y solo pasar al navegador del destinatario por el fragmento, lo que restaura el claro: la clave simétrica.

Puede salir lo inútil para el servidor: blob cifrado, id, caducidad y lecturas máximas. El tope del enlace es 32 KB. Un archivo grande se cifra antes en local como .lock / .enc. Tras la primera lectura el servidor borra el cifrado. No hay copia en claro: no pidas a soporte que «lo recupere».

Cuando quieres enviar una clave sin escribirla en el log

Correo e IM dejan la contraseña en historiales. Un disco por defecto es legible. La clave en la consulta pide al proxy que la anote. Esas rutas tienen la ventana de claro dentro del protocolo.

Para un secreto corto —root, código, una cadena de conexión— hace falta: cifrado en local, clave fuera de HTTP, el destinatario abre y lee, el cifrado desaparece. El enlace efímero de MyPassGen sigue esa regla. Abre Red y busca la clave que acabas de copiar.

Si pasa de 32 KB o necesitas un archivo que se pueda descifrar otra vez, usa la caja. Sobre por qué el cálculo no debería ir al servidor, la nota por qué el cálculo debe quedarse en el navegador abre más la ventana de claro. Aquí solo hace falta responder: al abrir este enlace, ¿la clave sigue tras el almohadilla o ya entró en la línea de petición?