Cómo instalar Vaultwarden en un VPS con Docker

Qué va a crear

Un gestor de contraseñas bajo su control: Vaultwarden se ejecutará en un contenedor pequeño detrás de un proxy inverso que terminará HTTPS. Las aplicaciones oficiales de Bitwarden del teléfono, el portátil y el navegador se conectarán a él. Vaultwarden vuelve a implementar en Rust la API del servidor de Bitwarden y usa el mismo protocolo que bitwarden.com. Por eso, los clientes oficiales funcionan sin cambios, siempre que mantenga el servidor actualizado. Las nuevas versiones de los clientes a veces requieren una versión compatible de Vaultwarden: se necesita la versión 1.37.2 para los clientes 2026.8.0 y posteriores. Aun así, Vaultwarden consume aproximadamente 100 MB de RAM, frente a la pila oficial formada por varios contenedores.

La instalación ocupa una docena de líneas de Compose. Hay tres aspectos que realmente importan y que suelen fallar: TLS debe estar disponible antes de abrir el almacén web; los registros públicos deben cerrarse en cuanto exista su propia cuenta; y el volumen de datos debe tener copias de seguridad que se hayan restaurado como prueba, porque ese único directorio contiene todas sus contraseñas.

Requisitos previos y problemas importantes

• Un VPS con Docker Engine y el complemento Compose, en una instancia KVM nueva de Ubuntu 24.04 con acceso de root o sudo. 512 MB de RAM son suficientes; 1 GB ofrece un margen cómodo. Es uno de los servicios más ligeros que puede ejecutar y aparece cerca del principio de la lista de servicios que merece la pena alojar uno mismo. Aun así, dimensione la instancia según los demás servicios que compartan el sistema: alojar una biblioteca de fotos autoalojada como PhotoPrism o Immich en el mismo VPS eleva el mínimo de RAM a varios gigabytes, mientras que Vaultwarden apenas lo modifica. El mismo cálculo se aplica a los frontends multimedia que añada más adelante, ya que convertir una biblioteca de Jellyfin en un videoclub de los años 90 que se pueda recorrer implica otro contenedor permanente y margen de RAM para la transcodificación dentro del mismo presupuesto.
• Un dominio con un registro A (y AAAA si dispone de IPv6) que apunte vault.example.com al VPS. El certificado TLS se emite para este nombre exacto, por lo que DNS debe resolverlo antes de comenzar.
• Los puertos 80 y 443 abiertos a Internet y terminados por el proxy inverso, nunca directamente por Vaultwarden. El puerto 80 se utiliza sólo para el desafío del certificado ACME y para la redirección de HTTP a HTTPS.
• El problema más importante es el siguiente: los clientes de Bitwarden se niegan a comunicarse con un servidor que no use HTTPS. No existe la opción de «probarlo primero mediante http»; ese procedimiento no funciona por un motivo concreto que se explica a continuación.

Por qué Vaultwarden y no la pila oficial de Bitwarden

Los mismos clientes con una fracción del consumo. La implementación oficial estándar de Bitwarden para alojamiento propio se distribuye como un conjunto de contenedores (MSSQL Express, Identity, Api, Admin y otros) y requiere al menos 2 GB de RAM. Bitwarden también ofrece Bitwarden lite, una sola imagen de Docker que necesita al menos 200 MB de RAM, pero está pensada para uso personal y laboratorios domésticos, no para empresas, y deja la base de datos y sus copias de seguridad completamente bajo su responsabilidad. Vaultwarden es un único binario que almacena todo en una base de datos SQLite de forma predeterminada y consume unas pocas decenas de megabytes en reposo. Para una persona, una familia o un equipo pequeño es la opción evidente. Además, como implementa fielmente la API de Bitwarden, sus datos siguen siendo portables entre Vaultwarden y bitwarden.com.

Lo que se pierde es la mayor parte de las funciones empresariales: no hay aprovisionamiento SCIM (aunque la compatibilidad con SSO mediante OpenID Connect se incorporó en 1.35.0), y usted es el operador, por lo que el parcheado, HTTPS y las copias de seguridad son su responsabilidad. Esta guía cubre esas tres tareas.

Por qué HTTPS no es opcional

La bóveda web de Bitwarden y las extensiones del navegador derivan las claves de cifrado en el navegador mediante la Web Crypto API (window.crypto.subtle). Los navegadores sólo exponen crypto.subtle en un contexto seguro: HTTPS o el caso especial de las direcciones de loopback, como http://localhost y http://127.0.0.1. Mediante http://vault.example.com sin cifrar, undefined, por lo que, en cuanto la aplicación deriva una clave, genera una excepción y la consola muestra:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

La página se bloquea o muestra un error criptográfico genérico, y ningún usuario puede iniciar sesión. Los clientes de escritorio, móviles y de navegador realizan su propia comprobación de una URL autohospedada. Si el endpoint usa http o no es accesible, rechazan la conexión con:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Ambos casos tienen la misma causa: no hay un HTTPS válido. Por eso configuramos TLS primero y nunca abrimos la bóveda mediante http, ni siquiera una vez para comprobarla rápidamente.

Paso 1, DNS y el proxy inverso (primero TLS)

Apunte el registro a su VPS y confirme que resuelve a la dirección correcta:

dig +short vault.example.com

La línea que imprime debe ser la IP de su VPS. Si está vacía o es incorrecta, corrija el DNS y espere a que expire el TTL; la emisión del certificado fallará si se intenta contra un nombre que no resuelve.

Para el front-end HTTPS, esta guía utiliza Traefik, el cual emite y renueva certificados de Let's Encrypt automáticamente y se integra directamente en Compose. Si aún no lo ejecuta, siga primero la configuración del proxy inverso Traefik y TLS automático; esto crea una red Docker externa (proxy más abajo) y un resolvedor ACME (letsencrypt) a los que se conecta el servicio Vaultwarden. Nginx con terminación TLS y un certificado emitido manualmente funciona de forma idéntica desde el lado de Vaultwarden.

¿Prefiere nginx y Certbot en lugar de Traefik? Coloque Vaultwarden en 127.0.0.1:8080 (añada ports: ["127.0.0.1:8080:80"] al servicio y elimine las etiquetas de Traefik), luego emita un certificado y haga proxy hacia él. La parte del certificado está cubierta en emisión de certificados Let's Encrypt con Certbot y nginx. El extra crítico es la actualización de WebSocket en la ruta de notificaciones:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Observe la línea X-Real-IP, es la que permite que Fail2ban vea más tarde al atacante real en lugar de 127.0.0.1. Todo lo demás en esta guía es idéntico, independientemente de si Traefik o nginx se encuentran al frente.

Paso 2: el archivo de Compose

Cree primero el directorio del proyecto. Esta guía usa /opt/vaultwarden, que hace predecibles el nombre del proyecto de Compose y, por tanto, el volumen de datos vaultwarden_vw-data; los pasos de Fail2ban y de copia de seguridad que aparecen más abajo dependen de ese nombre exacto.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Cree un .env para el secreto de administración y el archivo de Compose en ese directorio.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Genere ese token con openssl rand -base64 48 y péguelo en el archivo. (Más adelante se explica una forma con un hash más resistente; para empezar, basta con una cadena aleatoria larga).

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Hay dos aspectos de este archivo que sostienen todo el diseño. No existe ninguna asignación de ports:, por lo que sólo se puede acceder a Vaultwarden a través de Traefik y su TLS; publicar su puerto en el host es la forma de servir el almacén por http por accidente. Además, DOMAIN debe ser la URL HTTPS pública completa: se incorpora a los enlaces de los adjuntos, a la autenticación de dos factores de WebAuthn y al endpoint de notificaciones, por lo que un valor incorrecto o http rompe esas funciones aunque el sitio cargue. La etiqueta latest es una excepción deliberada a la regla habitual de no usar nunca latest. Vaultwarden publica sus versiones estables como una única imagen continua, con :testing como canal independiente de versiones preliminares, así que actualice de forma intencionada y revise las notas de la versión antes de descargar la imagen. Esta excepción es limitada: para la mayoría de los contenedores de larga duración es preferible fijar una etiqueta exacta. Eso es lo que mantiene predecible un agente siempre activo alojado en el mismo VPS entre reinicios y descargas de imágenes.

Inícielo y supervise el registro:

docker compose up -d
docker compose logs -f vaultwarden

Un inicio correcto termina con una línea como Rocket has launched from http://0.0.0.0:80. Espere unos segundos para que Traefik obtenga el certificado y cargue https://vault.example.com. Debería aparecer el almacén web de Bitwarden con un candado válido y sin ninguna advertencia de certificado.

Paso 3, un ADMIN_TOKEN seguro y la trampa de $$

ADMIN_TOKEN protege /admin, el panel que puede leer todos los usuarios y ajustes de la instancia, así que debe tratarlo como una contraseña de root. Hay dos formatos válidos.

El formato sencillo es la cadena aleatoria que ya generó con openssl rand -base64 48. Como base64 nunca contiene un $, puede incluirse directamente en .env sin escapar caracteres.

El formato reforzado es un hash PHC de Argon2, por lo que el token en texto plano nunca se almacena en disco. Genere uno con la misma imagen:

docker run --rm -it vaultwarden/server /vaultwarden hash --preset owasp

Solicita el valor dos veces e imprime una cadena que empieza por $argon2id$v=19$.... Esta es la trampa que puede hacerle perder una hora: Docker Compose trata $ como interpolación de variables. Por tanto, si pega el hash directamente bajo environment: en el archivo Compose, debe duplicar cada $ como $$. Puede entrecomillar el valor; lo importante es el escape:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Si prefiere guardar el hash en .env, la regla cambia: deje los signos $ simples, encierre todo el valor entre comillas simples (ADMIN_TOKEN='$argon2id$v=19$...') y la línea ${ADMIN_TOKEN} existente del archivo Compose lo utilizará. Nunca duplique $ en .env. Si deja signos $ simples en el propio archivo Compose, Compose muestra una advertencia The "argon2id" variable is not set y deja vacío el token; después, /admin rechaza su contraseña correcta. Ejecute docker compose up -d y guarde el texto plano que introdujo en el indicador en su propio gestor de contraseñas.

Paso 4: registre su cuenta y cierre el acceso

Con SIGNUPS_ALLOWED: "true", abra https://vault.example.com, haga clic en Create account y regístrese con su correo electrónico y una contraseña maestra segura. Esta contraseña maestra no se puede recuperar y no existe ninguna opción para restablecerla. Guárdela primero en un lugar duradero.

Ahora cierre el acceso. Edite el archivo Compose para desactivar los registros:

      SIGNUPS_ALLOWED: "false"

Vuelva a aplicar la configuración con docker compose up -d. Esto no es una medida de seguridad que pueda posponer. Si permanece abierto, cualquiera que encuentre la URL, incluidos los rastreadores, puede crear una cuenta en su servidor. No podrán leer su bóveda, pero consumirán recursos y convertirán su instancia privada en un servicio abierto. La señal de que lo dejó activado es que /admin muestra cuentas que usted no creó.

Para añadir más adelante a familiares o compañeros de equipo sin volver a abrir los registros públicos, use el botón Invite User en /admin. Esta opción requiere configurar SMTP para que el invitado reciba su enlace.

Paso 5: acceso a /admin

Acceda a https://vault.example.com/admin e introduzca el token de administración en texto plano (la cadena aleatoria o la contraseña que ha convertido en hash, no el hash). Desde ahí puede enumerar usuarios, ajustar la configuración, enviar un correo de prueba y crear una instantánea de la base de datos.

Si la página muestra The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it, ADMIN_TOKEN está vacío o no está definido, lo que desactiva por completo el panel. Esta también es una opción válida si nunca lo necesita. Si el panel se carga pero rechaza el token, consulte el problema de escape de $$ en la lista de errores que aparece más abajo. ¿Ha olvidado el token? No hay ningún aviso de recuperación. Edite .env o el archivo Compose, establezca uno nuevo y docker compose up -d.

Paso 6: conectar los clientes de Bitwarden

Todos los clientes oficiales pueden conectarse a un servidor autohospedado. Instale el cliente de Bitwarden para escritorio, móvil o navegador desde las tiendas habituales. No necesita una compilación especial de Vaultwarden.

Antes de iniciar sesión, abra el icono de configuración en la pantalla de inicio de sesión (con la etiqueta Autohospedado o Región → Autohospedado), establezca URL del servidor en https://vault.example.com y guarde los cambios. Después, inicie sesión con el correo electrónico y la contraseña maestra que registró. El cliente debería conectarse de inmediato y ofrecer rellenar y guardar las credenciales.

Si un cliente muestra This is not a recognized Bitwarden server. You may need to check with your provider or update your server., la URL es incorrecta, usa http o el certificado no es de confianza. Compruebe de nuevo que https://vault.example.com se cargue correctamente primero en un navegador. Las actualizaciones lentas en otros dispositivos se deben a las notificaciones push de WebSocket, que se explican más adelante.

Paso 7, una jail de Fail2ban para el endpoint de inicio de sesión

Vaultwarden registra cada inicio de sesión fallido en el archivo definido por LOG_FILE, justo lo que necesita un mecanismo de protección contra ataques de fuerza bruta. Si todavía no ejecuta Fail2ban, consulte la guía de refuerzo de SSH con Fail2ban para la instalación y los conceptos básicos. Aquí añadimos una jail para vault.

Primero, busque dónde se encuentra el volumen con nombre en el host para que Fail2ban pueda leer el registro:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

El comando muestra algo parecido a /var/lib/docker/volumes/vaultwarden_vw-data/_data; dentro de él, el registro está en vaultwarden.log. Cree el filtro:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Y la jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Recargue con sudo systemctl restart fail2ban y confirme con sudo fail2ban-client status vaultwarden.

Tres detalles de Docker determinan si esta protección funciona. Primero, si el registro muestra IP: 127.0.0.1 o la dirección de su proxy en cada intento fallido, Vaultwarden está bloqueando el proxy. Establezca IP_HEADER en la cabecera que realmente envía su proxy: X-Forwarded-For para Traefik, X-Real-IP para el bloque de nginx anterior y CF-Connecting-IP detrás de Cloudflare. Desde la versión 1.37.4, con X-Forwarded-For Vaultwarden toma la dirección situada más a la derecha que no está en IP_HEADER_TRUSTED_PROXIES (por defecto, local, que incluye un proxy en el mismo host o en la misma red de Docker). Por tanto, si hay una CDN delante de su proxy, incluya también sus direcciones ahí. Segundo, la cadena de iptables correcta depende del proxy. Con Traefik ejecutándose como un contenedor con puertos publicados, el tráfico atraviesa la ruta FORWARD de Docker, por lo que el bloqueo debe aplicarse en DOCKER-USER, como se indicó arriba. Sin embargo, si eligió la opción de nginx en el host del Paso 1, las conexiones terminan en nginx dentro de la cadena INPUT del host y un bloqueo en DOCKER-USER nunca las verá. En ese caso, elimine la línea chain = DOCKER-USER para que Fail2ban use la cadena predeterminada INPUT. Tercero, use banaction = iptables-allports en lugar del valor predeterminado basado en el puerto. Esta jail no define ningún puerto, y un bloqueo para todos los puertos en DOCKER-USER impide correctamente que el infractor acceda a todos los servicios publicados del equipo.

Paso 8: haga una copia de seguridad del almacén y restáurela realmente

El volumen vw-data es su gestor de contraseñas. Contiene db.sqlite3 (todas las entradas), los directorios attachments/ y sends/, los archivos rsa_key.* que firman las sesiones de inicio de sesión y config.json del panel de administración. Una copia de seguridad que omita cualquiera de estos elementos fallará cuando la necesite.

Copiar db.sqlite3 mientras Vaultwarden está escribiendo puede capturar un archivo parcialmente escrito y dañado. Por eso, haga una instantánea en frío. La interrupción dura unos segundos:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Ejecútelo cada noche desde cron y copie .tgz fuera del servidor. Una copia de seguridad almacenada sólo en el servidor que está protegiendo no es una copia de seguridad. La forma adecuada de transferirla es una copia de seguridad nocturna con restic a otro servidor o a un almacenamiento de objetos, que cifra el archivo y deduplica las instantáneas repetidas automáticamente. El botón Backup Database del panel de administración resulta útil para hacer una instantánea en caliente únicamente del archivo SQLite, pero omite los archivos adjuntos y las claves.

Ahora viene el procedimiento que distingue una copia de seguridad real de una que sólo se espera que funcione: restáurela una vez y compruebe que funciona:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Desde su portátil, cree un túnel hasta el servidor con ssh -L 8888:127.0.0.1:8888 you@your-vps y abra http://localhost:8888 (o http://127.0.0.1:8888). Como las direcciones de loopback cuentan como un contexto seguro, crypto.subtle está disponible y el almacén se descifra mediante http sin cifrar en este caso. Es el único tipo de dirección en el que está permitido. Inicie sesión con su contraseña maestra y confirme que sus entradas están presentes. Si lo están, la base de datos, las claves RSA y la contraseña maestra se restauran correctamente, y podrá reconstruir el servicio en un VPS nuevo en cuestión de minutos. Detenga el contenedor con Ctrl-C y elimine /tmp/vw-restore. Mantenga esta práctica del túnel para cualquier otra interfaz de administración del servidor que nunca deba exponerse a Internet. Así también accedería a un escáner de seguridad open-kritt alojado por usted en el puerto 5173.

Modos de fallo y mensajes que verá

Cannot read properties of undefined (reading 'importKey') en la consola del navegador. El vault se cargó mediante http, por lo que crypto.subtle no está definido. Acceda a él sólo mediante https:// y añada la redirección de HTTP a HTTPS en el proxy.

This is not a recognized Bitwarden server... en un cliente. La Server URL usa http, está mal escrita o el certificado no es de confianza. Confirme que https://vault.example.com muestra un candado válido y vuelva a introducirla en la configuración de self-hosted del cliente.

/admin rechaza la contraseña correcta. El hash de Argon2 perdió su escape. Cada $ debe ser $$ en el archivo Compose, pero debe usarse un solo $ dentro de comillas simples en .env. También es posible que haya introducido el hash en lugar del texto plano que representa.

La sincronización entre dispositivos es lenta y la consola muestra WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. El proxy no reenvía las cabeceras Upgrade/Connection. Traefik lo hace automáticamente; nginx necesita las dos líneas de actualización del paso 1. El vault sigue funcionando, pero sólo sincroniza al abrirse. El puerto dedicado antiguo 3012 desapareció desde v1.31.0, por lo que no se necesita una ruta WebSocket independiente.

Fail2ban informa de un bloqueo, pero el atacante sigue conectándose. Está bloqueando 127.0.0.1 porque IP_HEADER es incorrecto, o el bloqueo se aplica en la cadena de iptables equivocada. Configure chain = DOCKER-USER y banaction = iptables-allports.

Actualizaciones

Descargue la imagen nueva y vuelva a crear el contenedor. El volumen con nombre y todos sus datos se conservan:

docker compose pull
docker compose up -d

Vaultwarden publica versiones con frecuencia. Consulte las notas de lanzamiento del proyecto en lugar de fijar una versión de parche, ya que algunas versiones incluyen instrucciones de migración. Cree una copia de seguridad reciente antes de cualquier actualización importante. Puede volver a una versión anterior restaurando el tarball en un volumen nuevo.

FAQ

¿Vaultwarden es lo mismo que Bitwarden?

Es un servidor compatible e independiente, no el servidor oficial. Vaultwarden vuelve a implementar la API del servidor de Bitwarden en Rust, por lo que los clientes oficiales de escritorio, móviles, de navegador y CLI funcionan con él usando una fracción de los recursos de la pila oficial. El formato de la bóveda es el mismo, así que puede migrar en cualquiera de las dos direcciones mediante exportación e importación.

¿Realmente necesito HTTPS o puedo ejecutarlo mediante http en mi LAN?

Necesita HTTPS para cualquier caso que no sea una prueba de loopback. La bóveda web y las extensiones de Bitwarden usan la API Web Crypto del navegador, que sólo está disponible en un contexto seguro. Por eso, mediante http sin cifrar, el cliente muestra Cannot read properties of undefined y nunca inicia sesión. Las únicas direcciones http que funcionan son las de loopback, como http://localhost o http://127.0.0.1. Por eso la prueba de restauración del paso 8 usa un túnel SSH.

¿Cómo evito que personas desconocidas se registren en mi servidor?

Establezca SIGNUPS_ALLOWED: "false" en el archivo Compose y ejecute docker compose up -d inmediatamente después de crear su propia cuenta. A partir de ese momento, añada nuevos usuarios mediante el botón Invitar usuario de /admin. Para ello, SMTP debe estar configurado para que reciban el enlace de invitación. Revise ocasionalmente la lista de usuarios administradores para confirmar que no hayan aparecido cuentas inesperadas.

¿Cómo hago una copia de seguridad de mi bóveda de Vaultwarden?

Detenga brevemente el contenedor y archive todo el volumen vw-data, db.sqlite3, attachments/, sends/, config.json y los archivos rsa_key.*. Después, copie el archivo fuera del servidor, preferiblemente mediante un cron nocturno. Copiar el archivo SQLite mientras el servidor está en ejecución puede producir una instantánea dañada, así que haga la copia con el servicio detenido. Lo más importante es restaurarla una vez en un contenedor temporal e iniciar sesión. Así sabrá que la copia de seguridad es válida antes de depender de ella.

¿Es realmente seguro alojar mis contraseñas por mi cuenta?

Sí, si hace las tres cosas que cubre esta guía: HTTPS real, registros cerrados junto con un token de administrador seguro y copias de seguridad probadas. La bóveda se cifra en el cliente con su contraseña maestra. Por tanto, ni siquiera el servidor ve sus contraseñas sin cifrar, y el robo de db.sqlite3 no revela sus entradas sin ella. Sin embargo, el servidor sí conserva las direcciones de correo de las cuentas y un hash con salt derivado de cada contraseña maestra. Un atacante puede intentar descifrarlo sin conexión, así que debe proteger el archivo de base de datos y todas sus copias. La contrapartida es que los parches y las copias de seguridad pasan a ser su responsabilidad. Por eso Fail2ban y el procedimiento de restauración no son opcionales en este caso. Una vez configurados, examinar con más detalle dónde puede atacarse realmente una bóveda alojada por cuenta propia es el siguiente paso útil. Como las entradas están cifradas en el cliente, lo que queda por proteger es el token de administrador y el archivo de copia de seguridad.