求教！这是什么加密

hope

+------------+--------------+-------+
| loginname  | password     | email |
+------------+--------------+-------+
| admin      | JNHOPuGxUis= | NULL  |
| shenheren1 | JNHOPuGxUis= | NULL  |
| shenheren2 | JNHOPuGxUis= | NULL  |
| shenheren3 | JNHOPuGxUis= | NULL  |
| shenheren4 | AKNKznGugc0= | NULL  |
| shenheren5 | AKNKznGugc0= | NULL  |
| shenheren6 | AKNKznGugc0= | NULL  |
+------------+--------------+-------+

wbgj1569

楼主知道那是什么加密了没{:soso_e140:}

hope

wbgj1569 发表于 2015-9-27 12:09
楼主知道那是什么加密了没

不知道额 求解

热心网友5

从你贴出来的数据看，密码字段末尾有等号，而且都是12个字符（含等号），这很像是 Base64 编码后的结果。你可以先直接把 `JNHOPuGxUis=` 和 `AKNKznGugc0=` 拿去 Base64 解码看看，解码出来可能是明文密码，也可能是其他加密后的二进制数据。 另外，同一个密码出现在多个用户身上，也可能是简单的加密（比如固定 salt 的 MD5 再 Base64 编码）。如果直接 Base64 解码出来是乱码，那可能是哈希值再 Base64 的结果，需要再尝试常见的哈希算法（MD5、SHA1 等）去比对。 你可以先试试在线 Base64 解码工具，如果解出来不是可读文本，再结合长度和特征往哈希方向猜。希望能帮到你！

热心网友2

从你贴出的数据来看，password 字段的值以等号结尾，长度固定为12个字符，这很可能是 Base64 编码后的结果。解码后是8字节的数据，常见的情况有： - 某种64位哈希（比如 CRC64 或者定制的哈希算法） - 经过 Base64 编码的加密密文（例如 DES、Blowfish 等块加密的输出） 另外注意到多个用户密码完全相同（admin 和 shenheren1~3 都是 `JNHOPuGxUis=`，shenheren4~6 都是 `AKNKznGugc0=`），说明可能使用的是相同的密码，或者是默认/弱密码。你可以尝试把 `JNHOPuGxUis=` 解码为字节，然后看看能否推断出原始密码的对应关系。如果能拿到对应的明文密码，反向验证算法会容易很多。 如果这是某个特定系统（比如论坛、CMS）的密码字段，建议先确认该系统的密码存储文档，常见做法是 MD5 或 SHA1 后再 Base64，但8字节输出不太可能是 MD5（16字节）或 SHA1（20字节），更像是某种自定义或旧的加密方案。

热心网友5

从给出的数据来看，这些密码看起来像是 Base64 编码后的字符串，比如 `JNHOPuGxUis=` 和 `AKNKznGugc0=` 都带有等号填充，长度也符合 Base64 的特点。不过同一个密码对应了多个用户，而且全部是 NULL 的邮箱，这可能说明数据库里的密码字段存储的是某种固定值或默认值，并没有真正使用随机盐值加哈希。 你可以尝试把这段 Base64 解码看看，如果是可读的明文那就简单了。如果解码后是乱码，那可能是某种哈希（比如 MD5、SHA1）再 Base64 后的结果，但长度不太对——MD5 的 Base64 通常是 24 个字符（含等号），这里只有 12 个字符，所以也有可能是一种较短的加密算法（比如 DES 或 3DES 的密文再进行 Base64 编码）。 建议你先把这两段 Base64 解码，看能不能得到有意义的字符串，如果不行再根据字符特征推测算法。另外，你是在什么系统或场景下看到这个表结构的？比如 CMS、论坛、或者自己写的应用？这会帮助缩小加密类型的范围。