嘿，这个现象确实有点反常，我来帮你拆解几个最可能的原因：

• 哈希算法被误标记：你看到的32字符「SSHA」哈希，大概率实际是MD5哈希。因为MD5的十六进制表示正好是32个字符，而SHA1的十六进制是40个字符。很可能是早期部署时，有人错误地给MD5哈希加上了{SSHA}标记，而非正确的{MD5}——这种情况在老系统里挺常见，比如切换哈希算法时没统一清理旧数据，或者客户端工具配置错了标记规则。

• 混淆了Base64与十六进制存储格式：SSHA的标准存储逻辑是{SSHA}前缀加上Base64编码的「SHA1哈希值+随机盐」，而非直接存十六进制。比如用OpenLDAP自带的slappasswd生成的SSHA，Base64部分大概是38个字符左右（算上前缀总长度44）。如果有人把这些Base64字符串转成了十六进制，长度会变长；但反过来，若把十六进制的MD5当成SSHA内容存储，就会出现32字符的情况。

• 非标准的SSHA实现：虽然SSHA要求必须加盐，但有些不规范的工具或脚本可能只生成了纯SHA1哈希（40字符十六进制）却标成了SSHA，甚至存在加盐长度为0的违规情况（这其实已经不能算SSHA了）。不过32字符的长度还是更偏向MD5误标记的可能性。

你可以做个简单验证：挑一个32字符的哈希，去掉{SSHA}前缀后，把它当成十六进制转成二进制。如果长度是16字节，那100%是MD5被误标记了；如果是20字节，才是SHA1（但32字符十六进制对应16字节，所以基本可以锁定是MD5的问题）。

备注：内容来源于stack exchange，提问作者MarkZ