Introducción
Llevaba años usando Bitwarden. Funciona bien, es open source, tiene extensión para el navegador, apps para todo. No había razón aparente para cambiar. Pero, si funciona tan bien... ¿por qué migrar a algo completamente offline como KeePassXC?

Pues la respuesta es simple y es que había algo que me incomodaba sin que yo pudiera nombrarlo del todo. Y las noticias no ayudaban: RockYou2024, casi 10 mil millones de contraseñas únicas filtradas en un solo archivo. El breach de National Public Data exponiendo datos de 2.9 mil millones de personas. Empresas de gestión de identidad comprometidas silenciosamente durante meses antes de que alguien lo notara. Incluso cosas más cercanas, como la brecha de seguridad que sucedió hace un par de meses con todo el tema de Telcel. Cada vez que leía una de esas noticias miraba mi vault en la nube y pensaba: ¿y si mañana es este?
Mis contraseñas — las de mi banco, mi correo, mis servidores, mis cuentas de trabajo — vivían sincronizadas en servidores de alguien más. Sí, cifradas. Sí, con zero-knowledge. Sí, con toda la documentación de seguridad del mundo. Pero en servidores de alguien más al fin.
No es que Bitwarden sea malo. Es que yo quería algo diferente: control total, sin excepciones.
La pregunta que me hice fue simple: ¿qué pasa si mañana Bitwarden decide cambiar su modelo de negocio, sube precios, o simplemente desaparece? ¿Y si hay un breach? ¿Y si la API tiene un bug silencioso que lleva semanas enviando datos a quien no debe?
No tenía respuestas tranquilizadoras para ninguna de esas preguntas. Así que empecé a buscar alternativas.
Hasta que me encontré con KeePassXC. Un gestor de contraseñas offline, sin sincronización, sin cuentas, sin servidores. Solo tú y un archivo cifrado en tu disco.
¿Qué es KeePassXC?
KeePassXC es un gestor de contraseñas de código abierto, completamente offline. No tiene servidor, no tiene sync en la nube, no tiene cuenta de usuario. Tu base de datos es un archivo .kdbx que vive en tu disco, cifrado con AES-256.
Nadie más tiene acceso a ese archivo. Ni el desarrollador, ni un servidor remoto, ni ningún tercero. Si lo pierdes, lo pierdes. Si lo proteges bien, nadie más llega a él.
Eso es exactamente lo que quería.
Pero "solo con contraseña" me parecía insuficiente para algo tan crítico. Entonces decidí añadir un segundo factor completamente local: un keyfile guardado en una USB cifrada con LUKS.
Así que me busqué en el cajón una USB vieja, la cifré con LUKS, generé un keyfile aleatorio dentro, y configuré KeePassXC para que lo use junto con la contraseña maestra.
La arquitectura del setup
El esquema es sencillo pero robusto:
- La base de datos (
.kdbx) vive en el disco de la computadora - La contraseña maestra la sé de memoria
- El keyfile vive en una USB cifrada con LUKS
Para abrir la base de datos necesitas las tres cosas: el archivo .kdbx, la contraseña maestra, y la USB con el keyfile. Si alguien roba tu laptop, tiene el .kdbx pero no el keyfile. Si alguien roba la USB, tiene el keyfile pero no puede abrirla sin la passphrase LUKS. Si alguien te extorsiona con la contraseña maestra... bueno, ya estamos en otro tipo de problema.
El punto es: ninguna pieza sola es suficiente.
Preparando la USB cifrada con LUKS
LUKS (Linux Unified Key Setup) es el estándar de cifrado de disco en Linux. Cifra el contenido completo del dispositivo de forma que sin la passphrase correcta, lo que hay dentro es ruido aleatorio.
Primero identifiqué mi USB con lsblk. En mi caso era /dev/sdb.
Cuidado: asegúrate de identificar correctamente tu USB. Si usas el dispositivo equivocado, puedes borrar datos importantes de tu disco duro. Siempre revisa dos veces antes de ejecutar comandos de cifrado o formateo.
# Cifrar el dispositivo completo con LUKS
sudo cryptsetup luksFormat /dev/sdb
Cuando te pregunte confirmación, tienes que escribir YES en mayúsculas exactas. Luego te pedirá una passphrase, que es la clave que protege la USB. Que sea fuerte y que no la olvides.
Cuando digo "no la olvides", lo digo en serio. Si pierdes esta passphrase, no hay forma de recuperar el contenido de la USB. Es la única llave que abre ese cifrado.
# Abrir el volumen cifrado
sudo cryptsetup open /dev/sdb keepass_usb
# Formatear con ext4
sudo mkfs.ext4 /dev/mapper/keepass_usb
# Montar
sudo mkdir -p /mnt/keepass_usb
sudo mount /dev/mapper/keepass_usb /mnt/keepass_usb
Ahora tengo la USB montada en /mnt/keepass_usb, lista para recibir el keyfile.
Generando el keyfile
Un keyfile es simplemente un archivo de bytes aleatorios que KeePassXC usa como parte de la clave de descifrado. No tiene que ser legible, no tiene que recordarse, solo tiene que existir en la USB cuando abras la base de datos.
# 64 bytes de entropía real del kernel
sudo dd if=/dev/urandom of=/mnt/keepass_usb/keepass.key bs=64 count=1
# Solo el dueño puede leerlo
sudo chown neandertech:neandertech /mnt/keepass_usb/keepass.key
sudo chmod 600 /mnt/keepass_usb/keepass.key
Por qué dd if=/dev/urandom y no algo más "conveniente": porque /dev/urandom usa el pool de entropía del kernel. No hay patrón, no hay semilla predecible. 64 bytes así son prácticamente imposibles de reproducir por fuerza bruta.
Creando la base de datos
Abrí KeePassXC, creé una nueva base de datos, definí una contraseña maestra fuerte, y en la sección de Key File apunté a /mnt/keepass_usb/keepass.key.
Si ya tienes una base de datos creada y quieres agregar el keyfile después, puedes hacerlo desde:
Database → Database Settings → Security → Master Key → Add additional protection → Key File
Guarda la base de datos en algún lugar de tu disco. Yo uso ~/Vaults/Personal.kdbx. No la pongas en la misma USB que el keyfile — ese es el punto de tenerlos separados.
Cerrando la USB correctamente
Esto es importante. Si simplemente desconectas la USB sin desmontarla, puedes corromper el filesystem. Siempre cierra de esta forma:
sudo umount /mnt/keepass_usb
sudo cryptsetup close keepass_usb
Después de eso, lsblk muestra el dispositivo como crypto_LUKS sin montar, exactamente lo que debe verse.
El flujo diario: kp-open y kp-close
Memorizar esos comandos es un fastidio. Los convertí en funciones de zsh, directo al ~/.zsh_functions de mis DotFiles.
function kp-open() {
sudo cryptsetup open /dev/sdb keepass_usb && \
sudo mount /dev/mapper/keepass_usb /mnt/keepass_usb && \
keepassxc ~/Vaults/Personal.kdbx &
}
function kp-close() {
sudo umount /mnt/keepass_usb && \
sudo cryptsetup close keepass_usb && \
echo "USB cerrada correctamente"
}
Ahora mi flujo es:
- Conecto la USB
kp-openen la terminal- Introduzco la passphrase LUKS + la contraseña maestra en KeePassXC
- Trabajo normalmente
- Al terminar,
kp-close
Dos comandos. Sin fricción innecesaria.
Migrando desde Bitwarden
Esto fue más fácil de lo que esperaba. Bitwarden permite exportar el vault completo en formato JSON, y KeePassXC 2.7+ lo importa directamente.
En Bitwarden:
- Settings → Export Vault → Format:
.json(unencrypted)
En KeePassXC:
- Database → Import → Bitwarden CSV/JSON → selecciona el archivo
Todos los entries, carpetas, usuarios y contraseñas se importan correctamente. Las notas también.
El archivo JSON exportado de Bitwarden no está cifrado. Asegúrate de eliminarlo de forma segura después de la importación, usando shred o una herramienta similar, para evitar que quede en el disco sin protección.
shred -vzu ~/bitwarden_export.json
TOTP: los códigos de dos factores también viven aquí
Una cosa que no esperaba es que KeePassXC maneja TOTP de forma nativa. No necesitas Google Authenticator, Authy, ni ninguna app separada.
Por cada entrada que tenga 2FA activado:
- Click derecho en la entrada → TOTP → Set up TOTP
- Pega el secret (la clave que te da el sitio al activar 2FA, o escaneas el QR)
- Listo
Para usar el código: click derecho → TOTP → Copy TOTP. O puedes ver los códigos directamente activando la columna en View → Columns → TOTP.
Nota importante: si tu base de datos es tu única copia de los seeds TOTP y la pierdes sin backup, pierdes también el acceso a esos 2FA. Guarda los recovery codes de cada servicio en un lugar separado.
Auto-Type: adiós a copiar y pegar
Una de las cosas que sabía que más extrañaría de Bitwarden era la extensión de navegador. Detectaba el sitio, autollenaba usuario y contraseña. Muy cómodo, pero también significaba darle acceso al navegador a KeePassXC. Y a este punto mi paranoia de seguridad ya no me lo permitía.
Para quien prefiere mantener eso separado, KeePassXC tiene Auto-Type: un atajo de teclado global que detecta la ventana activa y escribe usuario + contraseña directamente, sin extensión, sin socket expuesto al browser.
La configuración es por entrada. En la pestaña Auto-Type de cada entrada puedes definir con qué ventana se asocia (usando wildcards en el título) y la secuencia que escribe:
{USERNAME}{TAB}{PASSWORD}{ENTER}
Si tienes TOTP y el sitio lo pide en el mismo flujo, puedes extender la secuencia:
{USERNAME}{TAB}{PASSWORD}{ENTER}{DELAY 2000}{TOTP}{ENTER}
El {DELAY 2000} le da dos segundos al sitio para cargar el campo del código OTP antes de escribirlo.
Fue sencillo ajustarlo debido a mi configuración de entorno actual, el cual incluye bspwm y sxhkd. Sin embargo, tuve que redirigir el shortcut global de Auto-Type a través de sxhkd para que funcione correctamente, ya que sxhkd captura las teclas primero. La solución fue esta:
ctrl + alt + shift + k
xdotool key --window $(xdotool search --classname "keepassxc" | head -1) --clearmodifiers ctrl+alt+a
¿Y en el celular?
Cuando decía que Bitwarden es multiplataforma, no mentía. KeePassXC no tiene app móvil oficial, pero el formato .kdbx es un estándar abierto que muchas apps compatibles pueden leer.
El archivo .kdbx lo puedes sincronizar a donde quieras — incluyendo tu teléfono. Las apps compatibles son:
- Android: KeePassDX o Keepass2Android
- iOS: KeePassium o Strongbox
Aunque quizá lo más seguro es no sincronizar el .kdbx a la nube, sino transferirlo manualmente por cable cada vez que necesites actualizarlo. O incluso, desarrollar una aplicación de sincronización local que use rsync o algo similar para mantener el .kdbx actualizado entre tu computadora y tu teléfono sin pasar por la nube.
Para el keyfile en móvil, lo más limpio es transferirlo por cable una sola vez. Nunca subas el keyfile a la misma nube que el .kdbx, si ambos están en el mismo lugar, el segundo factor pierde sentido.
El backup que no puedes ignorar
Con este setup, si pierdes la USB sin backup del keyfile, tu base de datos se vuelve inaccesible para siempre. No hay recuperación. No hay soporte técnico que te ayude. Es la consecuencia directa del control total. Aquí no hay "reset password" ni "contact support". Si pierdes la passphrase LUKS o el keyfile, pierdes el acceso a tus contraseñas.
La estrategia que recomiendo es tener tres copias de tu base de datos y keyfile, en tres ubicaciones diferentes.
Lo ideal es que cada copia esté en un medio diferente: una en tu computadora, otra en un disco externo que guardes en casa, y otra en una caja de seguridad o con un familiar de confianza. De esta forma, si hay un incendio, robo o desastre natural, no pierdes todo.
Parece paranoico, pero la realidad es que la mayoría de las personas no hacen backups regulares de sus contraseñas. Y cuando ocurre un incidente, se encuentran sin acceso a sus cuentas críticas. Con este setup, el riesgo de perder todo es real, pero también es un recordatorio constante de la importancia de los backups.
¿Vale la pena el cambio?
Depende de qué busques. Si quieres comodidad máxima y confías en que Bitwarden estará ahí mañana, no hay razón urgente para migrar. Bitwarden es una herramienta excelente.
Pero si lo que buscas es control real sobre tus credenciales, un setup que funcione completamente offline, y la tranquilidad de saber que nadie más tiene acceso a ese archivo aunque quisiera — entonces KeePassXC con USB cifrada es exactamente eso.
Yo llevo usando este setup dos días, y no les voy a mentir, me costó lo suyo acostumbrarme a este nuevo flujo. Sobre todo al ver la cara de mi prometida cuando le dije que ahora tenía que meter una USB cada vez que quería abrir el vault. Pero la verdad es que una vez que lo integras a tu rutina, es sorprendentemente fluido. Y la tranquilidad mental de saber que mis contraseñas no dependen de la continuidad de una empresa o de la seguridad de un servidor remoto, no tiene precio.
"La seguridad no es un producto, es un proceso — y ese proceso empieza por entender qué controlas y qué no."
Referencias

