Si necesitas enviar una contraseña, clave API o credencial de base de datos a alguien fuera de tu sistema, el patrón más seguro es cifrarla en el navegador del remitente, enviar solo texto cifrado a un servidor y entregar la clave de descifrado al destinatario de una manera que el servidor nunca vea. Esta es la esencia del intercambio de conocimiento cero. A continuación se muestra un ejemplo práctico de encriptación que muestra cómo enviar credenciales con conocimiento cero, además de un flujo de trabajo simple que puedes adoptar hoy.

Cómo se ve el "conocimiento cero" en la práctica

Conocimiento cero en este contexto significa que el servicio que retransmite tu mensaje no puede leerlo. La clave de encriptación nunca sale de los navegadores, el servidor solo ve texto cifrado y el secreto se destruye después de su uso.

Un diagrama simple: el navegador del remitente cifra una contraseña usando AES-256 y un IV aleatorio, sube solo texto cifrado y metadatos a un servidor de retransmisión, el enlace que el remitente comparte contiene la clave de descifrado en el fragmento de URL (#key). El navegador del destinatario obtiene el texto cifrado del servidor, usa la clave del fragmento para descifrar localmente, luego el servidor elimina el texto cifrado después de un solo acceso.

Dos detalles hacen que esto funcione:

  • Encriptación del lado del cliente, por lo que el texto plano existe solo en los navegadores del remitente y del destinatario.
  • Clave en el fragmento de URL, por lo que la clave nunca se transmite al servidor. El fragmento, todo lo que viene después del #, no se envía en las solicitudes HTTP, ver RFC 3986, Sección 3.5.

Para encriptación autenticada, las implementaciones modernas típicamente usan AES-GCM con una clave de 256 bits, que está estandarizada por NIST, ver NIST SP 800-38D. Si deseas una introducción rápida al algoritmo y por qué las organizaciones confían en él, lee nuestra guía en lenguaje sencillo, AES 256 explicado para no ingenieros.

Un ejemplo mínimo de encriptación en el navegador (solo para educación)

El siguiente JavaScript muestra el núcleo de un flujo de conocimiento cero usando la API Web Crypto. Genera una clave aleatoria de 256 bits, cifra una credencial con AES‑GCM, sube solo texto cifrado e IV a un servidor, luego construye un enlace que lleva la clave de descifrado en el fragmento.

Importante, este código es para aprendizaje, no para producción. Como OWASP aconseja, no crees tu propia criptografía o protocolo en producción, usa bibliotecas y servicios verificados, ver la Hoja de referencia de almacenamiento criptográfico de OWASP y la documentación de la API Web Crypto.

// Ejemplo mínimo de conocimiento cero con AES-GCM (solo para educación)
// 1) Cifrar en el navegador  2) Subir solo texto cifrado  3) Poner clave en fragmento de URL

const te = new TextEncoder();
const td = new TextDecoder();

function toB64url(buf) {
  const bytes = buf instanceof ArrayBuffer ? new Uint8Array(buf) : new Uint8Array(buf.buffer || buf);
  let bin = "";
  for (let i = 0; i < bytes.length; i++) bin += String.fromCharCode(bytes[i]);
  return btoa(bin).replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/g, "");
}

function fromB64url(s) {
  const base64 = s.replace(/-/g, "+").replace(/_/g, "/") + "===".slice((s.length + 3) % 4);
  const bin = atob(base64);
  const out = new Uint8Array(bin.length);
  for (let i = 0; i < bin.length; i++) out[i] = bin.charCodeAt(i);
  return out;
}

async function createZeroKnowledgeLink(secret) {
  // Clave AES-GCM de 256 bits
  const key = await crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]);

  // Nunca reutilices un IV con la misma clave
  const iv = crypto.getRandomValues(new Uint8Array(12));

  const plaintext = te.encode(secret);
  const ciphertext = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, plaintext);
  const keyRaw = await crypto.subtle.exportKey("raw", key);

  // Enviar solo texto cifrado + IV a tu API de retransmisión
  const payload = {
    ciphertext: toB64url(ciphertext),
    iv: toB64url(iv),
    expireViews: 1,         // acceso de un solo uso
    ttlSeconds: 600         // expiración de 10 minutos
  };

  // Reemplaza con tu endpoint backend que almacena texto cifrado de forma efímera
  const res = await fetch("/api/secret", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });
  const { id } = await res.json();

  // Pon la clave de descifrado en el fragmento de URL para que el servidor nunca la reciba
  const keyB64 = toB64url(keyRaw);
  const link = `https://your-app.example/secret/${id}#k=${keyB64}`;
  return link;
}

// La lógica del navegador del destinatario haría lo contrario: obtener texto cifrado, importar clave del fragmento, descifrar localmente.
async function openZeroKnowledgeLink(id, keyB64) {
  const r = await fetch(`/api/secret/${id}`);   // el servidor debería devolver 404 y eliminar después de la primera lectura
  const { ciphertext, iv } = await r.json();

  const keyRaw = fromB64url(keyB64);
  const cryptoKey = await crypto.subtle.importKey("raw", keyRaw, { name: "AES-GCM" }, false, ["decrypt"]);

  const pt = await crypto.subtle.decrypt(
    { name: "AES-GCM", iv: fromB64url(iv) },
    cryptoKey,
    fromB64url(ciphertext)
  );
  return td.decode(pt);
}

Notas para precisión y seguridad:

  • AES-GCM requiere un IV único para cada encriptación con una clave determinada. Usa un IV aleatorio de 96 bits por mensaje y nunca lo reutilices.
  • El servidor debe hacer cumplir el acceso de un solo uso y la eliminación en la primera recuperación. Mantén solo texto cifrado y metadatos mínimos, nunca almacenes claves o texto plano.
  • Si necesitas frases de contraseña ingresadas por humanos, usa un KDF como PBKDF2 o Argon2 para derivar una clave fuerte antes de AES-GCM. Para la mayoría de las transferencias de credenciales ad-hoc, una clave aleatoria en el fragmento de URL es más simple y más fuerte.

Si prefieres no construir o mantener esto tú mismo, Nurbak ya implementa un modelo de conocimiento cero con AES‑256, enlaces de un solo uso, sin registro de datos, registros de acceso de auditoría y un panel de administración limpio. Ver nuestro análisis, Encriptación del Lado del Cliente vs. del Servidor: Por Qué Importa para Tus Secretos.

Paso a paso: enviar credenciales con conocimiento cero

Aquí hay un proceso conciso y repetible que los equipos usan para claves API, contraseñas de bases de datos, credenciales de emergencia SSO y códigos de recuperación.

  1. Prepara la credencial. Limítala al menor privilegio, agrega una expiración y, si es posible, crea un valor temporal que rotarás después de la transferencia.
  2. Crea un enlace de autodestrucción de un solo uso. Usa una herramienta de conocimiento cero que cifre en el navegador y elimine el texto cifrado después del primer acceso o TTL corto.
  3. Entrega el contexto y el enlace en canales separados. Envía el enlace a través de tu canal normal y envía cualquier contexto o instrucciones en un segundo canal. Esto reduce los riesgos de vista previa accidental y ayuda a la verificación resistente al phishing.
  4. Confirma la recepción. Pide al destinatario que confirme que ha almacenado el secreto en su administrador de contraseñas, luego revoca o rota inmediatamente cualquier credencial temporal.
  5. Registra el evento. Mantén evidencia de auditoría de que ocurrió una transferencia sin almacenar texto plano. Herramientas como Nurbak proporcionan registros de acceso de auditoría que registran el acceso sin comprometer el contenido.

Qué puede ver cada parte en cada paso

PasoNavegador del remitenteServidor de retransmisiónNavegador del destinatario
Crear enlaceTexto plano antes de la encriptación, luego clave y texto cifradoSolo texto cifrado y metadatosAún nada
Entregar enlaceURL con clave en fragmentoSin clave, sin texto planoURL con clave en fragmento
Abrir enlaceNada nuevoLectura de un solo uso, elimina texto cifradoDescifra texto cifrado localmente, ve texto plano

Esta minimización de datos es el corazón del intercambio de conocimiento cero. No hay nada útil que extraer del servicio de retransmisión porque nunca posee la clave.

Amenazas para planificar, con mitigaciones

Incluso un diseño criptográfico sólido puede fallar si ignoras los riesgos operacionales. Aborda estos problemas comunes.

  • Vistas previas de enlaces y escáneres. Algunos sistemas de chat y correo electrónico obtienen enlaces automáticamente, lo que puede consumir enlaces de un solo uso. Mitiga con un TTL corto, acceso de un solo uso, instrucción al usuario para copiar y pegar el enlace en un navegador, y considera enviar el enlace como texto plano sin despliegue automático cuando sea posible.
  • Phishing y confusión de dominio. Entrena a los destinatarios para verificar el dominio antes de abrir cualquier enlace secreto. Considera una frase precompartida o una llamada para verificación cuando las apuestas son altas.
  • Compromiso del dispositivo. Los enlaces de conocimiento cero protegen los datos en tránsito y en reposo en el retransmisor, pero no protegen un endpoint comprometido. Anima a los destinatarios a abrir enlaces solo en dispositivos gestionados o de confianza.
  • Reutilización de credenciales. Siempre rota o revoca credenciales temporales después de su uso. Trata la transferencia como exitosa solo después de haber eliminado la puerta trasera de persistencia.

Para una guía más amplia sobre el manejo de secretos, considera la Hoja de referencia de gestión de secretos de OWASP.

Por qué los enlaces de conocimiento cero superan al correo electrónico y los tickets para credenciales únicas

MétodoQué puede leer el proveedorRiesgo de persistenciaAdecuación
Correo electrónico o ticketTexto plano disponible en múltiples sistemas y respaldosAlto, las copias existen durante añosNo adecuado para credenciales
Compartir elemento de administrador de contraseñasVaría según el proveedor, algunos están cifrados de extremo a extremoMedio, requiere cuenta y coordinaciónBueno para compartir a largo plazo dentro de una organización
Enlace de conocimiento cero de un solo usoSolo texto cifrado, sin clave, sin texto planoBajo, uso único con TTL cortoIdeal para transferencias ad-hoc entre organizaciones

Si necesitas enviar un secreto rápidamente a un proveedor, freelancer o cliente, los enlaces de conocimiento cero de un solo uso ofrecen la mejor combinación de velocidad, seguridad y auditabilidad.

Consideraciones de cumplimiento en 2026

  • SOC 2 e ISO 27001. Estos marcos esperan el menor privilegio, retención mínima y auditabilidad. Los enlaces de conocimiento cero te ayudan a cumplir estas expectativas al eliminar el texto plano persistente y proporcionar eventos de acceso rastreables.
  • GDPR y Derecho al Olvido. El correo electrónico y el chat propagan copias a través de sistemas y respaldos, lo que complica las solicitudes de eliminación. Los enlaces efímeros y autodestructivos te ayudan a minimizar los datos personales retenidos. Para un análisis más profundo, lee nuestra guía, Cumplimiento del GDPR y el Derecho al Olvido: Por Qué Necesitas Enlaces Autodestructivos.

Cuándo construir vs. comprar

El ejemplo anterior ilustra cómo funciona la criptografía. Convertirlo en un servicio de nivel de producción requiere más trabajo, incluida la seguridad de enlaces contra escáneres, garantías de eliminación de un solo uso, expiraciones confiables, limitación de velocidad, telemetría e informes de cumplimiento. La mayoría de los equipos prefieren no poseer esta superficie.

Nurbak implementa el patrón de conocimiento cero de inmediato, con encriptación AES‑256 del lado del cliente, enlaces autodestructivos, sin registro o almacenamiento de datos, registros de acceso de auditoría y un panel de administración para políticas y análisis. Si solo quieres una forma segura y profesional de entregar secretos, es más rápido y seguro usar una herramienta diseñada para ese propósito que ensamblar la tuya propia.

Primer plano de un desarrollador pegando una contraseña temporal de base de datos en un formulario del navegador, que muestra

Preguntas frecuentes

¿Qué es un enlace de conocimiento cero? Un enlace de un solo uso donde la encriptación ocurre en el navegador y la clave de descifrado está incrustada en el fragmento de URL. El servidor solo almacena texto cifrado y no puede descifrarlo.

¿Por qué poner la clave en el fragmento de URL? El fragmento no se envía al servidor durante las solicitudes HTTP, por lo que el servidor no puede aprender la clave. El navegador del destinatario la usa localmente para descifrar.

¿Es seguro AES‑256 GCM para este caso de uso? Sí, cuando se implementa correctamente con un IV aleatorio único por mensaje y encriptación autenticada. Ver NIST SP 800-38D. Evita esquemas personalizados y usa bibliotecas verificadas.

¿Esto reemplaza a los administradores de contraseñas? No. Usa un administrador de contraseñas para almacenar credenciales a largo plazo. Los enlaces de conocimiento cero son ideales para transferencias ad-hoc entre organizaciones que no deberían persistir en correo electrónico o chat.

¿Cómo evito que las vistas previas de enlaces consuman un enlace de un solo uso? Usa herramientas que admitan expiraciones cortas y acceso de un solo uso, instruye a los destinatarios para copiar el enlace en el navegador y evita canales que obtengan enlaces automáticamente. Separa el enlace del contexto circundante cuando sea posible.

¿Puedo auditar transferencias sin almacenar texto plano? Sí. Puedes registrar metadatos sobre la creación de enlaces y eventos de acceso. Nurbak proporciona registros de acceso de auditoría mientras mantiene el contenido del mensaje con conocimiento cero.


¿Listo para enviar credenciales con conocimiento cero, sin construir tu propia criptografía o protocolos? Crea un enlace cifrado del lado del cliente y autodestructivo en minutos con Nurbak. Aprende cómo funciona la arquitectura en Encriptación del Lado del Cliente vs. del Servidor o obtén un recorrido directo en Cómo compartir un secreto con enlaces de un solo uso. Cuando estés listo, visita Nurbak para generar tu primer enlace de conocimiento cero.