JohnTheRipper项目修复MSSQL哈希验证大小写敏感问题分析

近期JohnTheRipper项目中发现了一个影响MSSQL哈希验证功能的回归问题。该问题源于2021年11月的一个提交，导致工具对MSSQL哈希值的验证变得大小写敏感，这与实际应用场景产生了兼容性问题。

问题背景

在数据库安全审计中，MSSQL数据库的密码哈希提取是常见操作。安全工具如nmap的ms-sql-dump-hashes脚本会输出小写格式的MSSQL哈希值。然而JohnTheRipper的最新版本却无法识别这种小写格式的哈希，必须手动转换为大写才能处理，这显然不符合实际使用需求。

技术分析

通过对比测试发现：

1. JohnTheRipper 1.9.0版本无法识别nmap输出的小写哈希
2. 手动转换为大写后验证通过
3. 同类工具hashcat则能同时处理大小写格式

深入代码分析发现，问题源于项目对MS SQL哈希格式的假设——开发团队原以为相关工具都已统一使用大写格式。由于许多其他哈希算法确实对字符大小写敏感，项目没有实现通用的混合大小写支持机制。

解决方案

项目维护者迅速响应并提交了修复方案：

1. 为三种MSSQL哈希格式添加了对大小写的兼容支持
2. 统一采用大写格式写入pot文件，保持结果一致性
3. 设置FMT_SPLIT_UNIFIES_CASE标志确保处理逻辑统一

安全实践建议

在测试过程中还发现一个有趣的安全现象：示例密码"p4$$w0rd1"的测试效率问题。使用最新版JohnTheRipper：

• 默认设置需要约1分钟完成测试（笔记本CPU）
• 使用优化规则集（-ru=by-rate -rules-stack=by-score）可即时完成

这提示我们：

1. 复杂密码规则的重要性
2. 安全工具规则集的优化对测试效率有显著影响
3. 密码策略应避免简单的字符替换模式（如password→p4$$w0rd）

总结

此次修复不仅解决了工具兼容性问题，也提醒我们安全工具在实际应用中需要考虑各种使用场景。对于安全研究人员，建议：

1. 保持工具更新以获取最佳兼容性
2. 了解不同安全工具的特性差异
3. 重视密码策略的制定和实施

该修复已合并到项目主分支，用户更新后将获得更好的MSSQL哈希处理体验。