老旧Java项目中如何加密属性文件里的JDBC用户名与密码？

先说说你的思路：这种“明文存属性文件，代码编码后匹配数据库密码”的方式，确实能绕开直接存真实密码的问题，但缺点也很突出——多应用共用账号的情况下，全量切换风险太高，逐个迁移又要维护两套逻辑，后续容易出乱子。

给你几个更适配当前环境的方案，从应急到长期重构都有：

优先用WebSphere自带加密（零迁移成本） #

WebSphere本身就有密码加密工具，完全不用自己造轮子：

• 用WebSphere提供的PropFilePasswordEncoder命令行工具，直接加密属性文件里的密码，加密后的内容会带{xor}或{encrypt}前缀
• 代码不用改任何加密逻辑，WebSphere在加载应用时会自动解密，你直接拿解密后的密码连数据库就行
• 好处是不用动现有数据库账号，多应用继续共用，完全没迁移成本，而且官方工具比自己写的加密逻辑靠谱多了

长期方案：拆分数据库账号（更安全） #

如果想彻底解决多应用共用账号的风险，建议分阶段拆：

• 给每个应用单独建数据库账号，权限按最小必要原则配置（比如只读、只能操作自己的表）
• 每个新账号的密码用上面说的WebSphere工具加密，更新对应应用的属性文件
• 逐个应用切换，验证没问题后再停掉原共用账号
• 这么做能降低单账号泄露的影响范围，也符合现代安全规范，后续维护也更清晰

彻底消除属性文件存密码：用WebSphere JNDI数据源 #

如果重构的步子可以大一点，直接把数据库连接信息移到WebSphere控制台：

• 在WebSphere里配置数据源，绑定一个JNDI名称，密码直接存在WebSphere的安全存储里
• 代码里通过InitialContext lookup获取数据源，完全不用在属性文件里碰密码
• 这是最安全的方式，彻底消除了属性文件存密码的风险，也是WebSphere推荐的做法

临时优化你的原有思路 #

如果暂时不想动WebSphere配置，也可以优化你的方案：

• 别用简单编码，换成加盐哈希（比如SHA-256加盐），盐值单独存在一个只有运维能访问的文件里（和应用属性文件分开）
• 数据库密码设为哈希后的结果，代码里读明文密码+盐，哈希后再连数据库
• 就算属性文件泄露，没有盐值也生成不了正确的数据库密码，安全性比单纯编码高很多

内容的提问来源于stack exchange，提问作者ResourceReaper