已知明文密码与对应数据库存储密文，如何推导所用的密码哈希/转换算法？

先做初筛，靠密文特征快速排除不可能的方案 #

先把对照样本列清楚：

• 已知明文：k4oK203$
• 数据库存储的加密值：6xqmRr0QNUrc0uvwGchWqA==

先观察存储值的固有特征：

• 这个值末尾带两个=填充符，是Base64编码的典型标识。直接对存储值做Base64解码，能得到16字节的二进制内容。
• 靠这个解码后的长度，直接筛掉长度对不上的方案：
  • SHA1的原始二进制输出是20字节，转成Base64后是28字符，和现在24字符的存储值长度不符，直接排除
  • SHA256的原始二进制输出是32字节，转成Base64后是44字符，和当前长度差很多，直接排除
  • bcrypt、PBKDF2这类带迭代的密码哈希输出长度通常更长，也可以初步排除。

缩小范围后逐类匹配，用已知明文做校验 #

解码后得到16字节二进制，剩下需要验证的常见转换方式只有三类：

• 纯Base64编码（没有前置的哈希或加密）：直接把明文k4oK203$做Base64编码，看结果是不是和数据库值一致。按长度算，8字节的明文转Base64是12字符，和当前24字符的存储值长度对不上，基本可以快速排除。
• 无盐单轮哈希后转Base64：16字节的二进制长度刚好和MD5哈希的原始输出长度一致。验证方法：对明文k4oK203$计算MD5的16字节原始二进制值，再把这个二进制值转成Base64，和数据库里的存储值逐字符比对，如果完全匹配，说明转换规则就是「明文计算MD5哈希→对哈希值做Base64编码后存储」。
• 对称加密后转Base64：16字节长度也匹配AES-128的单块加密输出长度。这类验证可以结合系统已知的加密密钥、偏移量参数，把数据库存储值解码后做AES解密，看解密结果是不是等于已知明文，就能确认是否为对称加密方案。

匹配失败时优先排查容易忽略的细节 #

如果常规方案验证下来不匹配，优先排查这几个高频影响因素：

• 计算哈希/加密时，用的字符编码不是默认的UTF-8/ASCII，比如很多老系统用GBK、UTF-16编码处理明文，不同编码算出的结果差异极大。
• 计算哈希前拼接了固定盐值，比如把系统内置的固定盐值拼在明文前面、或者后面，再算哈希转Base64存储。
• 哈希计算后做了大小写转换，比如把算出的MD5十六进制值转成全小写/全大写，再转Base64。

内容的提问来源于stack exchange，提问作者carl.hiass