防范哈希函数实现遭恶意碰撞攻击的可行方法有哪些？

以下是工业界实际落地的成熟防护手段，均可规避全量更换哈希函数带来的重哈希性能损耗：

• 带秘密盐值的哈希计算
  服务器本地生成仅内部可见、不对外泄露的随机秘密盐值，所有用户输入的密钥在做哈希计算前，都会先拼接该盐值再计算哈希。攻击者在未知盐值的前提下，完全无法预先构造符合碰撞条件的攻击密钥，哪怕所用的哈希函数本身存在公开的碰撞漏洞，也无法被利用。该方案仅在原有哈希逻辑前增加一步字符串拼接操作，性能损耗低于1%，无需修改底层哈希函数，也无需全量重哈希，仅在定期更换盐值时才需要做存量数据的重哈希，更换周期可设置为半年到一年，对业务影响极小。
• 哈希桶冲突长度阈值限制
  给哈希表的每个桶的冲突链表/红黑树长度设置硬阈值（通常设置为正常业务场景下最大冲突长度的2~3倍），一旦某个桶的冲突长度超过阈值，自动触发降级逻辑：后续对该桶的查询操作切换为线性遍历，或者自动将该桶的存量数据拆分到独立的小哈希表中。配合服务端单IP/单用户的请求频率限流策略，哪怕攻击者成功构造了部分碰撞密钥，也只会影响单个哈希桶的处理性能，不会导致整个服务器CPU被占满的拒绝服务效果。
• 非法输入前置拦截
  在哈希计算逻辑之前增加输入校验层，先过滤所有不符合业务规则的用户输入：比如校验密钥的长度范围、合法字符集、恶意特征黑名单，攻击者构造的碰撞密钥通常会包含大量非常规字符、或者长度不符合业务要求，90%以上的攻击请求会在这一步被直接拦截，不会进入后续的哈希计算环节。
• 哈希函数增量热切换
  如果确实需要更换存在漏洞的哈希函数，无需做一次性全量重哈希，采用双写双查的灰度切换逻辑即可：新写入的密钥同时用旧哈希函数和新哈希函数计算，分别存入新旧两套哈希表；查询请求优先查新哈希表，查不到再查旧表；后台启动低优先级异步任务，慢慢将旧表的存量数据迁移到新表，等迁移完成后再下线旧哈希表。整个切换过程完全无业务感知，不会出现服务不可用窗口，也不会产生短时间的集中计算负载。

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