Límites de seguridad

memories 0.1 es software en desarrollo. No considere que una batería de pruebas superada constituye una auditoría de seguridad independiente ni una certificación de seguridad para producción.

Protección frente a

Que un relay de sincronización de bóvedas lea o falsifique el contenido de los activos, sustituya la identidad de un par después de una verificación deliberada de su huella digital o modifique texto cifrado autenticado.
Que se lea una copia de la base de datos local sin la contraseña local o, cuando se haya habilitado deliberadamente, sin la clave de envoltura independiente para el acceso desatendido. El factor local móvil depende además del almacenamiento seguro de la plataforma.
Que un lector falsifique escrituras, un administrador cambie la propiedad o un dispositivo revocado utilice su clave de identidad de usuario para emitirse un nuevo dispositivo autorizado.
Que la CLI/MCP ordinaria imprima accidentalmente una credencial almacenada, acepte una contraseña en la línea de comandos o permita que una capacidad MCP herede la elevación del terminal. Las lecturas deliberadas de credenciales sin supervisión entregan intencionadamente bytes en texto plano.
La modificación no detectada de revisiones firmadas o entradas de auditoría, los huecos en la cadena y el truncamiento de puntos de control respecto al estado actual restante de la base de datos.

Limitaciones deliberadas

Las cuentas alojadas de autoservicio utilizan hashes de contraseña Argon2id con sal y bóvedas independientes; el operador sigue controlando el almacenamiento alojado y puede descifrarlo. El registro por correo electrónico exige un código de verificación del buzón de un solo uso y con caducidad antes de establecer una contraseña. El modo de nombre de usuario no tiene una dirección de contacto verificada. SMTP exige TLS con verificación de certificados; las credenciales permanecen en la configuración protegida del servicio. Las autorizaciones de inicio de sesión caducan después de una hora; la revocación al cerrar sesión en el navegador se realiza en la medida de lo posible cuando no hay conexión. Los límites de autenticación son locales al proceso, acotados y poco precisos: limitan el abuso de CPU/correo, pero no constituyen un servicio distribuido de prevención de abusos. Consulte docs/center.md para conocer las limitaciones de configuración y recuperación.
Memories Web es un cliente de un Center alojado, no una bóveda cifrada local al navegador. Mantiene los tokens de portador y el contenido recibido en la memoria de la página, los borra al desconectarse, pasar a segundo plano, salir de la página o tras cinco minutos de inactividad, y no los persiste en el almacenamiento del navegador. No se garantiza el borrado de la memoria JavaScript; las extensiones y herramientas de depuración pueden inspeccionarla, y los archivos descargados permanecen en disco. Los tokens están vinculados al origen HTTPS elegido (HTTP de loopback para desarrollo); las redirecciones y cookies están deshabilitadas. Un origen web permitido puede acceder a las API de contenido alojado con un token de portador autorizado, pero no a las rutas de administración o gestión de tickets. CORS no sustituye la autorización del servidor. Se confía el token al alojamiento web que suministra los scripts; utilice el /app/ del mismo origen incluido en Center cuando ese sea el límite de confianza deseado. Consulte la guía del cliente web.
El modo alojado opcional de Center (memories-center --data) es una bóveda cifrada independiente en el servidor, no almacenamiento de dispositivos cifrado de extremo a extremo. La MEMORIES_CENTER_VAULT_PASSWORD en poder del operador abre el Store con formato de daemon; los operadores del host y cualquier persona con la contraseña y el disco pueden leer todo el texto plano alojado. El RPC de autorizaciones alojadas es una superficie cerrada de contenido de bóveda con elevación local a cada operación, incluidas escrituras privadas/de archivos/protegidas y entrega deliberada de credenciales. El MCP del daemon sigue sin elevación y sin cambios. El token de portador de administrador por sí solo no puede usar las API de bóveda, pero los administradores pueden emitir autorizaciones independientes con ámbitos específicos o miembros duraderos. El bloqueo administrativo alojado descarta las claves del Store; desbloquear exige la contraseña del operador mediante HTTPS de confianza. Los tokens de miembros duraderos en members.json, accesible solo por el propietario, son credenciales en texto plano, no claves de bóveda: proteja sus archivos, copias de seguridad y respuestas de una sola entrega. Un ticket de desbloqueo emitido por Center no custodia la contraseña del dispositivo ni eleva los privilegios del dispositivo/MCP. Los clientes del daemon configurados para SaaS comparten el token de portador alojado inyectado; las capacidades MCP locales no pueden heredarlo. La migración de notas antiguas conserva un memories.json.bak en texto plano; protéjalo o elimínelo después de verificarlo. Consulte docs/center.md para conocer el modelo de amenazas completo y las diferencias intencionadas.
Los dispositivos comprometidos, los administradores del sistema operativo, los programas autorizados maliciosos, la inspección de memoria, los registradores de teclas y los usuarios que copian deliberadamente texto plano quedan fuera del límite de confidencialidad. Los búferes de claves de Rust se ponen a cero cuando se posee su memoria; no se garantiza el borrado del intercambio del sistema operativo, los volcados de fallos, las asignaciones de dependencias ni las cadenas de Dart gestionadas por el recolector de basura. La custodia desatendida de escritorio dispone de backends Windows DPAPI, macOS Keychain, Linux Secret Service y owner-file. Estos proporcionan protección mediante la cuenta del sistema operativo, no una garantía de custodia respaldada por hardware; owner-file almacena su clave de envoltura en texto plano accesible solo por el propietario. Ningún backend distribuido garantiza custodia de escritorio respaldada por hardware.
El relay puede observar metadatos del tráfico, bloquear conexiones, conservar su propia grabación del texto cifrado, retrasar revocaciones o dividir la flota en particiones. El servidor distribuido no escribe activos, pero no se puede obligar a un servidor malicioso a no grabar el tráfico. La sincronización entre pares de bóvedas (/v1/channel) está cifrada de extremo a extremo. El RPC remoto del daemon mediante relay (/v1/rpc/{room}/{slot}), en cambio, transporta JSON autenticado: el relay o el terminador TLS pueden leer el token de escucha compartido y los contenidos de las solicitudes/respuestas.
La revocación sin conexión no puede borrar texto plano anterior, claves ni copias de seguridad. Un dispositivo que no haya recibido una revocación puede seguir utilizando su copia local antigua. Se bloquea la exportación a un dispositivo cuya revocación se conoce y las nuevas épocas utilizan claves nuevas. La revocación también descarta las exportaciones a la nube en cola e invalida el trabajo capturado antes de la siguiente operación de objeto. No se puede retirar una solicitud de red que ya haya comenzado.
La auditoría demuestra el contenido firmado y la continuidad respecto a un estado conocido, no que un dispositivo comprometido haya registrado todos los accesos. No se puede detectar la sustitución de toda la base de datos y todas las pruebas locales por una copia de seguridad anterior coherente sin un punto de control más reciente de un par o un anclaje externo. No existe un servicio de marcas de tiempo de confianza.
Las operaciones fallidas se auditan cuando hay una identidad local de firma autorizada y utilizable desbloqueada. Los intentos mientras todo está bloqueado están sujetos a límites de frecuencia, pero no crean un registro de auditoría firmado persistente. Los fallos abruptos dejan intenciones de entrega/ejecución previamente confirmadas en lugar de inventar resultados.
Un proceso del mismo usuario está dentro del límite de la cuenta local del sistema operativo. IPC autentica al usuario del sistema operativo; la elevación del terminal utiliza además el PID del padre. Esto no aísla frente a un proceso malicioso ejecutado como ese mismo usuario, ni constituye una identidad de sesión duradera inmune a la reutilización de PID. IPC acepta hasta 16 clientes simultáneos. El enmarcado de las canalizaciones con nombre de Windows sigue siendo bloqueante: los clientes del mismo usuario detenidos pueden ocupar esos puestos, pero un cliente detenido o una transferencia a la nube no bloquea todas las demás conexiones. La E/S de tramas en Unix tiene plazos acotados. Las operaciones de servicio que mantienen el bloqueo de escritura, incluida la ejecución de hijos de confianza, siguen serializándose. Los vínculos de ejecución son la excepción: el servicio autoriza, descifra y audita bajo el bloqueo, y luego lo libera mientras se ejecuta el programa vinculado.
Los vínculos de ejecución (credential bind) amplían deliberadamente, con autorización sudo, el límite de elevación para un programa. Mientras un vínculo no haya caducado (8 horas por defecto, 720 como máximo) y el almacenamiento esté desbloqueado, cualquier llamador cli: del mismo usuario puede ejecutar ese programa con su credencial vinculada sin elevación. Esos llamadores reciben la salida del programa con las apariciones exactas de la credencial sustituidas, no la credencial, pero el programa, sus plugins/extensiones y sus descendientes reciben el texto plano y pueden divulgarlo (salida codificada, red, archivos). Los vínculos son estado cifrado local al dispositivo, nunca se sincronizan, se borran al restaurar una copia de seguridad y se rechazan para llamadores MCP, remotos (ws:/relay:), desatendidos y móviles. El servicio aplica las reglas de denegación a los argumentos que el programa recibe realmente; las reglas de consulta solo las aplica el hook de Claude Code, que es un enrutador de conveniencia, no un límite: un comando que no detecta se ejecuta sin la credencial, y un proceso del mismo usuario puede llamar directamente a run --binding (el hook también comprueba las llamadas directas que puede ver). Incluya en una regla de denegación cualquier cosa que nunca deba ejecutarse sin supervisión.
La escucha HTTP/WebSocket opcional y el RPC mediante relay exponen el mismo protocolo enmarcado service::Request después de presentar un secreto compartido (JSON binario de WebSocket: AuthFrame seguido de Wire). El token de escucha se suministra únicamente mediante --listen-token / MEMORIES_LISTEN_TOKEN (o se genera e imprime una vez); nunca se almacena en TOML. La comparación se realiza en tiempo constante. El token se borra cuando se bloquea el almacenamiento. Los llamadores remotos utilizan espacios de nombres de elevación estables ws:remote / relay:remote y no pueden heredar la elevación cli:{pid} de un terminal local; desbloquear/sudo a través de ese transporte eleva el espacio de nombres remoto para las conexiones posteriores de una sola operación. Los hosts HTTP/relay de escritorio exponen el conjunto ordinario de operaciones IPC locales después de desbloquear/sudo (incluidos Run, CryptoJob, autorizaciones MCP, sesiones remotas, proxies, copia de credenciales y copias de seguridad), sujeto a las mismas comprobaciones de elevación. Por tanto, los poseedores del token tienen tanto poder como un cliente local elevado en ese host: proteja el token en consecuencia. FFI móvil y Share mantienen la lista de denegación móvil (sin Run/CryptoJob/autorización MCP/remoto/proxy en el teléfono; Share también rechaza la copia de credenciales en texto plano y los volcados de copias de seguridad). La escucha HTTP utiliza loopback por defecto; vincular una dirección que no sea loopback exige --allow-non-loopback e imprime una advertencia. HTTP/WS sin cifrar no necesita certificados; --tls-cert / --tls-key habilitan HTTPS/WSS cuando se desee. El RPC mediante relay exige WSS para relays que no sean loopback, un identificador de sala de alta entropía de 43 caracteres y el token de escucha. La sincronización de bóvedas sigue usando /v1/channel; el RPC directo utiliza /v1/rpc y el RPC mediante relay utiliza /v1/rpc/{room}/{slot}. La superficie restringida de WebUI es independiente y no debe convertirse en un puente genérico de Request.
Los Centers de autorización opcionales ([[centers]]) convierten un dispositivo en uno gestionado por Center: se rechazan la inicialización autónoma local (init/restore) y la emisión local de autorizaciones MCP. La inicialización y las autorizaciones llegan como tickets firmados por Center, verificados contra los valores public_key configurados. Los tickets de autorización llevan ámbitos deliberados (allow_all, read, write, read_write, read_write_delete); los tickets antiguos con un booleano write se corresponden con read / read_write. Se pueden configurar varios Centers; basta con uno para prohibir la inicialización autónoma. El desbloqueo con contraseña de la bóveda sigue siendo local: los Centers distribuyen políticas, no claves de bóveda. Proteja los secretos de firma y los tokens de administrador de Center como credenciales de root. Consulte docs/center.md.
Las huellas digitales de los ejecutables se comprueban inmediatamente antes de iniciar los procesos. No hay aislamiento del sistema operativo, requisito de código firmado, ejecución atómica mediante identificador de archivo ni contención de procesos descendientes. Un ejecutable de confianza puede cargar plugins o delegar trabajo.
Las copias al portapapeles de memoria ordinaria/privada, las credenciales copiadas deliberadamente y los archivos exportados salen del almacenamiento cifrado por acción del usuario. credential_copy es una excepción local deliberada, autorizada mediante sudo, a las restricciones de salida de credenciales: su cliente autenticado recibe texto plano UTF-8 para el portapapeles del sistema. La CLI imprime solo el estado de la copia; el móvil muestra confirmación y éxito sin representar el secreto. MCP no puede solicitar copias. El contenido del portapapeles persiste después del bloqueo y puede conservarse en el historial/sincronización del sistema operativo o en otras aplicaciones; no se garantiza su borrado. credential generate crea material de claves dentro de la bóveda; su respuesta de generación y credential public devuelven claves públicas o certificados, nunca claves privadas. La copia deliberada de credenciales puede entregar material de claves privadas UTF-8 almacenado al portapapeles bajo el mismo límite de autorización. Las claves RSA son de 3072 o 4096 bits.
file exec es una exportación de archivo autorizada desde la CLI seguida de ejecución local, usando el permiso existente de lectura de archivos y la auditoría de entrega. No puede leer credenciales ni ampliar la autoridad de MCP/móvil. El programa elegido por el usuario recibe una instantánea en texto plano en un directorio temporal accesible solo por el propietario, hereda el entorno y los flujos de la CLI y puede divulgar contenido sin ocultación de la salida. No se fija ninguna huella digital de ejecutable, igual que al ejecutar manualmente un archivo exportado. El bloqueo/la revocación no pueden recuperar esta copia. La salida normal del hijo, el fallo de inicio y las interrupciones gestionadas provocan su eliminación; la terminación forzada, la pérdida de alimentación o el cierre de la consola de Windows pueden dejar texto plano. La eliminación no es borrado seguro. Solo se supervisa el hijo directo en primer plano, no sus descendientes separados. La ejecución de archivos no mantiene el bloqueo de servicio del daemon.
El adaptador de credenciales HTTPS admite GET/POST con Bearer y Cookie y devuelve solo el estado, no datos arbitrarios de respuesta. Las sesiones SSH, FTP, TCP, MySQL, Redis y PostgreSQL propiedad del daemon exigen sudo y proponer/aprobar/ejecutar cada instrucción. Los tickets no aprobados no pueden ejecutarse. Las claves de host SSH se fijan mediante SHA-256. La autenticación del cliente SSH utiliza una contraseña almacenada o una clave privada OpenSSH importada, y puede adjuntar un certificado OpenSSH almacenado. No están implementadas las claves privadas cifradas ni la firma mediante agente SSH. Las credenciales no se imprimen; la salida remota está acotada. MCP no puede abrir ni aprobar sesiones remotas. Los proxies SSH y de bases de datos de loopback se inician con sudo, se vinculan solo a 127.0.0.1 y se autentican con el servidor mediante secretos almacenados, de modo que los agentes nunca reciben claves. Cualquier proceso capaz de conectarse al puerto local puede utilizar la cuenta remota autorizada sin aprobación por comando; loopback no es autenticación del usuario del sistema operativo. El tráfico local de bases de datos está en texto plano. El bloqueo, la caducidad por inactividad de la bóveda y la detención cierran los listeners y las conexiones activas. Los proxies caducan después de 30 minutos independientemente de la actividad. MCP no puede iniciar, enumerar ni detener proxies. Cada proxy acepta como máximo 16 conexiones; la autenticación tiene un plazo de 30 segundos y paquetes de negociación acotados. El TLS de bases de datos de los proxies utiliza rustls, incluida la negociación de protocolos PostgreSQL/MySQL. PostgreSQL SCRAM verifica la firma del servidor. Se rechaza la autenticación completa de contraseñas SHA-256 de MySQL sin TLS verificado; el intercambio de contraseñas RSA no está implementado. No se admite el reenvío de cancelaciones/opciones de inicio de PostgreSQL ni la compresión de MySQL. Las sesiones de bases de datos utilizan autenticación con contraseña y TLS por defecto (verificación del nombre de host; credencial CA PEM adicional opcional). --no-tls es deliberado. No están implementados la fijación de certificados ni los certificados de cliente.
Los permisos se aplican a una bóveda completa. Los lectores pueden descifrar sus activos; la interfaz del cliente no puede imponer una distinción criptográfica entre que un miembro lea o copie contenido ya concedido a ese miembro.

Autoridad desatendida de escritorio

La CLI/MCP desatendida es una autoridad local independiente mediante token de portador que se habilita voluntariamente, no una autorización MCP ordinaria ni una sesión sudo. La inscripción exige un terminal interactivo, consentimiento escribiendo ENABLE, desbloqueo con contraseña y sudo con contraseña. Las lecturas posteriores requieren el archivo de cliente elegido deliberadamente, no solicitudes repetidas de contraseña. Su ámbito de bóveda incluye memoria/tarjetas ordinarias y privadas, bytes originales de archivos e historial de la bóveda activa, incluido el texto plano UTF-8 de credenciales almacenadas solicitado deliberadamente. Las lecturas genéricas rechazan credenciales; las referencias de tarjetas protegidas no se resuelven automáticamente. Se deniegan las revisiones en cuarentena. No existe una superficie de modificación de activos, ejecución, administración, sincronización, volcado de copias de seguridad, ejecución de búsquedas/modelos ni avance del contador OTP. La pertenencia actual del dispositivo y el ámbito de la autorización se comprueban en cada lectura; se guarda una intención de entrega firmada antes de emitir la salida, y un fallo de auditoría/almacenamiento deniega la entrega.

La envoltura independiente de la clave maestra conserva el desbloqueo/la recuperación mediante contraseña. Su clave de envoltura se mantiene por separado a través de windows-dpapi (DPAPI del usuario actual), macos-keychain (Keychain sin sincronización) o linux-secret-service (Secret Service del bus de sesión), seleccionados deliberadamente. owner-file es una opción deliberada de menor protección: material de envoltura en texto plano protegido únicamente por permisos de la cuenta del sistema operativo. No hay alternativa automática. Las lecturas al inicio no solicitan desbloqueo del llavero ni interfaz de autenticación; la custodia no disponible, bloqueada o que necesita aprobación falla de forma cerrada. Un cliente de protocolo no puede controlar comportamientos arbitrarios de interfaz específicos del proveedor. Estos backends no establecen confidencialidad frente a procesos de la misma cuenta o administradores del sistema operativo, ni una garantía de custodia respaldada por hardware.

Un inicio desatendido correcto carga las claves mientras la autorización ordinaria permanece bloqueada. No desbloquea las operaciones ordinarias de CLI/MCP, sudo, nube ni RAG. El lock manual borra las claves e inhibe de forma duradera el inicio desatendido entre reinicios; el desbloqueo con contraseña por sí solo no lo reanuda. unattended resume exige gestión desde un terminal local autorizada con contraseña. revoke elimina de forma duradera una autorización; disable deshabilita la autoridad y revoca todas las autorizaciones antes de limpiar el backend. Un fallo al escribir el bloqueo duradero devuelve un error, por lo que no se puede prometer persistencia en un dispositivo sin posibilidad de escritura. El texto plano ya entregado no se puede recuperar mediante bloqueo, revocación o deshabilitación.

El archivo de cliente es una capacidad secreta de portador, independiente de los archivos ordinarios de autorizaciones MCP y vinculada al almacenamiento seleccionado. La clave de envoltura está vinculada a la identidad canónica del almacenamiento/cabecera. La autoridad desatendida no se incluye en copias de seguridad lógicas, emparejamiento de dispositivos ni sincronización de bóvedas. Copiar toda la base de datos sin procesar sigue copiando su tabla auxiliar de envoltura/autoridad; copiar archivos de cliente o material de custodia también puede conservar la autoridad. La reversión de todo el dispositivo a un estado anterior y el borrado seguro siguen fuera de las garantías. Mantenga estos archivos fuera del control de versiones, los registros y las copias de seguridad compartidas.

Los almacenamientos gestionados por Center rechazan la autoridad desatendida. HTTP/WebSocket, RPC mediante relay, FFI móvil/Share y WebUI no pueden usar esta vía, incluso con elevación ordinaria. Los permisos y restricciones de credenciales de mcp serve --grant-file ordinario no cambian. El mcp serve-unattended --client-file independiente expone deliberadamente secretos al cliente receptor. Base64url es codificación, no cifrado: los proveedores de IA, las transcripciones, los registros de herramientas y las cachés pueden conservar o transmitir secretos descodificados o sus valores codificados. El acceso de solo lectura no convierte la divulgación de secretos en algo inocuo.

La cobertura de extremo a extremo en Linux utiliza custodia owner-file con el daemon y la CLI/MCP reales. La fixture aislada del protocolo Linux Secret Service no es una prueba de un llavero de escritorio real. Windows DPAPI, macOS Keychain y la validación de llavero real/nativa sin interfaz siguen siendo requisitos de publicación; la revisión independiente está pendiente. Consulte los detalles de uso y validación.

Recuperación y servicios de modelos

Los índices BM25 y los vectores normalizados son cachés acotadas en memoria de memoria/tarjetas ordinarias autorizadas. Se invalidan con los cambios de política/contenido y se borran al bloquear. Los índices nunca contienen cuerpos de credenciales ni contenido deliberadamente privado; siguen excluidos los activos de archivos y las revisiones sin resolver/en conflicto. Ingerir deliberadamente un documento de texto/Markdown crea una tarjeta de conocimiento ordinaria, por lo que el operador no debe importar texto confidencial como datos ordinarios públicos para la bóveda. El almacenamiento temporal de SQLite para búsquedas se fuerza a memoria; el contenido en caché no se incluye en copias de seguridad ni exportaciones a la nube. Siguen aplicándose las limitaciones de la memoria del proceso.

EmbeddingGemma local se ejecuta dentro del proceso mediante una biblioteca nativa de inferencia; sus archivos públicos del modelo solo se descargan mediante un comando deliberado de instalación o se suministran localmente. La telemetría de ONNX se deshabilita deliberadamente antes de crear sesiones de inferencia. Las descargas integradas fijan una revisión del repositorio y verifican cada archivo mediante SHA-256 antes de publicarlo. Los archivos del modelo tienen su propia licencia Gemma. No son material secreto ni un límite de seguridad auditado de forma independiente.

Configurar una URL remota de embeddings permite que las operaciones RAG autorizadas envíen todos los fragmentos de documentos elegibles a ese endpoint. La generación envía la pregunta y los fragmentos de fuentes seleccionados; la reordenación aprendida envía sus candidatos. El cliente debe confiar en los proveedores de modelos y proxies configurados. Los pasos de modelos dirigidos a proveedores que no sean loopback se rechazan para bóvedas exclusivas del dispositivo antes de la inferencia. Siguen disponibles la inferencia local y los servicios loopback configurados deliberadamente. Los clientes MCP ordinarios no pueden elegir URL de proveedores, credenciales ni ajustes de proxy en los argumentos de herramientas, y siguen limitados a la bóveda y los permisos de contenido ordinario de su autorización. Las claves API se referencian por nombre de variable de entorno, nunca mediante valores literales de configuración o CLI. Se suprimen los cuerpos de respuestas HTTP fallidas y se rechazan las reproducciones directas de material de autenticación en respuestas generadas; un proveedor configurado malicioso sigue fuera del límite local de confidencialidad.

Las URL de modelos remotos exigen HTTPS; HTTP solo se permite en loopback. Se rechazan las redirecciones de las API de modelos. Las solicitudes loopback omiten los proxies; otras solicitudes pueden utilizar proxies HTTP(S)/SOCKS o el entorno de proxy. Los reintentos están acotados y restringidos a fallos transitorios de conexión/lectura, HTTP 429 y determinadas respuestas 5xx. Los reintentos pueden repetir el cálculo/la facturación del modelo. La validación TLS no se deshabilita.

El trabajo de modelos no mantiene el mutex de escritura del servicio. El bloqueo, las autorizaciones caducadas/revocadas o los cambios en el estado de las fuentes suprimen resultados tardíos e impiden pasos posteriores. Una solicitud/inferencia en curso puede finalizar, y el texto ya divulgado remotamente no se puede recuperar. Las fuentes recuperadas son datos, no instrucciones; la generación no tiene herramientas de aplicación. Los identificadores de cita válidos no demuestran que una respuesta esté fundamentada en hechos ni eliminan el riesgo de inyección de instrucciones desde texto de fuentes no fiables.

Panel de estado de escritorio

La configuración TOML local contiene únicamente ajustes no secretos de almacenamiento/relay/escritorio. Los archivos seleccionados deliberadamente que faltan, las claves desconocidas y los valores malformados se rechazan antes de abrir un almacenamiento. Las rutas relativas de almacenamiento se resuelven junto al archivo seleccionado. Cambiar la ruta selecciona otro almacenamiento y no migra datos. La validación de URL del relay conserva las restricciones existentes de TLS remoto y prohibición de credenciales en la URL.

La WebUI opcional escucha únicamente en 127.0.0.1. GET /api/status y el editor restringido POST /api/cards están protegidos por un token aleatorio de 256 bits creado para cada proceso. El lanzador coloca el token en el fragmento de URL; la página lo elimina de la barra de direcciones, lo mantiene en el almacenamiento de sesión de la pestaña y utiliza una cabecera Authorization. La URL completa de lanzamiento es una capacidad del panel y no debe compartirse. Se deniegan las solicitudes con Host inesperado, Origin ajeno o metadatos de fetch entre sitios. No se ofrecen acceso CORS, recursos de terceros ni inclusión en marcos. La proyección de estado sigue siendo de solo lectura. La edición de tarjetas utiliza una lista de permitidos deliberada independiente en la CLI hermana, con como máximo cuatro solicitudes simultáneas y un límite de solicitud de 1 MiB. Permite operaciones ordinarias de tarjetas/tipos, no desbloqueo, sudo, lecturas de archivos, lecturas de credenciales, revelación de secretos, autorizaciones ni ejecución de procesos. Los activos privados se comprueban antes de devolver el contenido de una tarjeta. Los campos sensibles se enmascaran y su cuerpo estructurado interno nunca se devuelve. No está implementada la inscripción biométrica/PIN en el navegador: las vías nativas móviles/CLI verificadas gestionan los valores sensibles. El token de lanzamiento ahora autoriza escrituras ordinarias de tarjetas y CRUD de plantillas; protéjalo en consecuencia. Esto no es un puente IPC genérico.

El monitor local consulta el daemon mediante su IPC autenticado normal en un subproceso de corta duración, con un plazo de tres segundos para acotar las lecturas bloqueadas de canalizaciones de Windows. Borra los detalles cuando fallan las consultas; el bloqueo oculta los detalles en el siguiente sondeo. El sondeo no renueva el tiempo de inactividad del desbloqueo ni concede elevación. El estado de escritorio sigue sin estar disponible para capacidades MCP. Un programa malicioso en la misma cuenta del sistema operativo sigue dentro del límite local de confianza existente.

La bandeja puede iniciar el daemon local mediante una acción deliberada del menú. Cerrar la bandeja/el panel detiene su listener HTTP y su monitorización; no detiene ni desbloquea un daemon que se ejecute independientemente. La autenticación permanece en la CLI.

Trabajos criptográficos de escritorio

crypto_job exige elevación del terminal local y un resumen criptográfico que vincule el plan público exacto, las huellas digitales de entrada/herramientas y las referencias de credenciales. MCP y FFI móvil no pueden invocarlo. Las credenciales deben pertenecer a la bóveda autorizada. La intención firmada se confirma antes de la ejecución externa y se audita el éxito/fallo. La cadena de herramientas permanece dentro del límite de confianza de la cuenta del sistema operativo; el hash de ejecutables no limita bibliotecas, auxiliares, procesos hijos ni acceso a la red.

Las claves privadas/contraseñas se materializan como archivos temporales en un espacio de trabajo accesible solo por el propietario (permisos Unix o una DACL protegida de Windows). Los argumentos contienen rutas de archivos, nunca valores de credenciales inyectados. Se suprime la salida de las herramientas. La limpieza normal elimina el espacio de trabajo e invoca la limpieza de GPG-agent/Keychain temporal cuando corresponde. Una terminación abrupta puede dejar texto plano o procesos auxiliares; no hay garantía de borrado seguro ni contención del árbol de procesos. El Keychain temporal de iOS tiene una contraseña vacía y depende de los permisos del espacio de trabajo. Esto no es custodia de claves respaldada por hardware. La salida descifrada deliberadamente es un archivo en texto plano.

El primer adaptador iOS admite una .app aprovisionada con frameworks/dylibs, sin aplicaciones/extensiones anidadas ni enlaces. La verificación de la firma de código no verifica la elegibilidad de aprovisionamiento de Apple. La salida OpenPGP son firmas separadas o datos cifrados, no PGP/MIME ensamblado automáticamente. Consulte trabajos criptográficos para conocer los formatos y límites de las plataformas.

Captura de credenciales en CLI

catch exige la sesión sudo existente del terminal antes de solicitar entrada, leer stdin o iniciar su comando de origen deliberado. El servicio comprueba de nuevo la autorización al almacenar la credencial. La captura solo importa al almacenamiento protegido de credenciales; por sí misma no expone lectura/exportación de credenciales mediante CLI o MCP.

La captura de comandos lee solo stdout, cierra stdin del hijo y descarta stderr del hijo. El texto capturado y los errores del analizador nunca se imprimen. Los comandos fallidos, los tiempos de espera agotados, la entrada excesiva, los resultados ambiguos de expresiones regulares y las claves duplicadas de objetos JSON no guardan credenciales. Las cadenas JSON analizadas se borran tanto en caso de éxito como de fallo de análisis; los búferes temporales propiedad de dependencias siguen sujetos a los límites de memoria anteriores. El llamador debe confiar en el programa seleccionado: conserva los permisos ordinarios del sistema operativo y puede escribir sus propios archivos, registros o tráfico de red. La limpieza por tiempo de espera mata al hijo directo, no a sus descendientes. La captura es procesamiento deliberado de entrada/comandos, no monitorización de otros terminales ni de la entrada del teclado. Los archivos de origen existentes y el historial del shell no cambian. Utilice datos sintéticos para las pruebas y mantenga los secretos fuera de los argumentos de comandos.

Autorización de nube

El inicio de sesión en la nube utiliza un código de autorización del navegador con PKCE y validación de estado. El móvil utiliza AppAuth y una redirección nativa registrada; pasar a segundo plano bloquea la bóveda, y volver del navegador exige una nueva autorización local antes de intercambiar tokens. Los tokens móviles de acceso/actualización permanecen dentro de Rust. La sincronización en primer plano se ejecuta fuera del registro FFI y de los bloqueos del servicio; el bloqueo en segundo plano invalida las importaciones, actualizaciones de tokens y respuestas tardías. La CLI intercambia códigos con endpoints HTTPS fijos fuera del mutex del servicio y después envía los tokens mediante IPC local autenticado. El servicio exige un ticket de un solo uso y con caducidad vinculado al llamador/proveedor/identificador de cliente, además de sudo vigente. El bloqueo y el cierre de sesión invalidan los tickets, incluidas las respuestas de solicitudes de red en curso. La CLI local permanece dentro del límite de confianza de la cuenta del sistema operativo.

Los tokens OAuth/secretos de cliente se cifran dentro del estado local del dispositivo y se excluyen de las copias de seguridad exportadas, el emparejamiento de dispositivos, la sincronización de bóvedas, las búsquedas y MCP. El estado expone únicamente metadatos de cuenta y caducidad. Cerrar sesión elimina los tokens locales, no el consentimiento en el proveedor ni las copias históricas de la base de datos local cifrada. La revocación remota utiliza la configuración de aplicaciones conectadas del proveedor. La autorización de la cuenta no concede acceso a la bóveda. Un ejecutor de objetos inmutables pone en cola y aplica sobres de bóveda cifrados para sus destinatarios mediante las carpetas de aplicaciones de OneDrive y Google Drive. Los adaptadores de proveedores y la actualización de tokens se prueban con fixtures locales; no se han validado cuentas reales de proveedores. Los acuses de bandeja de salida/entrada permanecen en el estado cifrado local al dispositivo y se excluyen de copias de seguridad, paquetes de emparejamiento y MCP. El bloqueo y el cierre de sesión invalidan los acuses de transferencias en curso; los trabajos incompletos siguen pudiendo reanudarse después del desbloqueo. Los nombres de objetos de nube son hashes del texto cifrado, no títulos de bóvedas ni identificadores de cuentas.

Límites de tarjetas protegidas

La creación/sustitución de tarjetas protegidas exige sudo y almacena atómicamente una tarjeta de metadatos públicos más una credencial. Las contraseñas de cuentas, los valores dotenv, los tokens HTTP y las semillas OTP nunca entran en el índice ordinario de texto completo. Las vistas previas de dotenv enmascaran cada valor con un *** fijo; las lecturas y exportaciones genéricas nunca devuelven el secreto. La operación local deliberada de copia de credenciales también admite tarjetas protegidas, incluidas sus semillas/tokens/contraseñas, bajo el límite del portapapeles descrito anteriormente. MCP ordinario puede buscar resúmenes ordinarios, pero no crear secretos protegidos, generar códigos OTP ni enviar solicitudes autenticadas. Los metadatos y el contenido completo de las revisiones permanecen cifrados en reposo y durante la sincronización.

Importación y exportación de inicios de sesión de sitios web

Los inicios de sesión de sitios web son una tarjeta protegida login (URL públicas del sitio y nombre de usuario; la contraseña es la credencial almacenada). login_import exige sudo y un rol con escritura; normaliza un CSV del navegador (analizado en crates/core), un perfil Firefox de solo lectura, el Administrador de credenciales de Windows o una exportación descifrada hacia la misma vía de importación. La deduplicación compara la contraseña descifrada de un inicio de sesión existente en tiempo constante dentro del límite del servicio; se omiten los inicios de sesión idénticos, un inicio diferente con el mismo sitio y usuario se convierte en una tarjeta independiente salvo que se indique --update, y una importación individual está limitada (2000 filas). La columna note del navegador se descarta salvo solicitud deliberada, porque las notas entran en el índice ordinario. La lectura directa de Firefox solo admite la envoltura moderna PBES2 (PBKDF2-HMAC-SHA256 + AES-256-CBC) de key4.db con valores de inicio de sesión 3DES-CBC y una contraseña principal conocida o vacía; la envoltura antigua 3DES-PKCS#12 se notifica, no se descifra. Leer el almacenamiento propio de un navegador no debilita su protección y está sujeto al límite de cuenta del sistema operativo descrito anteriormente.

login_export exige sudo y rechaza bóvedas exclusivas del dispositivo. El formato cifrado (memories/logins/v1) sella las entradas bajo una contraseña independiente con Argon2id y XChaCha20-Poly1305 y puede importarse en cualquier bóveda. El formato CSV compatible con Chromium es texto plano que sale del almacenamiento cifrado: es una excepción local deliberada como credential_copy, permitida únicamente para un llamador local cli: (nunca MCP, remotos HTTP/relay ni FFI móvil/Share, impuesto tanto por una lista de llamadores permitidos como por la lista de denegación móvil), confirma una intención de entrega firmada antes de devolver texto plano y escribe un archivo accesible solo por el propietario con la inyección de fórmulas de hojas de cálculo neutralizada. El operador debe proteger y eliminar ese archivo.

La generación TOTP y HOTP es una salida deliberadamente autorizada de un código de corta duración, no una exportación de la semilla. La generación se audita sin el código ni la semilla. HOTP persiste el contador incrementado con la revisión de la tarjeta en cada generación. Existe compatibilidad con OTP SHA-1 estándar para interoperabilidad; en lo demás, la aplicación utiliza sus algoritmos modernos existentes de cifrado autenticado y firma. TOTP exige un reloj local correcto. Este cliente no puede impedir que un verificador reutilice un código aceptado. La importación de URI otpauth:// acepta solo tipos totp/hotp; la importación otpauth-migration:// descodifica exportaciones MigrationPayload de Google Authenticator únicamente en tarjetas totp/hotp y nunca expone la semilla mediante búsquedas o MCP ordinario. Las lecturas deliberadas de credenciales sin supervisión pueden divulgar la semilla almacenada.

Los identificadores de bóvedas exclusivas del dispositivo controlados por el cliente se persisten en estado cifrado. Su contenido se excluye del emparejamiento de dispositivos y las copias de seguridad exportadas, y se deniega la exportación para sincronización/miembros. Una máquina comprometida o un cliente de confianza modificado pueden eludir estos controles de aplicación. No se afirma confidencialidad frente a un miembro autorizado que ya posea las claves criptográficas de una bóveda compartida.

La plantilla protege campos dedicados a secretos. Los usuarios deben mantener los secretos fuera de títulos, notas, etiquetas y campos de origen ordinarios. La importación no borra de forma segura un archivo dotenv existente, el contenido del portapapeles ni el historial previo del shell.

Referencias a secretos en la wiki

protect_secret exige sudo local y acceso de escritura. Crea atómicamente una credencial y sustituye todas las coincidencias exactas del secreto no vacío suministrado en un cuerpo actual de memoria/tarjeta por {{secret:LABEL}}. Una asignación tipada de la misma bóveda resuelve la etiqueta a su credencial; el marcador por sí solo no concede acceso. Las etiquetas tienen entre 1-64 letras ASCII, dígitos, guiones bajos o guiones. Se rechaza un secreto también presente en metadatos, al igual que los documentos en conflicto y las etiquetas reutilizadas. Las ediciones ordinarias conservan la asignación; las escrituras genéricas no pueden adjuntar ni cambiar referencias. La lectura, búsqueda, listado, grafo y MCP no resuelven estas referencias. La copia resuelve la credencial actual después de la autorización y confirma una intención de entrega de auditoría sin el secreto antes de devolver texto plano al cliente local. Esta intención no demuestra que la escritura posterior en el portapapeles del sistema operativo haya tenido éxito. Las copias al portapapeles exigen UTF-8 sin bytes NUL; copiar una tarjeta OTP entrega su semilla, no un código de un solo uso generado.

La sustitución afecta únicamente al cuerpo actual, no al historial de revisiones firmadas, archivos de recuperación, otros documentos, copias de seguridad ni copias compartidas anteriormente. No es descubrimiento automático de secretos ni rotación de claves en el proveedor. Las claves ya expuestas deben revocarse/rotarse con su emisor. Las nuevas referencias protegidas exigen clientes actualizados; los clientes antiguos no pueden descodificar el campo de contenido añadido. Consulte la guía de uso para conocer las reglas de sustitución y el comportamiento de los clientes.

Límites de recursos y operación

Argon2id: 64 MiB, tres iteraciones, un carril, salida de 32 bytes; parámetros fijos versionados, sal aleatoria de 16 bytes. Sin restricción de longitud de contraseña a nivel de aplicación.
XChaCha20-Poly1305 con nonces aleatorios de 24 bytes; contextos autenticados independientes para claves maestras, estado, puntos de control, copias de seguridad, transporte y fragmentos de contenido de 256 KiB.
Como máximo 16 MiB de cuerpo de activo codificado por revisión (las importaciones binarias tienen sobrecarga base64). Todo el estado cifrado se reescribe transaccionalmente en SQLite; está pensado para bibliotecas pequeñas, no almacenamiento de archivos de varios gigabytes.
Sobre de sincronización completo: límite del relay de 32 MiB. Cuatro salas simultáneas, dos pares cada una, colas acotadas, 16 tramas entrantes/segundo, límite de inactividad de recepción de 60 segundos y duración máxima de conexión de diez minutos. Sin entrega sin conexión.
Un proceso hijo de confianza ocupado puede ocupar el servicio local durante hasta cinco minutos; un hijo de un vínculo de ejecución ocupa solo su propia conexión IPC durante ese tiempo. Las operaciones HTTPS tienen un tiempo de espera de 30 segundos. La retención es solo de adición; la poda de auditoría/versiones y la sincronización incremental se posponen.
La resolución de conflictos de permisos exige que el mismo propietario siga autorizado en ambas ramas. Las disputas de propiedad más complejas fallan de forma cerrada y requieren un procedimiento deliberado de recuperación futuro.

Despliegue

Vincule el relay a loopback detrás de TLS. Deshabilite el registro de cuerpos de solicitudes/respuestas del proxy inverso, el almacenamiento intermedio en disco, los volcados de memoria y los volúmenes persistentes de contenedores. TLS protege los metadatos del transporte frente a las redes intermedias; el cifrado de extremo a extremo protege los activos incluso frente al terminador TLS. El contenedor de ejemplo utiliza un usuario que no es root.

Realice copias de seguridad desde el cliente. El relay no es un sistema de copias de seguridad. Mantenga separada la contraseña independiente de la copia de seguridad y pruebe la recuperación antes de confiar en una copia.

Informe de los defectos de seguridad de forma privada al propietario del repositorio. No incluya contraseñas reales, valores de credenciales, contenido descifrado ni paquetes completos de producción en incidencias públicas.