Seguridad
Demuestre que su navegador no es una bóveda.
Chrome y Firefox guardarán sus contraseñas — y luego se las entregarán a cualquier programa que se ejecute como usted. Eso no es un error. Es el diseño. Aquí está la prueba: una vez en lenguaje claro, una vez en código.
La versión en lenguaje claro
El "gestor de contraseñas" de su navegador está protegido por un solo candado: el inicio de sesión de su ordenador. Una vez que haya iniciado sesión en su portátil, el navegador puede leer todas las contraseñas guardadas al instante — por lo que cualquier otra cosa que se ejecute en su cuenta también puede hacerlo.
Una descarga maliciosa. Un juego de navegador sospechoso. Un paquete envenenado en un proyecto que clonó. En el momento en que se ejecuta — mientras usted ha iniciado sesión, como siempre lo hace — lee todas las contraseñas que su navegador guardó, en el tiempo que se tarda en abrir un archivo. No hay una contraseña maestra que descifrar, porque no hay nada que descifrar: el navegador fue diseñado para desbloquearse automáticamente para usted, y el malware simplemente lo solicita amablemente como "usted".
Esto no es teórico. Es la forma más común en que las personas comunes pierden sus cuentas. El malware incluso tiene un nombre aburrido en la industria — "ladrones de información" — porque es así de rutinario. Sus contraseñas, sus tarjetas guardadas, sus cookies de sesión: copiadas y perdidas antes de que se dé cuenta.
La solución es simple de enunciar: sus contraseñas deben estar bloqueadas con algo que el resto de su ordenador no tiene — y no deben residir en la máquina en absoluto.
La versión con pruebas
No se fíe solo de nuestra palabra. Chromium y Firefox son de código abierto, y la ruta de lectura está documentada, es estándar y es corta. Aquí se indica exactamente dónde están las contraseñas y cómo se obtienen.
Chrome (y todos los navegadores Chromium)
Chrome almacena los inicios de sesión en una base de datos SQLite — Login Data, tabla logins, columna password_value — cifrada con AES-256-GCM. La clave AES reside en Local State, "protegida" por el sistema operativo: DPAPI en Windows, el Keychain de inicio de sesión en macOS, gnome-keyring/kwallet (o texto plano) en Linux.
Léalo usted mismo — el código está abierto. Busque en Chromium la constante que etiqueta la clave envuelta: kDPAPIKeyPrefix en os_crypt. La clave está envuelta con DPAPI, etiquetada y almacenada — luego se desempaqueta con una sola llamada que no protege nada de usted:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Sin segundo secreto, sin contraseña, sin aviso. CryptUnprotectData devuelve la clave a cualquier proceso que se ejecute en su sesión — que es exactamente el modelo de amenaza que DPAPI documenta: si se ejecuta como usted, es usted. El trabajo completo del atacante son tres líneas: leer la clave de Local State, desempaquetarla, descifrar AES-GCM cada fila en Login Data. El malware ladrón de información ha hecho exactamente esto durante años.
El "cifrado en el dispositivo" tampoco le salva
La respuesta de Google es un PIN de 6 dígitos que cifra su bóveda sincronizada. En mayo de 2026, investigadores de Phishu demostraron lo frágil que es. Un inicio de sesión de Google falso y convincente — phishing de adversario en el medio — captura la sesión y ese PIN, y el PIN es la clave maestra de cada contraseña y passkey en la cuenta sincronizada. Con él, un atacante une su propio dispositivo a su "dominio de seguridad" de Google y toda la bóveda se sincroniza directamente con ellos — toma de control completa en un solo paso.
El fallo de diseño: Google permite que un dispositivo se una solo con el PIN de 6 dígitos, sin aprobación de un dispositivo que usted ya posea.
Firefox
Firefox guarda los inicios de sesión en logins.json y la clave en key4.db, descifrada por el "Anillo Secreto de Decodificación" de NSS — también de código abierto: security/nss/lib/pk11wrap/pk11sdr.c. Si usted establece una Contraseña Primaria, la clave se sella con ella.
Por defecto, usted no lo ha hecho — por lo que la clave se sella con la cadena vacía, y un valor almacenado de "comprobación de contraseña" confirma que la contraseña vacía la descifra. Copie dos archivos de su perfil (key4.db + logins.json), apúntelos a NSS o al código abierto firepwd.py, y se descifran. Una cerradura cuya llave está pegada a la puerta no es una cerradura.
Todas las tiendas de contraseñas de navegadores tienen la misma estructura: el secreto reside donde usted trabaja, desbloqueado por la sesión en la que ya se encuentra. El cifrado que el resto de su propio ordenador puede deshacer no le protege de la amenaza que realmente vacía las cuentas — código que se ejecuta como usted.
Por qué Clavitor no se puede leer de esta manera
Clavitor no guarda su bóveda en la máquina. No hay Login Data, ni key4.db, ni clave en Local State — nada en el disco para que un proceso que se ejecute como usted pueda extraer.
La clave de descifrado no está sellada con su inicio de sesión del sistema operativo. Se deriva de un toque de hardware — Touch ID, Face, o una YubiKey — calculado en el navegador, utilizado para una sola solicitud, y luego descartado. Una credencial se obtiene a través de una API con alcance limitado exactamente cuando usted la solicita, y nunca se almacena en caché. El malware que se ejecuta como usted encuentra un armario vacío.
Esa es la diferencia entre "cifrado en su dispositivo" y "no en su dispositivo en absoluto".
Deje de confiarle sus contraseñas al navegador.
La extensión Clavitor rellena como su navegador — y mantiene la bóveda en un lugar que su portátil no puede leer.