Conviene dejar la conclusión en un solo sitio. AES-256-GCM responde si el campo de la contraseña, en el almacén de disco, está en claro. No responde quién puede desenvolver la clave. El 30 de julio de 2024 Google escribió que DPAPI en Windows frena a otros usuarios del sistema y los ataques de arranque en frío, y que no frena a un programa capaz de ejecutarse como el usuario que ya ha iniciado sesión. Desde Chrome 127, el cifrado vinculado a la aplicación pasó las cookies de «este usuario» a «esta aplicación del navegador». Ninguno de los dos límites significa «ningún programa de este equipo puede leer el secreto».
Qué pregunta hace de verdad esa búsqueda
Quien busca «las contraseñas guardadas de Chrome están cifradas, así que un programa malicioso no las ve» suele preguntar una sola cosa: después de pulsar Guardar, ¿otro programa de este equipo todavía puede recuperar el texto en claro? El nombre del cifrado no cierra esa pregunta. En el blog de seguridad de Google, Will Harris, del equipo de seguridad de Chrome, describió el límite antiguo de Windows con frases llanas. Chrome protege datos sensibles, como cookies y contraseñas, con el mecanismo más fuerte que ofrece el sistema operativo. En Windows ese mecanismo es la API de protección de datos (DPAPI). Protege los datos en reposo frente a otros usuarios del sistema y frente a ataques de arranque en frío. Una aplicación capaz de ejecutar código como el usuario que ya ha iniciado sesión queda fuera de esa protección, y ese es el hueco que usan los programas que leen credenciales guardadas.
Esta nota es para dos lectores. Uno revisa una frase del estilo «el navegador ya cifra las contraseñas guardadas, así que no hay que pensar en las contraseñas que quedan en disco»: suele ser quien desarrolla o quien opera. El otro vio esta semana un texto de seguridad y quiere saber qué demuestra de verdad la palabra «cifrada» en una página de ajustes. Aquí no se explica cómo desenvolver el almacén de contraseñas de otra persona, y esta página no sustituye al generador de contraseñas. Quédate con tres hechos que se pueden separar: qué demuestra el texto cifrado, qué demuestra la protección de la clave, y qué no demuestra el informe del 25 de septiembre de 2026.
AES-256-GCM solo muestra que el campo no está en claro
Los navegadores basados en Chromium guardan los inicios de sesión en el perfil local. En compilaciones más nuevas, el campo de la contraseña va sellado con AES-256-GCM. Si abres ese almacén con un editor de texto, no ves la contraseña del sitio en claro. Esa parte es real. GCM también hace que un byte cambiado falle la comprobación de autenticidad: el texto cifrado no es una cadena en claro que se pueda retocar en silencio y seguir dando por buena.
El navegador tiene que rellenar la contraseña la próxima vez que aparezca el formulario, así que la clave no puede vivir solo en una frase que únicamente tú recuerdes. Cuando la sesión está desbloqueada, el navegador de este equipo tiene que poder usarla. La pregunta útil deja de ser «¿el algoritmo es fuerte?» y pasa a ser «¿quién puede pedirle al sistema esta clave?». Un cifrado fuerte no mueve el límite. Si el derecho a desenvolver queda en «el usuario de Windows que ya ha iniciado sesión», un programa arrancado con ese usuario está del mismo lado que el navegador.
Por eso el mismo nombre de algoritmo es otra frase cuando el cifrado local usa una contraseña que tú escribes. Si cifras un archivo en el navegador con AES-256-GCM y una contraseña que conservas tú, otro programa y una unidad en la nube no tienen esa contraseña por defecto, y no abren el archivo. El almacén de contraseñas del navegador está hecho para el autocompletado. El derecho a usar la clave tiene que quedarse en el navegador de este equipo. Ver AES-256-GCM en los dos sitios no convierte las dos disposiciones de la clave en la misma disposición.
El límite que Google ya dejó escrito
La misma nota del 30 de julio de 2024 separa los sistemas operativos. macOS usa los servicios del Llavero. Linux usa una cartera del sistema, como kwallet o gnome-libsecret. Windows usa DPAPI. La frase sobre «un programa que se ejecuta como el usuario que ha iniciado sesión» es la descripción que Google hace de DPAPI en Windows. No la copies tal cual en cada Mac. El Llavero puede pedir una confirmación del sistema. Esa interacción es otro límite, distinto de «cualquier proceso de este usuario desenvuelve el secreto sin un aviso».
En Windows, DPAPI ata la protección al inicio de sesión de ese usuario. Los casos que Google enuncia son otros usuarios del sistema y los ataques de arranque en frío. Esa es la mitad de «está cifrado» que se sostiene en una revisión de producto. Google enuncia la otra mitad de forma directa: DPAPI no protege frente a una aplicación maliciosa capaz de ejecutar código como el usuario que ya ha iniciado sesión. Ese programa puede pedir al sistema operativo la clave por el mismo tipo de interfaz que usa el navegador. El cifrado no ha fallado. El límite se dibujó alrededor de otros usuarios y del arranque en frío, no alrededor de otros procesos de este usuario.
Cuando una revisión dice «el almacén de contraseñas usa AES-256-GCM, por tanto un programa malicioso local no puede leerlo», parte la frase. La primera mitad se sostiene al abrir el almacén y ver que el campo de la contraseña no está en claro. En la generación DPAPI, la segunda mitad contradice la nota pública de Google. La evidencia que todavía hace falta es si este navegador ha movido esta clase de secreto al límite siguiente. El nombre del algoritmo no es esa evidencia.
Chrome 127 mueve el límite del usuario hacia la aplicación
La misma nota sigue así: Chrome 127 introduce en Windows el cifrado vinculado a la aplicación (App-Bound Encryption). Los datos dejan de estar disponibles para cualquier aplicación que corra como el usuario que ha iniciado sesión. Chrome los cifra atados a la identidad de la aplicación, y un componente del lado del sistema comprueba que quien llama es un navegador de confianza antes de entregar la clave. El orden de migración que escribió Google es explícito. Las cookies se mueven primero, en Chrome 127. Las contraseñas, los datos de pago y otros tokens de autenticación persistentes son secretos que el equipo pensaba ampliar en versiones posteriores. No se describieron como ya migrados el día en que salió la 127.
A principios de 2026, las descripciones forenses públicas siguen trazando esa línea. La nota de ElcomSoft de enero de 2026 dice que el cifrado vinculado a la aplicación empezó por las cookies, con una arquitectura pensada para extenderse a contraseñas y datos de pago, y que Microsoft Edge siguió el mismo camino porque comparte el núcleo de Chromium. En los perfiles donde esa protección nueva está en uso de verdad, un programa de terceros que corre como el usuario falla cuando le pide al sistema operativo la clave a la manera antigua: quien llama no es el ejecutable del navegador ya verificado. Ese límite frena a un proceso ordinario que está fuera del navegador. No frena el interior del proceso del navegador. Una extensión maliciosa, u otro código que ya se ejecuta en ese proceso, sigue del lado de dentro. El cifrado vinculado a la aplicación cambia quién puede llamar. No significa «en cuanto el campo es AES-256-GCM, la lógica de autocompletado en memoria deja de ver la contraseña».
Dos frases se intercambian a menudo, y responden a preguntas distintas. «Mi Chrome es posterior a la 127, así que cada contraseña guardada ya se movió» trata un número de versión como un recibo de migración. En julio de 2024 Google dejó las contraseñas como una ampliación posterior. Un número de compilación 130, 140 o mayor solo muestra que el navegador ya pasó el punto de partida de las cookies. «Alguien todavía lee contraseñas con el acceso antiguo del usuario, así que el cifrado vinculado a la aplicación no hace nada» es el otro exceso. Esa observación muestra que algunos perfiles, o algunas filas, siguen en el límite anterior, o que la muestra describe ese límite anterior. No muestra que el límite nuevo se haya dado públicamente por fallido.
| Lo que puedes ver | Qué sostiene | Qué deja abierto |
|---|---|---|
| El campo de la contraseña es AES-256-GCM | El campo en disco no es la contraseña en claro | Si todo programa local es incapaz de leerla |
| Windows envuelve la clave con DPAPI | Otros usuarios y el arranque en frío quedan fuera de la protección enunciada | Si un programa iniciado como el usuario que ha iniciado sesión queda fuera |
| Cifrado vinculado a la aplicación en Chrome 127, primero las cookies | En datos ya migrados, un programa externo que pide la clave a la manera antigua falla | Si las filas de contraseñas de este equipo ya migraron, y si el código dentro del proceso todavía puede leerlas |
| El gestor de contraseñas lista un sitio | Ese sitio se guardó en algún momento | Qué generación de protección de la clave usa esa fila |
| «Ofrecer guardar contraseñas» está apagado | Los inicios posteriores pueden quedarse fuera del almacén | Si las filas que ya están se han eliminado |
Qué puede demostrar el informe del 25 de septiembre
El 25 de septiembre de 2026, Deepa B en K7 Labs publicó el análisis de un programa de Windows generado con un constructor en Python de tipo «malware como servicio». Ese programa busca carpetas de datos de usuario de 17 navegadores basados en Chromium y lee contraseñas guardadas, registros de tarjetas, historial de navegación y cookies de sesión. También lee el historial y las cookies de Firefox, así que la frase sobre AES-256-GCM en Chromium no describe todos los navegadores del equipo. Para los inicios de sesión de Chromium, K7 dice que los campos de contraseña más nuevos se guardan con AES-256-GCM y que la clave se recupera mediante la protección de datos de nivel de usuario de Windows, con una vuelta al método de protección anterior. El informe no incluye un recuento de equipos afectados ni dice hasta dónde se había distribuido el constructor.
Esa descripción encaja con el límite anterior de la sección previa. El derecho a desenvolver queda en el usuario actual, así que un programa de la misma sesión de Windows puede colocarse dentro de ese límite, y AES-256-GCM solo evita que el campo esté en claro. El informe no está escrito como «esta muestra superó la comprobación de identidad de la aplicación de Chrome», y no aporta un recuento de afectados que se pueda convertir en «tu Chrome ya está afectado». Leer el nombre del cifrado en el titular como «el cifrado ha fallado», o como «entonces mi almacén de contraseñas está a salvo con certeza», da un paso que el informe no da.
El mismo tipo de informe mezcla además dos materiales que es fácil tratar como uno. Una sesión robada permite usar un inicio de sesión que tú ya completaste, mientras esa sesión siga válida. Cambiar la contraseña en el sitio original retira el próximo inicio con contraseña. Por sí solo, no retira las sesiones que ya se habían emitido. Esas caen cuando cierras las otras sesiones en la lista de dispositivos de la cuenta, o cuando el sitio las revoca. Ese trabajo es independiente de lo fuerte que sea el cifrado del almacén de contraseñas. Una comprobación anterior de «cambiar la contraseña no retira una sesión que ya está inscrita» está en la nota de passkeys enlazada más abajo. No son el mismo interruptor.
No desenvolvas tu propio almacén de contraseñas para «ver si la noticia es cierta», y no ensayes con una contraseña real de banca, de correo o de una consola en la nube. La comprobación de abajo solo mira si la página de ajustes lista sitios guardados y si el aviso de guardar sigue activo. Mostrar el texto en claro y exportar el almacén entero quedan fuera de esta comprobación.
Mira la lista guardada, no la base de datos
Un eslogan y un titular no describen el navegador que tienes delante. Basta una cuenta desechable en un sitio de prueba. Los cuatro pasos de abajo se quedan dentro del navegador actual. No hace falta copiar la carpeta del perfil para hacerlos.
- Abre el gestor de contraseñas del propio navegador (Ajustes, en contraseñas o autocompletado, o la página de contraseñas del navegador desde la barra de direcciones). Lee solo la lista de sitios: ¿el correo, la banca, una consola en la nube o un alojamiento de código tienen cada uno una fila? No muestres el texto en claro y no exportes.
- Busca «Ofrecer guardar contraseñas», o el interruptor que cumple el mismo papel. Decide si el próximo inicio de sesión puede almacenarse. Apagarlo no borra las filas que ya están. La eliminación es fila a fila en la lista, o con el control del navegador para borrar las contraseñas guardadas.
- Abre Acerca de y confirma que el navegador sigue recibiendo actualizaciones oficiales. Anota la versión. La versión no demuestra que los campos de contraseña hayan pasado al cifrado vinculado a la aplicación. La página de ajustes no imprime las palabras DPAPI ni «vinculado a la aplicación». No recorras etiquetas de claves en la carpeta del perfil para zanjarlo.
- Si ya sospechas que este equipo ejecuta un programa que tú no instalaste: no pulses «mostrar contraseña» en esta máquina. En un dispositivo en el que todavía confías, cierra las otras sesiones en los sitios importantes y sustituye esas contraseñas. No reutilices una contraseña entre sitios. Este paso limita el daño. No es una invitación a desenvolver el almacén en el equipo sospechoso «para ver si una lectura es posible».
Un número de versión no nombra la generación de la clave
Chrome 127 es la versión en la que el cifrado vinculado a la aplicación empezó a cubrir las cookies. No es la versión en la que cada contraseña guardada cambió de protección ese día. Ver 130, 140 o una versión principal posterior solo muestra que el navegador ya pasó ese punto de partida. Si los campos de contraseña terminaron el traslado quedó, en la nota de julio de 2024, para versiones posteriores, y la interfaz no muestra una generación de protección. Si una hoja de revisión anota la versión, la casilla de al lado debe decir «esto no establece que el almacén de contraseñas esté vinculado a la aplicación», en lugar de una marca de hecho.
El aviso de guardar es el interruptor que crea una fila
Muchas contraseñas entran en el almacén porque el navegador preguntó tras un inicio de sesión correcto y una persona pulsó Guardar, no porque una página de cifrado las subiera. A partir de ahí, esa fila queda detrás del límite descrito arriba. Si generas una contraseña que solo existe en este dispositivo y rechazas el aviso, no se convierte en una fila del gestor. Rechazar el aviso no demuestra que el script de la página nunca envió la contraseña. Esa pregunta pertenece al panel Network. Solo demuestra que no entregaste la cadena a la lista de contraseñas guardadas del navegador.
Cuatro lecturas que estiran «cifrada» demasiado
La primera lectura de más trata AES-256-GCM como «un programa malicioso no puede leer esto». El algoritmo muestra que el campo no está en claro, y muestra que el texto cifrado no se puede alterar sin la clave y seguir verificando. Si esa clave va envuelta con DPAPI para el usuario actual, Google ya escribió que un programa que se ejecuta como ese usuario no está fuera de la protección. El nombre del cifrado y el sitio del límite son dos líneas, y en una revisión tienen que seguir siendo dos líneas.
La segunda lectura de más trata «tengo una contraseña de inicio de Windows» como «el almacén de contraseñas es inmune a programas maliciosos». La contraseña de inicio es lo que impide que otras cuentas, y un ataque de arranque en frío, desenvolvan DPAPI. Un programa que ya está en marcha después de que tú hayas iniciado sesión usa ese entorno de usuario desbloqueado. La contraseña de inicio sigue mereciendo existir. Responde a otro límite.
La tercera lectura de más trata «versión superior a la 127» como «las contraseñas guardadas y las cookies están ambas vinculadas a la aplicación, y el código de dentro del proceso tampoco puede verlas». El punto de partida de Google fueron las cookies. Las contraseñas eran la ampliación. El cifrado vinculado a la aplicación frena, desde fuera del navegador, esa forma antigua de pedir la clave. Una extensión, u otro código que ya corre en el proceso del navegador, no se queda ciego porque ese límite exista.
La cuarta lectura de más trata «cada sitio tiene una contraseña distinta» como «da igual si se lee el almacén entero». Las contraseñas distintas frenan que la filtración de un sitio se reutilice en tu correo y en tu consola en la nube. No frenan a un programa que lee cada fila guardada de una pasada. Los dos controles merecen hacerse. Cubren fallos distintos.
Preguntas frecuentes
Si el gestor de contraseñas dice que está cifrada, ¿otros programas de este equipo pueden leerla?
Cifrada significa que el campo de la contraseña en disco no está en claro. En la generación DPAPI de Windows, Google escribió que la protección cubre a otros usuarios y los ataques de arranque en frío, y que no cubre a un programa que se ejecuta como el usuario que ha iniciado sesión. El cifrado vinculado a la aplicación desde Chrome 127 empieza por las cookies: un programa externo que pide la clave a la manera antigua falla en los datos que ya migraron, y el interior del proceso del navegador sigue pudiendo leer. La palabra «cifrada» en pantalla no te dice en qué generación están los campos de contraseña de este equipo.
¿El cifrado vinculado a la aplicación de Chrome 127 impide que un programa malicioso descifre las contraseñas guardadas?
Esa equivalencia no está en la nota. El 30 de julio de 2024, Google dejó las contraseñas y los datos de pago como elementos previstos para versiones posteriores. El cifrado vinculado a la aplicación estrecha el derecho a desenvolver: pasa de «el usuario actual» a «un navegador que el componente del sistema acepta». Por eso un programa externo que solo usa el acceso antiguo del usuario falla en datos que ya se movieron. No coloca el código interno del proceso fuera del límite, y no muestra que cada contraseña guardada de tu navegador haya completado el traslado.
¿El informe del 25 de septiembre demuestra que cualquier programa ya puede leer mis contraseñas de Chrome?
Ese intercambio es demasiado grande. El informe describe un programa de Windows que lee contraseñas guardadas, tarjetas, historial y sesiones de 17 navegadores basados en Chromium, además del historial y las cookies de Firefox, y dice que los campos de contraseña usan AES-256-GCM y que la clave se desenvuelve con la protección de datos de nivel de usuario. K7 no publica un recuento de equipos afectados, y no presenta la muestra como si hubiera superado la comprobación de identidad de la aplicación. En qué generación está tu navegador depende de la lista guardada y de si las actualizaciones siguen llegando, no del nombre del cifrado en un titular.
Después de cambiar la contraseña de un sitio, ¿las sesiones ya guardadas dejan de valer?
No siempre. Un cambio de contraseña retira el próximo inicio de sesión que use esa cadena. Las sesiones ya emitidas suelen permanecer hasta que cierras las otras sesiones en la lista de dispositivos de la cuenta, o hasta que el sitio las revoca. El mismo tipo de programa se lleva sesiones y contraseñas guardadas a la vez. Cambiar una contraseña y dejar las otras sesiones abiertas trata la contraseña, no la sesión.
¿FastPwd escribe la contraseña generada en la lista de contraseñas guardadas del navegador?
No escribe esa lista, y el sitio no tiene un almacén de contraseñas propio. Una fila aparece solo si aceptas el aviso de guardar del navegador. El modo aleatorio usa crypto.getRandomValues, admite de 6 a 128 caracteres y usa 16 por defecto. El resultado no se sube. Listo para usar, sin cuenta. Si un programa de este equipo ya puede leer la pestaña actual o el portapapeles, ve el texto en claro de la página. El límite de subida no sustituye ese límite.
Comprueba «no guardada» en un generador que puedes abrir ahora
Si quieres que la diferencia entre «apareció una contraseña» y «una contraseña entró en el almacén del navegador» se vea, abre el generador de contraseñas de FastPwd. Sin registro. En el modo aleatorio, deja el valor por defecto de 16 caracteres y genera una cadena desechable. Si el navegador ofrece guardarla, rechaza. Vuelve al gestor de contraseñas: el sitio de prueba no debería haber ganado una fila nueva. FastPwd no guarda un almacén de contraseñas, y no escribe por ti la lista de contraseñas guardadas del navegador.
La generación usa crypto.getRandomValues. La longitud va de 6 a 128 caracteres, con 16 por defecto. Por debajo de 8 se marca como menos segura. El resultado no se sube. Abre las herramientas para desarrolladores, elige Network, activa conservar el registro y busca la cadena completa en las líneas y los cuerpos de petición. No debería aparecer en una petición de la aplicación. Esa búsqueda muestra que esta ejecución no salió de la pestaña como cuerpo HTTP. No muestra que un programa local sea incapaz de leer la página o el portapapeles. Si este equipo ya no es de confianza, genera e inicia sesión en otro dispositivo.
Si además quieres ver si una cadena se parece a una contraseña débil pública de alta frecuencia, lleva otra cadena desechable a Comprobar contraseña. La contraseña que compruebas no se sube. Una falta de coincidencia no demuestra que la cadena no haya aparecido nunca en la web. Una coincidencia solo significa que es demasiado común. No pegues la contraseña real que estás a punto de empezar a usar, y no exportes el almacén del navegador para comprobar esa exportación.
Si esa cadena tiene que llegar a otra persona una sola vez, déjala fuera del cuerpo de un ticket que acabará en registros del servidor. Usa Burn-Link: el servidor solo guarda texto cifrado, la clave va detrás de # en el enlace, y crear y leer no piden cuenta. Ese canal responde a «cómo entrego esto una vez». No vuelve segura una contraseña antigua que ya está guardada en el navegador. Borra esa fila anterior en el gestor de contraseñas y sustitúyela desde un dispositivo en el que confíes.
Para seguir leyendo
Para comprobar una afirmación de «local, no se sube», busca un canario en Network, en Cómo comprobar que el cifrado local del navegador no envió el original. Un cambio de contraseña no retira una sesión que ya se emitió: mira Te llaman para actualizar la passkey. Por qué ese señuelo roba la sesión, no la Passkey. Una lista local de contraseñas débiles puede atrapar contraseñas débiles habituales y no es un cruce de toda la web: mira Qué puede demostrar una lista local de contraseñas débiles, y por qué no es un cruce de toda la web.