Node.bcrypt.js哈希比较特性解析：72字节限制对JWT令牌的影响

背景概述

在用户认证系统中，开发者常使用JWT作为令牌机制，同时配合bcrypt等算法进行敏感数据的存储保护。近期有开发者发现，当使用Node.bcrypt.js库处理JWT令牌时，会出现不同令牌通过哈希验证的异常情况。

核心问题现象

当对两个不同但前72字符相似的JWT refresh token进行bcrypt哈希比较时：

1. 原始令牌A：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjY3YjQ2NWE...
2. 相似令牌B：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjY3YjQ2NWE...（仅尾部差异）

使用bcrypt.compare()方法对这两个令牌与同一哈希值比较时，都会返回true。

技术原理分析

bcrypt的72字节限制

Node.bcrypt.js底层采用Blowfish加密算法，其设计特性决定：

• 仅处理输入字符串的前72个字节（UTF-8编码）
• 超长输入会被静默截断
• 这是算法层面的固有特性，非实现缺陷

JWT令牌的结构特点

典型JWT包含三部分：

头部(Header).载荷(Payload).签名(Signature)

当不同令牌的头部和载荷部分完全相同时（前72字节内），即使签名部分不同，bcrypt仍会判定为相同哈希值。

解决方案建议

针对JWT存储场景

1. 必要性评估：

   • JWT本身已包含数字签名，通常无需二次哈希
   • 如需防篡改，应验证签名而非内容哈希

2. 改进存储方案：

   • 存储关键标识（如jti声明）而非完整令牌
   • 使用专门的黑名单机制替代哈希比较

3. 替代技术方案：

   // 改为验证签名有效性
   jwt.verify(token, secretKey, (err, decoded) => {
     if(err) {/* 处理无效令牌 */}
   });
   

通用bcrypt使用建议

1. 对长字符串应先进行摘要处理：

   const crypto = require('crypto');
   const shortHash = crypto.createHash('sha256').update(longString).digest('hex');
   await bcrypt.compare(shortHash, storedHash);
   

2. 重要系统应添加长度校验：

   if(input.length > 72) {
     throw new Error('Input exceeds bcrypt limit');
   }
   

深度技术思考

该现象揭示了安全实践中一个重要原则：加密组件的特性必须与使用场景匹配。bcrypt作为密码哈希工具，其设计针对的是：

• 固定长度的密码输入
• 相对较短的认证凭证
• 加盐防彩虹表攻击

而JWT作为自包含令牌，需要的是：

• 签名验证机制
• 声明完整性检查
• 时效性控制

开发者应当根据数据特性和安全需求，选择合适的加密验证策略。

总结