通常情况下，我们将类似数据库连接类的信息保存在配置文件中，java里面喜欢用properties文件，以前没有考虑过，将文件中的密码加密，现在领导要求必须加密，那么，有没有必要对密码进行加密？如果有人能进入服务器，看这个配置文件的话，我想，加不加密的也没有多少意义吧？
加密只是增加一点点小小的时间成本而已，反而会给自己处理问题带来不便。
我看到的一种做法是将数据库的UserName、DatabaseName、Password全放到该user的环境变量里。
生产环境的密码放在App配置文件中，那它通常也会进入源码版本库[见备注]，这样普通的开发者就能checkout知道密码，但生产环境的密码是不需要让开发者知道的，而且是不应该让刚进入开发的实习生知道的。生产服务器的密码应该由运维人员统一管理。将密码放到环境变量中，开发者只需要一个get_env("db_password")这样的代码获取密码。
再回到你所担心问题：「如果有人能进入服务器，看这个配置文件的话，我想，加不加密的也没有多少意义吧？」，所以将密码交给运维人员管理，普通开发者不需要直接登录生产服务器，应用部署更新都是交给运维或者通过rsync发布，登录入口减少了，安全性就有所提高。将不同的应用以不同的用户身份运行，其它用户的环境变量也不会泄漏。
对了，配置文件加密是无助于提高安全性的。能得到配置文件通常意味着也能得到项目的源码[见备注]，能得到源码也就能得到解密方式。更何况，DB服务器一般应该配置了iptables限制访问来源，密码只是整个安全环节中的一小点而已。
备注：
- App的配置文件是应该受版本管理的
- 在我看来一般的App部署环境没有复杂多变到某种程度，不将密码放到配置文件中，也就没必要为配置文件单独开设一个版本库，和源码同一个repo更省事；我自己的做法是将真正使用的
settings.ini放到gitignore中，而在部署时执行一次cp settings_for_product.ini settings.ini。事实上如果目标环境并不多的话，我的做法是在源码版本库里存放多个版本的settings_for_A_cloud.ini、settings_for_B_cloud.ini，只是部署脚本中，不同目标环境，cp参数有所不同。
就算加了密，攻击者可以自己写个脚本调用你的加解密方法，把原文跑出来。