当前位置:Gxlcms > PHP教程 > 配置文件中的密码有没有必要加密?

配置文件中的密码有没有必要加密?

时间:2021-07-01 10:21:17 帮助过:92人阅读

通常情况下,我们将类似数据库连接类的信息保存在配置文件中,java里面喜欢用properties文件,以前没有考虑过,将文件中的密码加密,现在领导要求必须加密,那么,有没有必要对密码进行加密?如果有人能进入服务器,看这个配置文件的话,我想,加不加密的也没有多少意义吧?

回复内容:

通常情况下,我们将类似数据库连接类的信息保存在配置文件中,java里面喜欢用properties文件,以前没有考虑过,将文件中的密码加密,现在领导要求必须加密,那么,有没有必要对密码进行加密?如果有人能进入服务器,看这个配置文件的话,我想,加不加密的也没有多少意义吧?

我看到的一种做法是将数据库的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.inisettings_for_B_cloud.ini,只是部署脚本中,不同目标环境,cp参数有所不同。

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

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

人气教程排行