加密只是增加一点点小小的时间成本而已，反而会给自己处理问题带来不便。

就算加了密，攻击者可以自己写个脚本调用你的加解密方法，把原文跑出来。

我看到的一种做法是将数据库的UserName、DatabaseName、Password全放到该user的环境变量里。

生产环境的密码放在App配置文件中，那它通常也会进入源码版本库[见备注]，这样普通的开发者就能checkout知道密码，但生产环境的密码是不需要让开发者知道的，而且是不应该让刚进入开发的实习生知道的。生产服务器的密码应该由运维人员统一管理。将密码放到环境变量中，开发者只需要一个 get_env("db_password") 这样的代码获取密码。
再回到你所担心问题：「如果有人能进入服务器，看这个配置文件的话，我想，加不加密的也没有多少意义吧？」，所以将密码交给运维人员管理，普通开发者不需要直接登录生产服务器，应用部署更新都是交给运维或者通过rsync发布，登录入口减少了，安全性就有所提高。将不同的应用以不同的用户身份运行，其它用户的环境变量也不会泄漏。

对了，配置文件加密是无助于提高安全性的。能得到配置文件通常意味着也能得到项目的源码[见备注]，能得到源码也就能得到解密方式。更何况，DB服务器一般应该配置了iptables限制访问来源，密码只是整个安全环节中的一小点而已。

备注：

1. App的配置文件是应该受版本管理的
2. 在我看来一般的App部署环境没有复杂多变到某种程度，不将密码放到配置文件中，也就没必要为配置文件单独开设一个版本库，和源码同一个repo更省事；我自己的做法是将真正使用的 settings.ini 放到 gitignore 中，而在部署时执行一次 cp settings_for_product.ini settings.ini 。事实上如果目标环境并不多的话，我的做法是在源码版本库里存放多个版本的 settings_for_A_cloud.ini 、 settings_for_B_cloud.ini ，只是部署脚本中，不同目标环境，cp参数有所不同。