Gestores de contraseñas para desarrolladores: Bitwarden CLI vs 1Password CLI vs pass vs gopass 2026

Tabla de contenidos

• Por qué el CLI es esencial para desarrolladores
• Bitwarden CLI en profundidad
• 1Password CLI en profundidad
• pass en profundidad
• gopass en profundidad
• Matriz comparativa: 4 herramientas × 12 criterios
• Recomendaciones por perfil

Por qué el CLI es esencial para desarrolladores

Un gestor de contraseñas con interfaz gráfica es una capa de comodidad. Un gestor por línea de comandos es infraestructura. La diferencia se hace evidente en el momento en que necesitas un secreto dentro de un script de shell, un pipeline CI/CD, un build de Docker, un init container de Kubernetes, o un cron job que se ejecuta a las 3 AM sin ningún usuario conectado en toda la cadena.

Cuatro flujos de trabajo exponen este problema de forma recurrente.

Scripting y automatización. Scripts de shell que llaman a APIs autenticadas, migraciones de base de datos, scripts de despliegue que renuevan certificados TLS — todos necesitan credenciales en tiempo de ejecución. El patrón de codificar un secreto en duro en un script o archivo de entorno sigue siendo cómo la mayoría de los equipos comienzan, y también cómo la mayoría sufre su primera brecha. Un gestor CLI rompe ese patrón limpiamente: la credencial vive en el vault y se recupera, usa y descarta en una sola invocación de comando.

Rotación de secretos. Los marcos de cumplimiento (SOC 2, ISO 27001, controles operacionales RGPD) requieren cada vez más la rotación de credenciales en un calendario fijo — claves API a 90 días, contraseñas de base de datos a 30 días en algunos entornos. Hacer esto manualmente es lento y propenso a errores. Una herramienta CLI conectada a un script de rotación lo convierte en algo mecánico: recuperar el secreto antiguo, llamar a la API del servicio para rotar, escribir el nuevo secreto en el vault, actualizar los consumidores posteriores mediante inyección de variables de entorno.

Inyección de secretos CI/CD. El patrón que se ha vuelto estándar en 2026: ningún secreto en la configuración de variables de entorno de tu dashboard de CI. En su lugar, un token de sesión de corta duración autentica el pipeline al vault, los secretos se obtienen al inicio del job, se inyectan en el entorno del subproceso, y la sesión expira. Esto es lo que habilitan bw run, op run y el renderizado de templates de gopass.

Gestión de claves SSH. Las claves privadas SSH son credenciales. Almacenarlas como archivos en texto plano en las máquinas de los desarrolladores es equivalente a una contraseña en texto claro. Las cuatro herramientas de esta comparativa pueden actuar como almacén cifrado para claves SSH; dos de ellas exponen un socket de agente SSH nativo que gestiona las operaciones de firma sin colocar nunca la clave descifrada en disco.

Las cuatro herramientas se dividen en dos categorías. Bitwarden CLI y 1Password CLI son frontends a servicios de vault sincronizados en la nube con infraestructura comercial detrás. pass y gopass son herramientas local-first construidas sobre cifrado GnuPG y sincronización git, sin componente cloud obligatorio. Las compensaciones entre esos dos modelos — simplicidad operacional versus modelo de confianza — son el eje alrededor del cual giran la mayoría de las decisiones de equipo.

Bitwarden CLI en profundidad

Bitwarden es un gestor de contraseñas de código abierto con un servidor auto-alojable (Vaultwarden es el fork comunitario, el servidor oficial de Bitwarden también es de código abierto). La CLI, bw, es un binario Node.js distribuido como ejecutable único para Linux, macOS y Windows.

Autenticación y desbloqueo del vault. Existen dos rutas de autenticación. El inicio de sesión interactivo con bw login solicita email, contraseña maestra y token 2FA. El inicio de sesión con clave API mediante bw login --apikey usa las variables de entorno BW_CLIENTID y BW_CLIENTSECRET — esta es la ruta correcta para pipelines CI/CD. Tras la autenticación, el desbloqueo del vault es un paso separado: bw unlock con BW_PASSWORD configurado devuelve un token de sesión. Almacenar el token de sesión en BW_SESSION durante la duración del job.

export BW_SESSION=$(bw unlock --passwordenv BW_PASSWORD --raw)
bw get password "production/postgres"

El token de sesión es una clave AES-256 local que descifra el blob cifrado del vault en caché. Tiene una vida corta por defecto (15 minutos de inactividad) y no sale de la máquina.

Modelo de sincronización. El vault se almacena localmente como blob cifrado tras bw sync. En entornos CI, ejecuta siempre bw sync al inicio de un job para garantizar que el caché local coincide con el servidor. La sincronización es un pull completo: no hay sincronización parcial disponible, lo que significa que la operación es O(tamaño del vault). Para vaults de menos de 10.000 elementos, la latencia de sync es inferior a 2 segundos.

Especificación de cifrado. Bitwarden cifra los datos del vault con AES-256-CBC con un IV aleatorio por campo. La clave del vault se deriva de la contraseña maestra usando Argon2id (64 MB de memoria, 3 iteraciones, 4 threads). La clave extendida nunca sale del cliente. Todas las operaciones criptográficas ocurren localmente; el servidor almacena solo el texto cifrado. El código fuente de cliente y servidor está en GitHub y ha sido auditado por terceros — la más reciente por Cure53 publicada en marzo de 2025.

Patrones de variables de entorno. Para secretos de aplicación, Bitwarden soporta cargar credenciales directamente en entornos de subprocesos:

bw get notes "app/env-vars" | source /dev/stdin
# o usando bw run:
bw run -- ./mi-script.sh

El comando bw run no es tan completo como op run todavía, pero cubre los casos más comunes.

Precios. Gratuito: contraseñas ilimitadas, sin compartir elementos, sin recuperación 2FA, sin TOTP. Plan individual: $10/año — añade soporte TOTP, adjuntos cifrados, acceso de emergencia. Plan Teams: $4/usuario/mes — añade vaults de organización compartidos, gestión de grupos, consola de administración, registros de eventos, acceso a API. La opción auto-alojada está disponible en todos los planes de pago sin coste adicional.

1Password CLI en profundidad

1Password es un gestor de contraseñas comercial de código cerrado. La CLI, op, es un binario Go distribuido a través de los repositorios de paquetes de 1Password y Homebrew. Es el más completo de las cuatro herramientas desde una perspectiva de CI/CD y workflows de desarrollador.

Autenticación y cuentas de servicio. 1Password CLI 2.x introdujo las cuentas de servicio específicamente para uso no interactivo. Una cuenta de servicio tiene un token (OP_SERVICE_ACCOUNT_TOKEN) que concede acceso de lectura o lectura-escritura a vaults específicos. No hay contraseña maestra en el bucle. Este es el modelo correcto para pipelines CI/CD, secretos compartidos en contenedores, y cualquier sistema automatizado que necesite acceso de larga duración a credenciales.

export OP_SERVICE_ACCOUNT_TOKEN="ops_..."
op read "op://DevVault/postgres/password"

Integración SSH agent. Esta es la funcionalidad que distingue a 1Password de las otras tres herramientas para workflows individuales de desarrollador. La app 1Password expone un socket de agente SSH (/tmp/1password-ssh-agent.sock). Añade IdentityAgent a tu ~/.ssh/config y tus claves SSH son firmadas por el agente sin que la clave privada toque nunca el sistema de archivos en texto plano. Combinado con el desbloqueo biométrico (Touch ID en macOS, Windows Hello), este es el workflow de claves SSH más ergonómico disponible hoy.

Integraciones para desarrolladores. 1Password CLI tiene integraciones de primera clase con varias herramientas de desarrollo:

• op run inyecta secretos desde archivos template .env con sintaxis op://vault/item/field. No se escribe ningún secreto en texto plano en disco.
• Firma de commits Git via la integración SSH agent: op firma commits con una clave SSH almacenada en el vault.
• Provider de Terraform: el provider 1password/onepassword lee y escribe secretos desde planes de Terraform.
• Inyección de secretos Kubernetes: op inject renderiza manifests Secret de Kubernetes con referencias al vault resueltas en tiempo de despliegue.

Especificación de cifrado. 1Password usa AES-256-GCM para datos del vault, con claves protegidas por el modelo de doble clave Secret Key + Contraseña maestra. La clave secreta (128 bits de entropía aleatoria generada al crear la cuenta) se almacena solo en los dispositivos del usuario, nunca en los servidores de 1Password. La derivación de clave usa PBKDF2-SHA256 (650.000 iteraciones para el componente de contraseña maestra). El modelo combinado significa que una brecha del servidor solo no puede descifrar ningún dato del vault.

Precios. Individual: $36/año ($2,99/mes) — contraseñas ilimitadas, 1 GB de almacenamiento de documentos, Travel Mode. Teams Starter: $19,95/mes para hasta 10 usuarios — cuentas de invitados, vaults compartidos, permisos granulares. Business: $8/usuario/mes — RBAC avanzado, roles personalizados, integración Splunk/SIEM, API de registros de auditoría. Enterprise: precio personalizado — aprovisionamiento SSO/SCIM, revisiones de seguridad personalizadas, soporte dedicado. Sin nivel gratuito. Sin opción de auto-alojamiento.

pass en profundidad

pass es el Gestor de Contraseñas Unix Estándar. Creado por Jason Donenfeld (también autor de WireGuard), es un script Bash — el programa completo, incluyendo sincronización, generación y edición, tiene menos de 600 líneas de shell. La filosofía de diseño es explícita: un archivo de texto por secreto, cifrado con GPG, almacenado en un árbol de directorios, sincronizado via git.

Mecánica básica. El almacén de contraseñas vive en ~/.password-store por defecto. Cada entrada es un archivo .gpg cuyo texto en claro es típicamente una contraseña en la primera línea seguida de metadatos (URL, nombre de usuario, notas) en líneas posteriores. La convención es respetada por todos los clientes compatibles con pass.

~/.password-store/
  production/
    postgres.gpg        # contraseña línea 1, notas abajo
    api-key-stripe.gpg
  personal/
    email.gpg

Cifrar un nuevo secreto:

pass insert production/redis-password
# o multilínea:
pass insert --multiline production/postgres

Leer:

pass production/postgres            # muestra en stdout
pass -c production/postgres         # copia al portapapeles, borra en 45s

Modelo GPG. Cada archivo .gpg está cifrado para uno o más IDs de llave GPG pública especificados en archivos .gpg-id a nivel de directorio. Así funciona el acceso multi-destinatario: añade las huellas de llave de los miembros del equipo a .gpg-id, luego re-cifra con pass init --reencrypt. Cada secreto en el subárbol se re-cifra para todas las llaves listadas.

El modelo de seguridad es tan transparente como es posible: confías en GnuPG, en tu propia gestión de claves, y en el proveedor de alojamiento git. Sin middleware, sin binario propietario, sin flujo de autenticación cloud. El modelo de amenaza es proporcionalmente simple de razonar.

Sincronización git. pass git proxifica comandos git directamente. pass git push, pass git pull. El historial git almacena cada cambio con un mensaje de commit que intencionalmente revela solo el tipo de operación (añadir, editar, borrar) y la ruta de la entrada — el contenido permanece cifrado. Para equipos, un repositorio bare compartido en un host git privado es la configuración estándar.

Ecosistema. pass tiene un amplio ecosistema:

• passff / browserpass: extensiones de navegador para Firefox y Chrome.
• Android Password Store (ahora OpenKeychain + APS): cliente Android compatible.
• QtPass: GUI multiplataforma.
• pass-otp: plugin para códigos TOTP — pass otp production/totp-key.

Limitaciones. La filosofía Unix tiene sus contrapartidas. No hay interfaz de gestión de equipo, ni registros de acceso, ni detección de brechas, ni help desk. La gestión de claves GPG a escala es genuinamente dolorosa: cuando un miembro del equipo se va, eliminas su clave del .gpg-id y re-cifras cada secreto al que tenía acceso. Para un equipo de 20 personas, esto puede tomar varios minutos. gopass aborda la mayoría de estos puntos de fricción.

Precio. Gratuito. Licencia MIT.

gopass en profundidad

gopass es pass, reescrito en Go, con secretos estructurados, comandos de equipo y un backend enchufable. Creado por ingenieros de Codecentric, está activamente mantenido en 2026. El binario principal, gopass, es un reemplazo directo de pass — lee y escribe el mismo formato de almacén — añadiendo capacidades que faltan en pass a escala.

Secretos estructurados. Donde pass almacena un blob de texto por entrada, gopass soporta un formato clave-valor tipo YAML dentro del archivo cifrado:

gopass insert --multiline production/postgres
# texto en claro dentro del .gpg:
---
password: hunter2
username: postgres
host: db.prod.example.com
port: 5432

Los campos son entonces accesibles individualmente:

gopass show production/postgres password   # solo la contraseña
gopass show production/postgres host       # solo el host

Esto es significativo para CI/CD: los campos individuales pueden inyectarse en variables de entorno sin parsear salida multilínea.

Mounts. gopass soporta múltiples almacenes de contraseñas ("mounts") accesibles bajo prefijos de espacio de nombres:

gopass mounts add work   git@github.com:miempresa/passwords.git
gopass mounts add home   ~/.personal-pass

Los secretos viven en work/production/postgres o home/personal/email. Cada mount es un repositorio git separado con su propio .gpg-id. Este es el modelo correcto para un desarrollador que tiene un vault de trabajo y uno personal que nunca deben mezclarse.

Workflows de equipo. gopass tiene comandos de gestión de equipo de primera clase:

• gopass recipients add --store work "colega@ejemplo.com" — añade la llave GPG de un destinatario desde tu llavero, luego re-cifra solo el mount afectado.
• gopass recipients rm --store work "excolega@ejemplo.com" — elimina una llave y re-cifra.
• gopass audit — verifica contraseñas débiles y entradas duplicadas en todos los mounts.

Soporte de cifrado age. Desde la versión 1.14, gopass soporta age (una herramienta de cifrado moderna de Filippo Valsorda) como alternativa a GPG. age tiene un formato de clave más simple (claves X25519, claves SSH, o claves derivadas de passphrase), sin dependencia de servidor de claves, y una base de código más auditable. Para nuevos almacenes, age es recomendado sobre GPG si el equipo no tiene infraestructura GPG existente.

gopass init --crypto age

Renderizado de templates. gopass tiene un subcomando gopass env que resuelve referencias de secretos en un template de entorno:

DATABASE_URL=postgres://{{ gopass "production/postgres/username" }}:{{ gopass "production/postgres/password" }}@{{ gopass "production/postgres/host" }}:5432/mydb

No tan pulido como op run, pero funcional para la mayoría de casos de pipeline.

Precio. Gratuito. Licencia MIT.

Matriz comparativa: 4 herramientas × 12 criterios

Notas de cifrado. AES-256-GCM (1Password) proporciona cifrado autenticado de forma nativa, mientras que AES-256-CBC (Bitwarden) requiere un MAC separado. En la práctica, ambas implementaciones son sólidas. La ruta GnuPG para pass y gopass tiene una mayor superficie de ataque en términos de complejidad de biblioteca, pero el código ha sido auditado extensamente. age es la opción más limpia desde el punto de vista del diseño criptográfico: intercambio de claves X25519, cifrado de payload ChaCha20-Poly1305, sin trampa de agilidad algorítmica.

Notas de sincronización. Las herramientas sincronizadas en la nube (Bitwarden, 1Password) son más sencillas de operar: instalar, autenticar, listo. Las herramientas basadas en git requieren alojar un repositorio, gestionar la disciplina de clone/push/pull, y manejar conflictos de merge si dos miembros del equipo editan simultáneamente. La ventaja es que no tienen dependencia cloud obligatoria — el vault puede vivir completamente en infraestructura que controlas.

Recomendaciones por perfil

Desarrollador independiente (solo, sin equipo). Usa Bitwarden CLI en una cuenta gratuita para todo lo que no requiera integración de SSH agent, y 1Password si quieres gestión de claves SSH de forma inmediata. Para el desarrollador solo muy consciente de la privacidad que quiere cero dependencia cloud: gopass con cifrado age en un repositorio git privado que alojes tú mismo. La curva de aprendizaje es real pero el modelo de confianza es el más limpio disponible.

Equipo de 5 a 20 desarrolladores. Empieza con 1Password Teams si el presupuesto lo permite — la integración SSH agent, op run para CI/CD, cuentas de servicio para pipelines, y el registro de auditoría cubren el 95% de lo que un equipo de este tamaño necesita, con una sobrecarga operacional mínima. Si el presupuesto es una restricción o el auto-alojamiento es un requisito absoluto, Bitwarden Teams ($4/usuario/mes, auto-alojable via Vaultwarden) es la elección correcta. Evita pass o gopass a esta escala a menos que el equipo tenga experiencia dedicada en gestión de claves GPG.

Enterprise (100+ desarrolladores). 1Password Business o Bitwarden Enterprise (auto-alojado). Los factores diferenciadores son el aprovisionamiento SSO/SCIM (1Password tiene OIDC y SAML; Bitwarden tiene conector de directorio SCIM), la exportación del registro de auditoría a SIEM (ambos lo soportan en el nivel superior), y los informes de cumplimiento. El nivel enterprise de 1Password incluye políticas de protección avanzadas y revisiones de seguridad bajo demanda. La ruta auto-alojada de Bitwarden es preferida por organizaciones que no pueden tolerar una dependencia cloud para material de claves.

Power user paranoico / especialista en rotación de secretos. gopass con age en un repositorio git privado, llave maestra GPG en un dispositivo air-gapped o Yubikey, operaciones diarias firmadas con una subclave. Para la rotación de secretos, construye un script que llame a gopass show <secreto>, impacte la API del servicio para rotar, y llame a gopass insert <secreto> con el nuevo valor. Todo el pipeline corre localmente sin llamada cloud excepto al servicio objetivo. Añade gopass audit a tu cron semanal para detectar secretos débiles o duplicados antes de que se conviertan en un problema de cumplimiento.

Para una lectura fundamental sobre el modelo de amenaza más amplio que hace crítica la gestión de secretos, consulta nuestro pillar estado de la privacidad de los navegadores 2026. Para una referencia sobre el endurecimiento de la capa OS, nuestro análisis del modo Lockdown cubre cómo la superficie de ataque a nivel OS interactúa con los almacenes de credenciales a nivel de aplicación.

Cualquiera que sea la herramienta elegida, la línea de base innegociable es esta: ninguna credencial en texto plano toca un repositorio, un archivo de log, o un dashboard de variables de entorno. Un gestor de contraseñas CLI es el mecanismo que hace mantenible esa línea de base a la velocidad de ingeniería.