已知明文密码前提下，如何识别Java+MSSQL系统的加密/认证方式

已知前提梳理 #

• 数据库为MSSQL，后端为Java技术栈，推测使用PrimeFaces前端框架，持有数据库完全操作权限、无系统源码访问权限
• 数据库用户表存储字段样例：

  KeyEnc: 05992DB2BC2055946C299459AF8A4B3F
Password: X/i9vH5oXcBLAn+MWAIIJQ==

• 已掌握所有存储字段值对应的明文密码，此前单独用MD5、纯Base64解码以上字段均未得到有效结果，初步猜测KeyEnc字段是和密码加密关联的解密密钥
• 核心目标是确定系统实际使用的认证加密方式，完成新开发API与老系统数据库的集成

可落地的排查验证步骤 #

1. 卡准字段的基础编码特征，缩小排查范围 #

• KeyEnc是32位大写十六进制字符串，换算成原始字节长度为16字节，刚好匹配128位长度的对称加密密钥长度特征，不是无意义的随机值
• Password是标准Base64编码（末尾带双等号填充），Base64解码后的原始字节长度为16字节，刚好是AES加密的单块输出长度，可以直接排除bcrypt、PBKDF2这类带可变长度输出的单向哈希方案，基本可以确定系统走的是 对称加密存储密码，而非单向哈希存证 的路线

2. 验证KeyEnc作为加密密钥的核心假设 #

把KeyEnc字段的十六进制字符串直接转换为原始字节，作为候选加密密钥，匹配Java生态最常见的老项目加密参数做解密校验：

• 优先测试老项目最常用的简化实现：AES/ECB/PKCS5Padding。很多基于PrimeFaces的早期业务系统为了减少开发量，连初始化向量都不单独设置，直接用ECB模式加密，没有额外的随机值存储。测试逻辑为将Password字段的Base64值解码为密文字节，用转换后的KeyEnc字节作为密钥跑ECB模式解密，校验解密结果是否为已知的明文密码。
• 如果ECB模式测试不通过，再测试AES/CBC/PKCS5Padding的常见偷懒实现：很多老项目会直接取KeyEnc的前16字节当CBC模式的初始化向量，或者直接使用全0的16字节固定IV，不会单独存储向量值。

3. 排除不符合逻辑的实现方案 #

• 无需再投入时间测试纯MD5、SHA系列的单向哈希逻辑：这类单向哈希不会在同一个用户行内存储独立的KeyEnc字段，和字段设计逻辑不匹配
• 核对KeyEnc的存储特征：如果KeyEnc值随用户不同而变化、且同一个用户的KeyEnc值长期固定不变，基本可以坐实这是用户级别的关联加密密钥，而非系统全局的固定配置密钥

4. 匹配老栈的常见内置认证组件 #

Java生态搭配PrimeFaces的老系统，大多使用老版本Spring Security或Apache Shiro做认证，这类框架的早期实现中，很多直接使用16位十六进制字符串作为AES加密密钥，加密后的密码输出为Base64格式，没有额外的盐值随机数，和当前观测到的字段长度、存储格式完全匹配。

内容的提问来源于stack exchange，提问作者Joismar Braga