Abre un «generador de contraseñas online», pulsa generar y luego el panel Red de las herramientas de desarrollo. Si el cuerpo de la petición o los parámetros de consulta contienen la contraseña que acabas de crear, el texto en claro ya ha salido de tu dispositivo. No hace falta creer la promesa de ninguna marca: el propio navegador enseña el tráfico.
Dejar el cálculo en el navegador no es un eslogan de «descentralización». Es reducir la ventana de texto en claro a tu máquina: una capa menos de transmisión, un registro de servidor menos, una oportunidad menos de que alguien lea un volcado de memoria. A continuación, amenaza, pasos comprobables y límites. La pila de PassAfer está diseñada con este criterio; este artículo no es un recorrido de producto, responde a una sola pregunta: por qué el cálculo sensible no debería ir al servidor por defecto.
Qué ventana agranda el cálculo en el servidor
La ventana de texto en claro es el conjunto de momentos en los que el texto (o una clave que lo restaura) existe de verdad. Si el servidor hace el trabajo, esa ventana no es solo el instante en que pulsas enviar, sino una cadena difícil de borrar después:
- La sesión TLS entre el navegador y el origen: el proceso del servidor ve la petición ya descifrada, no el texto cifrado.
- Muestreo de cuerpos en el proxy inverso, el WAF, el APM o el rastreador de errores; un 500 puede meter el formulario en un informe de caída.
- Registros de aplicación, consultas lentas y access log con query string. Quien pone una clave en
?key=la está escribiendo en el access log. - Ficheros intermedios en base de datos, almacenamiento de objetos o disco temporal, más copias de seguridad y réplicas.
- El tiempo en que operaciones, soporte o un atacante consiguen cualquiera de esas copias. La ventana ya ocurrió; «lo borramos al terminar» no la deshace.
La jurisdicción y los subcontratistas convierten «no miramos» en una frase difícil de auditar. Lo que sí puedes comprobar es el protocolo y el tráfico, no el reglamento interno del centro de datos ajeno.
En la generación de contraseñas duele especialmente: quieres un secreto que aún no existe en ningún sistema. Si se genera en la sala de máquinas de otro, la primera copia no está en tu mano. Luego la pegas en configuración de producción, variables de CI o un gestor de contraseñas, y ya hay un nodo de fuga que no ves.
En la comprobación de fortaleza igual: enviar una contraseña habitual a un servicio remoto «para ver si es segura» es entregar el secreto más sensible de reutilización. Consultar listas públicas de filtraciones puede hacerse con protocolos tipo k-anonymity; PassAfer elige una restricción más dura: la contraseña a comprobar no se sube; la estimación de fortaleza y la comparación con listas Top de contraseñas débiles ocurren en el navegador. Lo que verificas no es «dicen que no lo guardan», sino que la petición no lleva esa cadena.
En el cifrado de archivos, el flujo «subir → cifrar en el servidor → volver a descargar» hace que la frase de paso y el contenido existan completos al menos en la memoria del servidor. El cifrado local en flujo deja al servidor sin texto en claro que recoger: ni siquiera necesita saber si cifras una foto o una imagen de disco.
HTTPS no es cálculo local
TLS protege frente a quien escucha en el camino, no frente al servidor de destino. Si ese servidor hace el cálculo, tiene que leer el texto en claro. El cálculo local responde a otra pregunta: el destino no debería ver ese material.
Qué significa «local» de verdad
«Local» se usa como eslogan. Hay que despiezarlo; si no, «solo tú puedes verlo» en un disco en la nube también se vende como cifrado local.
Proceso en tu máquina, no «en una cuenta en la nube»
En PassAfer, local significa que el cálculo ocurre en la pestaña del navegador: el azar sale de crypto.getRandomValues y el cifrado simétrico de la Web Crypto API. El material de clave vive en objetos CryptoKey de vida corta y, por defecto, no se envía como campo de analítica. El resultado se copia, se exporta o se descarga al disco; al cerrar la página, el texto en claro en memoria se recicla con el ciclo de vida del navegador, no queda otra copia en remoto.
Eso no es lo mismo que «dejar el archivo en un disco en la nube solo visible para ti». Ese servicio suele poder leer el objeto en claro, salvo que lo hayas cerrado antes en tu máquina y subas solo el texto cifrado. Lo local pregunta: ¿ha existido el texto en claro, en forma usable, fuera de tu dispositivo?
Algoritmo y límite de archivo son hechos comprobables
En la primera versión el único algoritmo simétrico es AES-256-GCM (cifrado autenticado: si se altera el texto cifrado, el descifrado falla). El cifrado de archivos trata un archivo en flujo, con un tope de 5 GB, y genera .lock (preferido) o .enc, para no cargar un vídeo entero en memoria. Esos números están en el producto, no son adjetivos de marketing; si en la página aparece un conmutador de algoritmo no implementado, prima la ficha del producto, no lo que uno imagine.
Local no es «todo el mundo puede usar todas las herramientas»
Dónde se calcula y qué exige iniciar sesión son cosas distintas. Un visitante sin cuenta puede generar caracteres aleatorios y frases memorables, copiarlas y exportarlas; la comprobación de fortaleza, quitar rastreadores, crear un mensaje autodestructivo, cifrar un archivo y la bóveda se desbloquean al iniciar sesión. Entender «local» como «cualquiera usa todo» choca con la matriz de permisos.
| Capacidad | Sin iniciar sesión | ¿Se sube el material sensible por defecto? |
|---|---|---|
| Generación aleatoria / frase memorable | Disponible | No se sube; se genera en el navegador |
| Añadir a la bóveda | Guía de inicio de sesión | — |
| Comprobar si tu contraseña es segura | Guía de inicio de sesión | La contraseña a comprobar no se sube; fortaleza + lista de débiles en local |
| Limpiar URL / enmascarado | Guía de inicio de sesión | URL y texto en local; no se escriben en analytics |
| Crear mensaje autodestructivo | Guía de inicio de sesión | Se sube el blob cifrado, no el original |
| Leer mensaje autodestructivo | Público para el destinatario | La clave está en el fragmento # de la URL; no viaja en el HTTP al servidor |
| Cifrar un archivo | Guía de inicio de sesión | Archivo y frase de paso no se suben; AES-256-GCM en flujo en local |
El mensaje autodestructivo es el único camino que necesita almacenamiento temporal en el servidor, pero lo que se guarda es texto cifrado. La clave de descifrado va en el tramo # de la URL: el fragmento no se envía con la petición HTTP y el access log suele llevar solo la ruta. La página de lectura es pública para el destinatario; si tuviera que registrarse, el envío de un solo uso no funcionaría. Tras la primera lectura, el texto cifrado se destruye por diseño. Conocimiento cero en el servidor no significa «no se guarda nada», sino «aunque se guarde, no se puede abrir». Aquí basta esta convención.
Comprobar en el panel Red si sale material sensible
Un eslogan no se demuestra solo. Esto es un procedimiento que no depende de la confianza, con las herramientas de desarrollo del navegador. El objetivo no es probar que no hay ningún canal lateral en el mundo, sino destapar las herramientas online que hacen POST del texto en claro al primer clic.
Empieza por el generador, sin iniciar sesión. Abre la página de contraseñas y permanece fuera de sesión. Los caracteres aleatorios y la frase memorable deberían generarse al momento. Así separas el sistema de cuentas de «¿la generación sale?», y no confundes una petición de inicio de sesión con una subida de la contraseña.
Abre Red (Network) y marca Preserve log. Vale Chrome, Edge o Firefox. Filtra primero Fetch/XHR y luego revisa todas las peticiones. Preserve log evita que un salto de página borre el registro. Fíjate también en sendBeacon y en las peticiones de un Service Worker.
Genera una contraseña fácil de reconocer. Alarga un poco la longitud, cópiala a un bloc de notas. En el buscador del panel Red pega esa cadena, o un trozo que no aparezca por casualidad en el código JavaScript.
Mira URL, Query y Request Payload. Si ninguna petición contiene ese trozo, al menos en el clic de «generar» el texto en claro no ha salido como contenido HTTP. Una cadena irrelevante en un script estático no cuenta; buscas la que acabas de generar.
Las herramientas con sesión, el mismo método. La comprobación de fortaleza, quitar rastreadores y cifrar un archivo requieren iniciar sesión. Después usa una contraseña de prueba o un archivo pequeño y vuelve a buscar. El comprobador no debería enviar la contraseña a comprobar; la limpieza no debería hacer POST del original; el cifrado de archivos no debería subir el texto en claro como multipart.
En un mensaje autodestructivo mira el texto cifrado y el fragmento. Al crear (hace falta iniciar sesión) lo que va al servidor debe ser texto cifrado, no lo que escribiste. En el enlace completo la clave va después de #; quita el fragmento y mira el panel Red: la ruta de la petición no debería llevar la clave. El destinatario abre la página de lectura sin iniciar sesión.
Qué demuestra este paso y qué no
El panel Red demuestra si esta operación ha metido texto en claro en HTTP. No ve un script del mismo origen leyendo memoria, una extensión maliciosa o una página ya inyectada con XSS. Basta para destapar muchas «herramientas online»; no lo tomes por una prueba formal.
Qué debe quedarse en local y qué excepciones hay que decir
Debe quedarse en tu máquina lo que, una vez fuera, no se puede retirar: una contraseña recién generada, una antigua a comprobar, el original a enmascarar, el archivo en claro, la clave simétrica. Si eso entra en el registro de otro, borrar la página no borra su copia.
Puede salir del dispositivo lo que, en términos criptográficos, no sirve al servidor, o lo que pertenece al sistema de cuentas. Por ejemplo el blob cifrado de un mensaje autodestructivo, el nombre de usuario y la contraseña de inicio de sesión, y los recursos estáticos sin secretos. No mezcles «iniciar sesión» con «subir el texto en claro de la herramienta»: iniciar sesión es un escalón de permisos —sin cuenta ya puedes generar contraseñas, para bajar la barrera; comprobar fortaleza, limpiar URL, crear un mensaje de un solo uso, cifrar un archivo y la bóveda se desbloquean después. Las credenciales van por el sistema de cuentas; eso no es lo mismo que «¿se sube la contraseña recién generada?».
La salida del cifrado de archivos es el .lock / .enc que descargas al disco. Luego, por disco en la nube, USB o correo, viaja el archivo cifrado. Si subes ese texto cifrado a un disco en la nube, ese servicio sigue sin ver la frase de paso ni el original, siempre que la frase no vaya en claro en el mismo envío o en el mismo correo. El cifrado local cambia «el administrador del disco puede abrir tus fotos por defecto»; no quita la responsabilidad física de custodiar el archivo.
Quitar rastreadores y enmascarar datos también deja URL y texto en el navegador: quita UTM y parámetros publicitarios, enmascara teléfonos y documentos, y te da el resultado para que lo revises antes de enviarlo. El original no se sube ni se manda como contenido de un evento de analytics. Si el proceso hiciera POST de todo el ticket al servidor y devolviera «ya enmascarado», la ventana de texto en claro ya se habría abierto en el servidor y el enmascarado sería solo de presentación.
Límites y malentendidos del cifrado local en el navegador
Priorizar lo local reduce la exposición en el servidor y en el camino, no en un ordenador controlado por un troyano. Meter el límite en las expectativas sirve más que imprimir AES en el pie de página.
Si la página está inyectada, el algoritmo no ayuda
XSS o un script secuestrado pueden leer el campo de entrada. Web Crypto protege «operaciones de clave en una página honesta», no «un script malicioso ya está en el mismo origen». Lo que cuenta es same-origin, la política de contenido y la integridad de la cadena de suministro del front. Ver «AES-256-GCM» no implica «XSS no sirve».
Extensiones, proxy de empresa, mirar por encima del hombro
Una extensión del navegador o un proxy de empresa que descifra SSL pueden seguir viendo la página. Con un certificado raíz inyectado por la empresa, Network muestra el mundo después del proxy. Pérdida del dispositivo, compartir pantalla, mirar por encima del hombro: el cálculo local no los cubre. Son problemas de extremo; sepáralos de «el servidor no debería tener el texto en claro».
«No se sube» no es «no hay red»
La página, los scripts y las peticiones de inicio de sesión siguen saliendo. Lo que compruebas es si los campos sensibles aparecen en esas peticiones, no si has desenchufado el cable. PassAfer tampoco reporta como evento de análisis la contraseña a comprobar, el original a limpiar ni el contenido del archivo: el evento no debe llevar el secreto.
No escribas capacidades que no existen
El algoritmo de la primera versión es AES-256-GCM; no esperes un conmutador a RSA o a algoritmos no entregados. No presentes la página de lectura del mensaje autodestructivo como si exigiera iniciar sesión. No afirmes que el servidor también ve el texto en claro o la clave: eso contradice el producto. La forma honesta de «local primero» es: el cálculo sensible se hace en el navegador; texto en claro, claves y archivos no se suben por defecto; en un mensaje autodestructivo el servidor solo guarda texto cifrado un tiempo.
Por dónde empezar si quieres comprobarlo tú
Si solo quieres confirmar que «este clic de generar no ha salido», lo más sencillo es el generador de contraseñas: no hace falta iniciar sesión, caracteres aleatorios y frases memorables se hacen en local, igual que copiar y exportar. Abre el panel Red y busca la cadena que acabas de generar. Es el coste más bajo y el que más rápido crea la intuición de «ventana de texto en claro».
Las alternativas habituales tienen límites concretos. Correo en claro y mensajería instantánea dejan la clave en el historial de ambos, en archivos del servidor y en copias de los dispositivos; un disco en la nube es legible para el servicio salvo que cifres antes en tu máquina; poner la clave en un parámetro de consulta casi siempre entra en el access log. No es que «falte comodidad»: la ventana de texto en claro está diseñada dentro.
Si quieres una copia de un archivo que no debería ir tal cual a un disco en la nube, inicia sesión y cifra un archivo: AES-256-GCM en flujo en el navegador, un archivo de hasta 5 GB, descarga .lock o .enc. Captura el tráfico del cifrado y confirma que el original no se ha enviado por POST. Si necesitas enviar un secreto corto a un compañero una sola vez y no quieres que la clave aparezca en los registros del servidor, usa un mensaje autodestructivo: cifrado local, clave en el tramo #, el servidor solo toca texto cifrado, el destinatario no se registra. Este solo pide que sepas responder: después de este clic, ¿el texto en claro sigue en tu pestaña?
El lema de PassAfer es «cifrado local, seguro donde vayas». La condición de que te acompañe es que el cálculo ocurra en la pestaña que estás mirando, y que puedas comprobarlo con el panel que ya trae el navegador.