静态块不适合管理全局唯一加密盐值，因其导致所有用户共用同一固定盐值，违背盐值必须唯一且随机的密码学原则，使哈希退化为可预测的固定前缀，极易遭受彩虹表攻击。

静态块不适合管理全局唯一的加密盐值变量，反而会严重削弱安全性。

静态盐值违背密码学基本原则

盐值的核心作用是防止彩虹表攻击和哈希碰撞。它必须满足两个硬性条件：唯一性、随机性。而静态块在类加载时就初始化一次，所有用户共用同一个盐值，等于把“加盐”退化为“固定前缀”。此时相同密码仍生成完全相同的哈希值，彩虹表可直接复用，安全等级不升反降。

常见错误写法及风险

比如以下代码看似简洁：

public class PasswordUtils {
    private static final String STATIC_SALT = "aB3#xQ9!"; // ❌ 危险！硬编码、固定、可预测
    static {
        System.out.println("Salt loaded: " + STATIC_SALT);
    }
    public static String hash(String pwd) {
        return DigestUtils.md5DigestAsHex((STATIC_SALT + pwd).getBytes());
    }
}

问题包括：
• 所有用户密码哈希都基于同一盐值，数据库中重复哈希暴露密码一致性
• 源码或字节码泄露即等于盐值泄露，攻击者可批量预计算破解
• 无法支持密码重置后盐值更新，历史凭证长期存在风险

正确做法：每个用户独立动态盐值

盐值必须由服务端在用户注册/改密时实时生成，并与该用户绑定存储。推荐方式：

• 使用 UUID.randomUUID().toString().replace("-", "") 生成32位随机字符串作为盐
• 盐值与哈希结果一同存入数据库（如 salt 和 password_hash 两个字段）
• 登录验证时：查出该用户的盐 → 拼接明文密码 → 重新哈希 → 比对数据库中的哈希值
• 优先选用 bcrypt 或 SCrypt，它们自动内嵌随机盐并编码进哈希字符串，无需手动管理

若真需“全局控制”，应聚焦策略而非盐值

真正值得用静态块配置的是加密策略参数，例如：

• 哈希迭代轮数（如 PBKDF2 的 600,000 次）
• 算法选择开关（开发环境用 SHA-256，生产强制 bcrypt）
• 盐长度标准（统一生成 16 字节随机 salt）

这些属于配置项，不参与具体哈希运算，不影响每个用户的盐唯一性。