通过数据库修改后台密码
上周三凌晨两点,通过台密朋友发来一条微信:“后台进不去了,数据密码被人改了。库修”他运营的改后是一个本地生活类小程序,日活不高,通过台密但后台绑着几千条商户信息和订单记录。数据我问他最近有没有点过什么奇怪的库修链接,他说没有,改后就是通过台密前一天把后台账号给了一个兼职运营。问题大概率出在这里。数据 很多人遇到后台密码被改,库修第一反应是改后找客服申诉。但如果你有数据库权限,通过台密这事其实可以在五分钟内自己解决。数据前提是库修你得知道密码存在哪张表、哪个字段,以及它是怎么被加密的。 大部分后台系统不会把明文密码直接写进数据库。常见的做法是存哈希值,比如MD5、SHA1,或者加了盐的bcrypt。你打开数据库,找到用户表,看到password字段里是一串32位或64位的乱码,基本就是哈希。这时候你没法“查看”原密码,只能替换。 替换的思路很简单:自己生成一个新密码的哈希值,然后UPDATE进去。以MD5为例,你可以在本地终端跑一行命令: 执行完刷新后台登录页,用新密码就能进去了。整个过程不需要重启服务,也不需要改配置文件。 我帮朋友处理的时候,发现他的系统用的是bcrypt。bcrypt每次生成的盐不一样,你没法直接拿一个固定的哈希去替换。这时候有两个办法:一是用系统自带的注册功能重新注册一个管理员账号,把新账号的密码哈希复制到旧账号上;二是写一段脚本,用系统相同的加密逻辑生成哈希。 我选了第一种。注册一个新用户,从数据库里查出它的password字段值,然后UPDATE到原来的admin账号上。登录成功后再把新注册的账号删掉。这个方法笨,但稳,不需要去翻代码里的加密逻辑。 还有个坑:有些系统除了password字段,还有salt字段单独存盐。你只改password不改salt,照样登不进去。所以动手之前,先把用户表的结构看清楚,别急着执行UPDATE。 密码改回来只是第一步。我让朋友查了数据库的binlog,发现那个兼职运营的账号在凌晨一点多执行了一次UPDATE,把admin的密码改了,还顺手加了一个自己的账号。更麻烦的是,他通过后台的导出功能下载了一份商户联系方式。 所以改完密码之后,至少要做三件事:删掉陌生账号、检查最近的操作日志、确认数据库账号的权限有没有被扩大。朋友那个系统用的是root连数据库,这意味着任何拿到后台权限的人都能直接操作所有表。后来我帮他把数据库连接账号换成了一个只有增删改查权限的普通用户。 另外,如果系统支持,把登录方式改成手机号加验证码,或者接入第三方登录。密码这东西,只要还在用,就永远有被改的风险。 说到底,通过数据库改密码是个应急手段,不是日常操作。它能帮你快速拿回控制权,但拿回来之后你得想想,为什么别人能改掉你的密码。是账号共享了,还是系统本身有漏洞,还是数据库权限给太大了。这些问题不解决,下次可能就不只是改密码这么简单了。先搞清楚密码是怎么存的
echo -n "newpassword123" | md5sum,得到一串哈希。然后进数据库执行:UPDATE admin_user SET password = '生成的哈希值' WHERE username = 'admin';但事情没这么简单
改完之后要做什么