2.3 Gestión de contraseñas e identidades

KeePassXC es el gestor de contraseñas de referencia para operadores que no quieren depender de un servidor externo. Todo vive en un archivo cifrado con AES-256 que tú controlas — sin cuentas, sin servidores de sincronización, sin telemetría. Si el archivo lo tienes tú, nadie más lo tiene.

La característica clave para OPSEC no es la contraseña maestra — es la separación por identidades. Una base de datos para tu identidad real, otra para trabajo, otra para operaciones anónimas. Cada una con su propia contraseña maestra. Si una base de datos se compromete, las otras permanecen intactas y no revelan que existen.

Instalación y configuración inicial

# Debian / Ubuntu / Kali
sudo apt install -y keepassxc

# O desde el repositorio oficial (versión más actualizada)
sudo add-apt-repository ppa:phoerious/keepassxc
sudo apt update && sudo apt install -y keepassxc

# macOS
brew install --cask keepassxc

# Verificar la firma GPG antes de instalar desde el binario oficial
gpg --keyserver keys.openpgp.org --recv-keys CFB4C2166397D0D2
gpg --verify KeePassXC-*.tar.xz.sig KeePassXC-*.tar.xz

Estructura de bases de datos separadas

El esquema de separación depende de tu modelo de amenaza. Una estructura típica para un operador con varias identidades:

# Cada archivo .kdbx es completamente independiente
# con su propia contraseña maestra y opcionalmente su propio keyfile

personal.kdbx        # identidad real: banca, servicios personales, email principal
trabajo.kdbx         # identidad profesional: clientes, herramientas, VPNs de trabajo
operaciones.kdbx     # identidades anónimas: cuentas de alias, infraestructura
infraestructura.kdbx # servidores, VPS, claves SSH, tokens de API

# NUNCA:
# - Una sola base de datos para todo
# - Guardar credenciales de identidad A junto a credenciales de identidad B
# - Sincronizar via Dropbox, Google Drive, iCloud o cualquier nube de terceros

Hardening de KeePassXC

La configuración por defecto de KeePassXC es razonablemente segura, pero hay ajustes que conviene revisar:

## Seguridad
Bloquear automáticamente tras inactividad    → 5 minutos
Bloquear al suspender / bloquear pantalla    → activado
Limpiar portapapeles tras N segundos         → 10 segundos
No recordar archivos recientes               → activado (para identidades sensibles)
Usar cifrado ChaCha20 (alternativa a AES)    → opcional, igual de seguro

## Base de datos → Cifrado
Algoritmo de derivación de clave             → Argon2id (recomendado sobre AES-KDF)
Iteraciones de memoria                       → 64 MB mínimo
Iteraciones de tiempo                        → ajustar para que tarde ~1 segundo al abrir

## Integración
Integración con el navegador (KeePassXC-Browser) → desactivar para bases de datos de identidades anónimas
SSH Agent                                    → útil si almacenas claves SSH aquí

Keyfile: segundo factor sin servidor

KeePassXC permite requerir un archivo adicional (keyfile) además de la contraseña maestra para abrir la base de datos. Sin el keyfile físico, la contraseña sola no es suficiente. Es un segundo factor que no depende de ningún servicio externo.

# Generar un keyfile con datos aleatorios de alta entropía
dd if=/dev/urandom of=mi_keyfile.key bs=64 count=1

# Guardar el keyfile en un USB físico separado de donde vive el .kdbx
# El USB con el keyfile y el .kdbx nunca deben estar juntos
# Si el .kdbx está en el portátil, el keyfile va en el USB
# Si el .kdbx está en el USB, el keyfile va en otro USB diferente

# Hacer backup del keyfile en un lugar diferente al .kdbx
cp mi_keyfile.key /media/backup_usb/
# Perder el keyfile = perder acceso permanente a la base de datos

Sincronización sin nube

Si necesitas acceder a tus bases de datos desde varios dispositivos sin pasar por servicios de terceros, estas son las opciones:

• USB físico: la más simple y segura. Un USB cifrado con LUKS que llevas encima con el .kdbx. Sin red involucrada.
• Syncthing: sincronización peer-to-peer cifrada entre dispositivos en la misma red local o mediante relay sin exponer el archivo a ningún servidor central. Open source, sin cuentas.
• rsync + SSH sobre tu propia infraestructura: copiar el .kdbx a un servidor que controlas tú mediante rsync sobre SSH. El archivo viaja cifrado y el servidor no tiene la contraseña.

VeraCrypt es el sucesor de TrueCrypt — la herramienta de cifrado de disco que sigue siendo el estándar para deniability plausible. Su característica más importante no es el cifrado en sí (que también hace LUKS) sino la posibilidad de crear volúmenes ocultos indetectables dentro de volúmenes normales.

Instalación

# Descargar desde la web oficial y verificar la firma PGP
# https://veracrypt.fr/en/Downloads.html

# Importar la clave GPG de VeraCrypt
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 0x680D16DE

# Verificar la firma antes de instalar
gpg --verify veracrypt-*.tar.bz2.sig veracrypt-*.tar.bz2

# Instalar (Debian/Ubuntu)
sudo dpkg -i veracrypt-*.deb

# Verificar la instalación
veracrypt --version

Crear un volumen cifrado básico

# Crear un contenedor de 500 MB con AES y SHA-512
veracrypt --text --create /ruta/contenedor.vc \
    --size 500M \
    --volume-type normal \
    --encryption AES \
    --hash SHA-512 \
    --filesystem ext4 \
    --pim 0 \
    --keyfiles "" \
    --random-source /dev/urandom
# Pedirá la passphrase dos veces

# Montar el volumen
veracrypt --text /ruta/contenedor.vc /mnt/vc

# Desmontar
veracrypt --text -d /mnt/vc

# Ver volúmenes montados
veracrypt --text -l

Volumen oculto: deniability real

El volumen oculto es la característica que distingue a VeraCrypt. Dentro del espacio libre de un volumen normal existe un segundo volumen completamente independiente. Cuando alguien te obliga a revelar la contraseña, das la del volumen externo — que contiene archivos plausibles e inocuos. Los datos reales están en el volumen oculto, accesible solo con la segunda passphrase.

La propiedad matemática clave: el volumen oculto y el espacio libre del volumen externo son indistinguibles — ambos son datos aleatorios. No hay ninguna firma que revele que existe un volumen oculto.

# PASO 1: Crear el volumen externo (datos señuelo)
# Usar un tamaño grande para que el oculto quepa dentro
veracrypt --text --create /ruta/volumen.vc \
    --size 2G \
    --volume-type normal \
    --encryption AES \
    --hash SHA-512 \
    --filesystem FAT \
    --pim 0 \
    --keyfiles "" \
    --random-source /dev/urandom
# Passphrase: clave del volumen EXTERNO (la que darás bajo coacción)

# PASO 2: Montar el volumen externo en modo de protección del volumen oculto
# Esto es obligatorio para no sobrescribir el volumen oculto al escribir en el externo
veracrypt --text \
    --protect-hidden yes \
    /ruta/volumen.vc /mnt/ext

# PASO 3: Copiar los archivos señuelo al volumen externo
# Deben ser creíbles — documentos reales, fotos, lo que sea plausible
cp -r /ruta/archivos_señuelo/ /mnt/ext/
veracrypt --text -d /mnt/ext

# PASO 4: Crear el volumen oculto dentro del contenedor
veracrypt --text --create /ruta/volumen.vc \
    --size 1G \
    --volume-type hidden \
    --encryption AES \
    --hash SHA-512 \
    --filesystem ext4 \
    --pim 0 \
    --keyfiles "" \
    --random-source /dev/urandom
# Passphrase: clave del volumen OCULTO (la real, diferente a la exterior)

# Montar el volumen oculto (usando la clave oculta)
veracrypt --text /ruta/volumen.vc /mnt/oculto
# VeraCrypt detecta automáticamente qué volumen abrir según la passphrase

Cifrado completo del sistema con VeraCrypt (Windows)

En Windows, VeraCrypt puede cifrar completamente la partición del sistema con un pre-boot password — igual que BitLocker pero con deniability plausible mediante sistema operativo señuelo. La funcionalidad de cifrado de sistema en Linux está cubierta por LUKS (apartado 2.2.2).

Las llaves de seguridad hardware como YubiKey implementan el estándar FIDO2/WebAuthn para autenticación de segundo factor sin contraseñas. El secreto criptográfico nunca sale del dispositivo físico — no puede ser phisheado, no puede ser interceptado, no puede ser copiado remotamente.

El matiz para OPSEC es la vinculación: algunas formas de usar una YubiKey dejan metadatos que relacionan diferentes cuentas o revelan que usas el mismo dispositivo en varios sitios. Entender cómo funciona FIDO2 permite usarlo sin crear esos vínculos.

Cómo funciona FIDO2 internamente

• Generación de claves por dominio: cuando registras la llave en un sitio, el dispositivo genera un par de claves asimétricas específico para ese dominio. La clave privada nunca sale del hardware. El servidor guarda solo la clave pública.
• Challenge-response: al autenticar, el servidor envía un desafío aleatorio. La llave lo firma con la clave privada del dominio. El servidor verifica la firma con la clave pública que registró. Sin secretos transmitidos.
• Vinculación al dominio: las claves son específicas del origen (URL del dominio). Un ataque de phishing con un dominio diferente no puede usar las credenciales — el navegador verifica que el dominio coincide.

El problema de los metadatos en FIDO2

Hay dos mecanismos de FIDO2 con implicaciones de privacidad distintas:

Configurar YubiKey en Linux

# Instalar yubikey-manager y librerías necesarias
sudo apt install -y yubikey-manager libpam-yubico libpam-u2f

# Verificar que el sistema detecta la YubiKey
ykman list
# YubiKey 5 NFC (5.4.3) [OTP+FIDO+CCID] Serial: XXXXXXXX

# Ver información completa del dispositivo
ykman info

# Configurar PIN de FIDO2 (obligatorio para algunas operaciones)
ykman fido access change-pin

# Listar credenciales FIDO2 almacenadas (resident keys)
ykman fido credentials list

# Resetear el módulo FIDO2 (borra todas las credenciales)
ykman fido reset

# Configurar la YubiKey para autenticación PAM (login de Linux)
mkdir -p ~/.config/Yubico
pamu2fcfg > ~/.config/Yubico/u2f_keys
# Pulsa el botón de la YubiKey cuando parpadee

# Para autenticación SSH con la YubiKey como clave de seguridad FIDO2
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_yubikey
# La clave privada generada requiere la presencia física de la YubiKey para usarse
# Si roban el archivo de clave privada, sin la YubiKey física es inútil

YubiKey como segundo factor para SSH

# 1. Generar clave SSH vinculada a la YubiKey
ssh-keygen -t ed25519-sk \
    -O resident \
    -O application=ssh:mi_servidor \
    -f ~/.ssh/id_ed25519_sk
# -O resident: almacenar en la YubiKey (pérdida = pérdida de acceso)
# Sin -O resident: el archivo .pub se genera pero se necesita presencia física

# 2. Copiar la clave pública al servidor
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub usuario@servidor

# 3. Conectar: SSH pedirá que toques la YubiKey
ssh -i ~/.ssh/id_ed25519_sk usuario@servidor
# Aparecerá "Confirm user presence for key..." — tocar el botón

# 4. Verificar que la clave está en la YubiKey (no en disco)
ykman fido credentials list
# Debe aparecer "ssh:mi_servidor"

Shamir's Secret Sharing (SSS) es un algoritmo criptográfico que divide un secreto en N partes de forma que cualquier subconjunto de K partes (con K <= N) permite reconstruir el secreto original, pero cualquier conjunto de K-1 partes o menos no revela absolutamente nada sobre el secreto. No es cifrado — es división matemática del secreto.

La aplicación práctica es inmediata: dividir una clave crítica (la passphrase de tu base de datos de infraestructura, una clave PGP maestra, la semilla de una billetera) entre varias personas o ubicaciones de forma que ninguna persona individual pueda reconstruirla sola, pero un quórum definido pueda hacerlo.

Cómo funciona matemáticamente

Shamir SSS usa interpolación de polinomios sobre un campo finito. Para un esquema K-de-N:

1. Se elige un polinomio de grado K-1 donde el término independiente es el secreto S.
2. Se evalúa el polinomio en N puntos distintos — cada punto es una parte.
3. Con K puntos cualesquiera se puede reconstruir el polinomio por interpolación de Lagrange y obtener S.
4. Con K-1 puntos o menos, hay infinitos polinomios de grado K-1 que pasan por esos puntos — el secreto es matemáticamente inrecuperable.

La propiedad de seguridad información-teórica: con menos de K partes no se filtra ni un bit del secreto. No es seguridad computacional (difícil de romper) sino seguridad perfecta (imposible de romper aunque tengas capacidad computacional infinita).

Implementación con ssss

# Instalar ssss (Shamir's Secret Sharing Scheme)
sudo apt install -y ssss

## DIVIDIR EL SECRETO

# Dividir en 5 partes, requiriendo 3 para reconstruir
# -t: threshold (mínimo necesario para reconstruir)
# -n: número total de partes
# -s: longitud en bits del secreto (128 o 256 para máxima seguridad)
ssss-split -t 3 -n 5 -s 256
# Escribe o pega el secreto y pulsa Enter
# Salida (ejemplo):
# 1-a3f2b1c4d5e6f7a8b9c0d1e2f3a4b5c6
# 2-b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9
# 3-c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0
# 4-d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1
# 5-e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2

## RECONSTRUIR EL SECRETO (con cualquier 3 de las 5 partes)

ssss-combine -t 3
# Introduce las 3 partes una a una (en cualquier orden)
# Enter para confirmar cada una
# Resultado: el secreto original reconstruido

## EJEMPLO PRÁCTICO: dividir la passphrase de una base de datos KeePassXC

echo "mi_passphrase_ultra_secreta_que_no_puedo_perder" | \
    ssss-split -t 2 -n 3 -s 256 -q
# -q: modo silencioso (sin output adicional, solo las partes)
# -s 256: tratar como un secreto de 256 bits de longitud

Casos de uso reales

Un backup digital de una clave privada puede corromperse, ser borrado, quedar inaccessible si el dispositivo falla o ser comprometido si el medio de almacenamiento es interceptado. Los backups físicos — papel, metal, grabado — resuelven el problema de durabilidad y existen fuera del alcance de ataques remotos. El tradeoff es que requieren protección física.

Backup en papel: formato y consideraciones

El papel es barato y universal, pero vulnerable al fuego, agua y deterioro. Para que un backup en papel sea duradero y útil:

• Usa tinta permanente, no bolígrafo: los bolígrafos pueden borrarse, decolorarse o transferirse. Una impresora láser o un rotulador permanente es más duradero.
• Plastifica o lamina: protege contra humedad y deterioro menor. No protege contra fuego.
• Múltiples copias en ubicaciones distintas: casa, caja de seguridad bancaria, familiar de confianza. Nunca todas en el mismo lugar.
• No etiquetes lo que es: un papel con "CLAVE PRIVADA BITCOIN" en la caja de seguridad es un objetivo obvio. El contexto debe ser conocido solo por ti.

# Exportar clave privada PGP a texto para backup en papel
gpg --armor --export-secret-keys tu@email.com > clave_privada.asc

# Imprimir o anotar el contenido de clave_privada.asc
# Es texto base64 — legible, copiable a mano si es necesario

# Herramienta paperkey: extrae solo la parte esencial de una clave OpenPGP
# Reduce drásticamente el texto a imprimir (elimina la clave pública)
sudo apt install -y paperkey

gpg --export-secret-key tu@email.com | \
    paperkey --output-type base16 > clave_paperkey.txt
# Imprime clave_paperkey.txt — mucho más corto que la clave completa

# Para restaurar desde el backup de papel:
paperkey --pubring clave_publica.gpg \
          --secrets clave_paperkey.txt | \
    gpg --import

Formato BIP-39: palabras en lugar de hex

BIP-39 es el estándar de las billeteras de criptomonedas para representar una semilla como una lista de 12 o 24 palabras en inglés. Es mucho más fácil de escribir a mano sin errores que una secuencia hexadecimal, y puede adaptarse para cualquier clave, no solo billeteras.

# Instalar bip39-tool (Node.js)
npm install -g bip39-tool

# Generar una semilla de 24 palabras (256 bits de entropía)
bip39 generate --words 24
# abandon ability able about above absent absorb abstract...
# 24 palabras del wordlist BIP-39 (2048 palabras posibles)

# Convertir un valor hex a palabras BIP-39
bip39 encode "a3f2b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2"

# Recuperar el hex desde las palabras
bip39 decode "abandon ability able about above absent absorb abstract..."

Backup en metal: durabilidad real

El papel no sobrevive a un incendio. El metal sí. Para claves que deben durar décadas o sobrevivir a desastres físicos, el backup en metal es la opción correcta.

Seguridad física del backup

El backup físico resuelve el problema de durabilidad pero crea un problema de acceso físico. Estas son las consideraciones operacionales:

• Nunca en casa exclusivamente: un incendio, un robo o una orden de registro puede comprometer el único backup. Distribuye copias.
• Caja de seguridad bancaria: razonablemente segura contra robo y fuego. Desventaja: el banco puede ver que accedes y en qué circunstancias, y tiene las llaves maestras.
• Cifrado adicional del backup: si alguien encuentra el backup en papel, no debe poder usarlo. Una passphrase adicional que solo tú conoces y que no está en el backup (la memorizas) añade una capa de protección. Shamir + backup físico de las partes es la combinación más robusta.
• Instrucciones para herederos: si el backup existe para recuperación de emergencia y falleces, alguien debe poder reconstruir el acceso. Esto requiere instrucciones separadas del backup mismo.