credentials-config.json中"configuration/password"字段存储的是AES-128-CBC加密后Base64编码的数据，密钥为babb4a9f774ab853c96c2d653dfe544a、IV为16个0x00字节，且默认加salt需跳过前16字节解密。
credentials-config.json 里存的是 AES-128-CBC 加密的 Base64 数据
你打开 credentials-config.json 文件，看到的 "configuration/password" 字段值是一串 Base64 字符（比如 U2FsdGVkX1+...），这不是明文，也不是任意加密格式——它明确是 AES-128-CBC 加密后、再 Base64 编码的结果。
关键依据来自 DBeaver 源码硬编码：ENCRYPTION_KEY 固定为 babb4a9f774ab853c96c2d653dfe544a，ENCRYPTION_IV 固定为 16 个 0x00 字节（即 00000000000000000000000000000000）。这决定了它**不是 AES-256、不是 GCM 模式、不带盐、不依赖系统密钥环**。
- 如果你在 macOS 或 Linux 上用 keyring 解密失败，大概率是因为你启用了“主密码（Master Password）”功能——此时密码实际由主密码派生密钥加密，而非固定密钥
- Windows 用户若启用了“使用 Windows 凭据管理器”，那
credentials-config.json里可能根本没存密码，而是只存了个凭据 ID，真实解密必须走系统 API - OpenSSL 命令能成功，仅说明当前连接未启用主密码或系统密钥环保护
怎么确认自己用的是固定密钥还是主密码加密？
打开 DBeaver 首选项 → General → Credentials，看两个关键开关：
- 如果勾选了
Use master password for credentials encryption：那你面对的就是 PBKDF2 + AES-256-CBC（主密码派生），openssl aes-128-cbc -K ...命令会直接失败，输出乱码或报错bad decrypt - 如果勾选了
Store passwords in plain text（不推荐）：那credentials-config.json里就是明文，但字段名可能变成"password"而非"configuration/password" - 如果两者都没勾选，且你从没设过主密码：那就一定是固定密钥 AES-128-CBC，可直接用 OpenSSL 解
openssl 解密命令里 skip=16 是跳什么？
OpenSSL 默认加 salt 头部，即使你指定了 -K 和 -iv，它仍会在输出开头塞入 8 字节 salt 标识 + 8 字节随机 salt（共 16 字节）。不跳过，JSON 解析就会失败——你会看到类似 Salted__\x9e\x0f... 开头的乱码。
-
dd bs=1 skip=16就是砍掉前 16 字节，留下纯加密 payload - 如果跳太多（比如
skip=20），会截断有效数据，导致 JSON 格式错误或解密失败 - 某些旧版 OpenSSL（如 1.0.x）可能不加 salt，此时
skip=0反而正确；但 DBeaver 6.1.3+ 默认适配的是加 salt 行为
为什么有时解出来是空或乱码？
最常见三个原因：
- 你解的是
connections.json或data-sources.json——这些文件只存连接元信息，密码字段是占位符{encrypted}，真密文全在credentials-config.json - 路径错了：Windows 下可能是
C:\Users\，而不是安装目录下的\AppData\Roaming\DBeaverData\workspace6\General\.dbeaver\credentials-config.json .dbeaver - 文件被修改过：比如手动编辑过 JSON、保存时编码变为了 UTF-16、或被 Git 自动换行（CRLF → LF）破坏了 Base64 对齐，导致解密后无法解析 JSON
固定密钥 AES-128-CBC 这套机制本身没有“认证方式切换”概念——它不涉及数据库端的 sha256、SCRAM 或 Kerberos。DBeaver 的加密只是本地存储保护，和数据库连接时用什么认证协议完全无关。
