DBeaver连接配置本身不泄露，但credentials-config.json文件配合固定密钥可本地解密，一旦该文件被导出或误传（如纳入Git、网盘同步），密码即等同裸奔；其路径固定为工作空间/.dbeaver/credentials-config.json，且因密钥（babb4a9f774ab853c96c2d653dfe544a）和IV（全零）硬编码，可用OpenSSL直接解密Base64密文。
直接说结论：DBeaver 的连接配置本身不泄露，但 credentials-config.json 文件 + 固定密钥 = 本地可解密，只要能访问你工作空间目录，密码就等于裸奔。
怎么看 credentials-config.json 是否已被导出或误传
这个文件是 DBeaver 存储加密后账号密码的唯一位置，路径固定为：工作空间/.dbeaver/credentials-config.json。它不像连接配置（connections.xml）会随项目共享，但很多人在备份、同步或提交配置时顺手把整个 .dbeaver 目录拖进 Git 或网盘，就埋下风险。
- 检查你是否在版本控制中意外提交过
.dbeaver/目录（尤其注意.gitignore里有没有写.dbeaver/**） - 搜索团队共享目录、NAS 或协作平台中是否存在
credentials-config.json文件名 - 用命令快速定位（Windows）：
dir /s /b credentials-config.json；macOS/Linux：find ~ -name "credentials-config.json" 2>/dev/null
为什么 openssl 解密命令能直接拿到明文密码
因为 DBeaver 硬编码了 AES-128-CBC 的密钥和全零 IV：
- 密钥固定为：
"babb4a9f774ab853c96c2d653dfe544a" - IV 固定为：
"00000000000000000000000000000000" - 这意味着只要拿到
credentials-config.json里的cipher字段值（Base64 编码的密文），就能用标准 OpenSSL 命令还原 - 典型解密命令：
openssl enc -aes-128-cbc -d -K babb4a9f774ab853c96c2d653dfe544a -iv 00000000000000000000000000000000 -base64 -in cipher.b64
哪些连接参数会放大泄露后的危害
即使密码被解出来，真正决定风险等级的是连接本身是否具备高危能力。重点检查以下几项是否被无意开启：
-
allowPublicKeyRetrieval=true（MySQL）：配合弱密码，可能被用于公钥注入攻击 -
autoReconnect=true+failOverReadOnly=false：故障时自动重连并保持写权限，扩大误操作范围 - 未启用 SSL 的公网连接（如
useSSL=false或缺失requireSSL=true）：密码和 SQL 内容全程明文传输 - 使用 root/admin 等超级账号连接生产库：密码一旦泄露，等于交出整套数据库控制权
真正该关掉的不是“记住密码”，而是“记住高危组合”
DBeaver 默认勾选“保存密码”不是 bug，是设计选择；问题出在用户习惯性把开发、测试、生产环境全用同一套高权限账号，还开着 SSL 关闭、自动重连、远程 root 登录等配置。安全检查的终点不是删掉 credentials-config.json，而是确认：
- 每个连接只用最小必要权限账号（比如只读账号查报表，不用 DBA 账号）
- 所有公网连接强制启用 SSL，并校验服务器证书（
verifyServerCertificate=true） - 生产环境连接从不保存密码，改用 SSH 隧道或操作系统凭证代理（如 Windows 的 SSPI）
- 工作空间目录不纳入任何自动同步工具（Dropbox、iCloud、OneDrive）
最容易被忽略的一点：DBeaver 启动时如果工作空间路径含中文或空格，某些驱动加载失败会导致连接降级到不加密模式，而界面不会报错——你看到“已连接”，其实走的是明文 TCP。
