Keycloak密码加密实战：算法选型、参数调优与安全迁移方案-拓冰建站

1. 项目概述：为什么我们需要关注Keycloak的密码加密？

如果你正在使用或评估Keycloak作为你的身份认证与访问管理（IAM）解决方案，那么“密码加密”这个议题绝对不应该被忽视。这不仅仅是配置一个算法那么简单，它直接关系到你整个系统的安全基石是否稳固。想象一下，你的Keycloak实例管理着成百上千甚至上万用户的凭证，这些密码数据如果以明文或弱加密方式存储，一旦数据库泄露，后果将是灾难性的。我见过太多团队在初期快速搭建Keycloak时，直接使用了默认配置，而忽略了密码哈希策略的深度定制，直到安全审计亮起红灯才追悔莫及。

Keycloak本身是一个功能强大的开源IAM，它内置了多种密码哈希算法，但这把“安全锁”的强度取决于你如何选择和配置它。本项目标题“Keycloak密码加密解决方案”的核心，就是深入探讨如何超越默认设置，构建一个健壮、可抵御现代攻击（如彩虹表、GPU暴力破解）的密码存储机制。这涉及到从算法选型、参数调优，到与现有用户迁移、性能权衡等一系列实战问题。无论你是运维工程师、安全架构师还是后端开发者，只要你的系统依赖Keycloak进行认证，理解并实施一套强密码加密方案，就是你的职责所在。接下来，我将结合多年的一线部署和调优经验，为你拆解其中的每一个关键环节。

2. 核心需求与安全模型解析

2.1 密码存储的安全基本原则

在深入Keycloak的具体配置之前，我们必须先统一思想：密码存储的目标是什么？答案绝不是“加密”，而是“不可逆的哈希”。我们永远不应该存储用户的明文密码，甚至不应该存储可解密还原的密文。正确的做法是，当用户设置密码时，我们使用一个密码哈希函数（Password Hash Function）对其进行处理，生成一个固定长度的“指纹”（即哈希值），然后将这个哈希值存入数据库。下次用户登录时，我们对其输入的密码进行同样的哈希计算，并比对两个哈希值是否一致。

这里的关键在于，一个安全的密码哈希函数需要具备以下特性：

确定性：相同的输入永远产生相同的输出。
雪崩效应：输入的微小改变会导致输出的巨大差异。
单向性：从哈希值反向推导出原始密码在计算上不可行。
抗碰撞性：很难找到两个不同的密码产生相同的哈希值。
计算密集型：哈希计算本身需要消耗一定的计算资源（CPU/内存），以增加暴力破解的成本。

Keycloak内置的密码哈希器（Password Hash Provider）就是围绕这些原则实现的。但默认配置往往为了兼容性和性能，可能未启用最强的算法或最优的参数，这就是我们需要介入定制的原因。

2.2 Keycloak密码加密的典型场景与挑战

在实际项目中，对Keycloak密码加密方案的改造通常源于以下几个核心需求场景：

场景一：合规性驱动。金融、医疗或政府项目通常需要遵守严格的安全标准，如等保2.0、PCI DSS、GDPR等。这些标准明确要求使用强密码哈希算法（如PBKDF2、bcrypt）并具备足够的迭代次数或工作因子。默认的“默认”（可能是较弱的哈希）算法无法满足审计要求。

场景二：安全升级与用户迁移。系统上线初期可能使用了较弱的哈希算法（例如简单的SHA-256，没有加盐或迭代）。随着安全认知的提升，需要将现有用户密码的存储方式升级到更强大的算法（如升级到bcrypt或PBKDF2）。这个过程需要无缝进行，不能影响现有用户的登录，即“动态哈希迁移”。

场景三：性能与安全的平衡。更强的哈希算法意味着更多的计算开销。在高并发登录的场景下（如千万级用户的互联网应用），不恰当的参数设置（如bcrypt的工作因子过高）可能导致认证服务响应缓慢甚至CPU过载。我们需要找到一个在安全强度和服务性能之间的最佳平衡点。

场景四：防范特定攻击。针对使用GPU或专用硬件（ASIC）的暴力破解，我们需要选择内存消耗大的算法（如Argon2），以增加攻击者的硬件成本。同时，充足的“盐值”（Salt）长度和全局唯一的盐值生成，是抵御彩虹表攻击的必备手段。

理解这些场景，有助于我们在设计解决方案时做出有针对性的决策，而不是盲目追求“最强”配置。

3. Keycloak密码哈希器深度剖析与选型

3.1 内置算法详解与横向对比

Keycloak提供了多种开箱即用的密码哈希器。了解它们的原理和差异是正确选型的第一步。以下是几种核心算法的深度解析：

1. PBKDF2 (Password-Based Key Derivation Function 2)

原理：通过对密码和盐值进行多次（可配置）哈希迭代（通常是HMAC-SHA256）来派生密钥。迭代次数是其主要的安全参数。
Keycloak标识：pbkdf2-sha256
优点：标准化（NIST推荐），广泛支持，参数（迭代次数）调整灵活。抗GPU破解能力较强，因为其核心是串行计算。
缺点：对内存要求不高，因此面对使用大量廉价内存的定制硬件（如某些ASIC）攻击时，防御成本相对较低。
适用场景：大多数通用场景，尤其是需要符合FIPS等标准的政府或企业应用。是平衡安全性和性能的可靠选择。

2. bcrypt

原理：基于Blowfish加密算法，引入“工作因子”（work factor）的概念，该因子不仅增加计算时间，还会增加内存消耗。
Keycloak标识：bcrypt
优点：内置盐值，能有效抵抗彩虹表攻击。工作因子是对数增长的，微小的增加会显著提升计算成本。在抗GPU/ASIC攻击方面比PBKDF2更好，因为它涉及对内存的频繁访问。
缺点：最大密码长度限制（通常72字符），对于使用超长密码短语的用户可能不友好。在一些平台上实现可能不如PBKDF2高效。
适用场景：对安全性要求高，且能够接受一定认证延迟的应用。是许多安全专家的首选推荐。

3. Argon2

原理：2015年密码哈希竞赛的获胜者。明确设计了三个可调参数：时间成本（迭代次数）、内存成本（使用的内存大小）和并行度（使用的线程数）。
Keycloak标识：argon2(Keycloak通常支持其变体，如Argon2id)
优点：被认为是当前最先进的密码哈希算法。通过同时调整时间、内存和并行度，可以最大化攻击者的硬件成本。尤其能有效抵御使用大量内存和并行计算的定制硬件攻击。
缺点：配置参数更复杂，需要更精细的调优。资源消耗最大，在高并发下对服务器压力明显。
适用场景：对安全性有极致要求，并且服务器资源充足的新建系统。是面向未来的选择。

4. 其他算法

SHA-256/512 (加盐): Keycloak可能支持如salt-sha-256。请注意：单纯的加盐SHA系列不是为密码存储设计的密钥派生函数，因为它们计算太快，极易被暴力破解。在生产环境中绝对禁止使用。它们可能仅存在于遗留系统迁移的过渡阶段。

实操心得：算法选型速查表这里我整理了一个简单的决策表，帮助你在不同情况下快速选择：
优先级推荐算法核心考量典型参数（起点）
安全优先，资源充足 Argon2id 抵御高端硬件攻击能力最强内存成本=64MB，时间成本=3，并行度=4
平衡之选，广泛适用 bcrypt 良好的安全性与成熟的生态工作因子=12 （约250-300ms）
合规要求，标准优先 PBKDF2-SHA256 满足各类安全标准审计迭代次数=310000 （约250-300ms）
遗留迁移 与原系统一致保证用户无缝登录需与原系统参数完全匹配
绝对禁止 纯MD5/SHA-*、明文毫无安全性可言 -

优先级	推荐算法	核心考量	典型参数（起点）
安全优先，资源充足	Argon2id	抵御高端硬件攻击能力最强	内存成本=64MB，时间成本=3，并行度=4
平衡之选，广泛适用	bcrypt	良好的安全性与成熟的生态	工作因子=12 （约250-300ms）
合规要求，标准优先	PBKDF2-SHA256	满足各类安全标准审计	迭代次数=310000 （约250-300ms）
遗留迁移	与原系统一致	保证用户无缝登录	需与原系统参数完全匹配
绝对禁止	纯MD5/SHA-*、明文	毫无安全性可言	-

3.2 关键参数调优：在安全与性能间走钢丝

选择了算法只是第一步，参数的配置才是真正体现功力的地方。参数的目标是：让一次合法的密码验证在你的服务器上耗时“可接受”（例如200-500毫秒），而对攻击者来说，尝试海量密码的成本高到无法承受。

1. 迭代次数/工作因子/时间成本

PBKDF2 (迭代次数)：例如从默认的27500次提升到310000次。这是OWASP 2023年推荐的基准值。你可以使用一个简单的测试脚本来确定你硬件上的最佳值。

# 示例：使用Python快速测试（需安装passlib） # from passlib.hash import pbkdf2_sha256 # import timeit # timeit.timeit(lambda: pbkdf2_sha256.hash("test", rounds=310000), number=10)/10

bcrypt (工作因子)：工作因子每增加1，计算时间大约翻倍。因子10约需100ms，因子12约需400ms。从10或11开始测试，确保登录API的响应时间（P99）仍在你的SLA范围内。
Argon2 (时间成本)：类似迭代次数。通常从3开始。

2. 内存成本 (仅Argon2)这是Argon2的杀手锏。设置一个较大的内存消耗（如64MB或128MB），能显著提高攻击者使用GPU或ASIC进行大规模并行破解的硬件门槛。你需要监控认证服务的内存使用情况，确保在并发登录峰值时不会导致服务器内存耗尽。

3. 盐值 (Salt)Keycloak会自动为每个密码生成唯一的盐值。你通常不需要配置盐值生成方式，但需要确保数据库字段有足够的长度来存储“算法标识+参数+盐值+哈希值”这个完整的哈希字符串。Keycloak的CREDENTIAL表里的VALUE列通常是TEXT类型，足够存储。

注意事项：参数测试方法论永远不要在生产环境直接修改参数。建议的流程是：
基准测试：在预发布环境，模拟真实用户登录的并发量（使用工具如JMeter），记录当前算法参数下的认证延迟和服务器资源（CPU、内存）使用率。
调整与测试：逐步调高安全参数（如增加迭代次数），每次调整后重复压力测试，观察性能衰减曲线。
确定阈值：找到那个“性能刚好开始让你感到有点压力，但尚可接受”的临界点参数。这个点就是你的最佳安全参数。
制定迁移计划：如果新参数与旧参数不兼容（例如从pbkdf2迭代27500次改为310000次），你需要规划用户密码的动态迁移策略（下文详述）。

4. 实施与配置：从控制台到代码

4.1 通过管理控制台配置域密码策略

对于大多数场景，通过Keycloak管理控制台进行配置是最快捷的方式。这适用于新域创建或现有域的整体策略变更。

步骤详解：

登录管理控制台：以管理员身份登录你的Keycloak实例。
选择域 (Realm)：在左侧下拉菜单中选择你要配置的域。
导航至认证策略：点击左侧菜单Authentication->Policies->Password Policy。
添加哈希算法策略：在密码策略列表中，点击Add policy。从下拉框中找到Hashing Algorithm并选择。
配置算法参数：
- 选择算法，如pbkdf2-sha256。
- 随后会出现该算法对应的参数输入框。对于pbkdf2-sha256，你需要输入迭代次数。
- 重要：迭代次数的值需要根据上述测试结果填写。例如，输入310000。
保存并生效：保存策略。此策略仅对新注册的用户和修改密码的用户生效。现有用户的密码哈希方式不会立即改变。

控制台配置的局限性：

无法迁移现有用户：这是最大的限制。控制台策略只影响“未来”的密码。
参数选项有限：控制台可能只暴露了核心参数（如迭代次数），对于Argon2的复杂参数（内存、并行度）支持可能不完整或没有。
无法实现精细控制：比如，你不能为不同的用户组设置不同的哈希强度。

4.2 通过SPI（服务提供者接口）实现自定义密码哈希器

当控制台配置无法满足需求时（尤其是需要动态迁移或使用非常特殊的算法），就需要开发自定义的PasswordHashProviderFactory。这是Keycloak强大的扩展机制。

核心步骤与代码解析：

创建Maven项目：添加Keycloak核心服务SPI依赖。

<dependency> <groupId>org.keycloak</groupId> <artifactId>keycloak-core</artifactId> <version>${keycloak.version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.keycloak</groupId> <artifactId>keycloak-server-spi</artifactId> <version>${keycloak.version}</version> <scope>provided</scope> </dependency>

实现PasswordHashProviderFactory接口：这是工厂类，负责创建提供者实例和定义配置元数据。

import org.keycloak.credential.hash.PasswordHashProvider; import org.keycloak.credential.hash.PasswordHashProviderFactory; import org.keycloak.models.KeycloakSession; import java.util.Map; public class MyArgon2PasswordHashProviderFactory implements PasswordHashProviderFactory { public static final String ID = "my-argon2"; private static final int DEFAULT_MEMORY = 65536; // 64MB in KiB private static final int DEFAULT_ITERATIONS = 3; private static final int DEFAULT_PARALLELISM = 4; @Override public PasswordHashProvider create(KeycloakSession session) { // 可以从session或配置中读取参数 return new MyArgon2PasswordHashProvider(getConfig()); } @Override public String getId() { return ID; // 这个ID将在密码策略配置中被引用 } @Override public String getDisplayName() { return "My Custom Argon2"; } // 配置描述，会在管理控制台显示 @Override public Map<String, String> getOperationalInfo() { return Map.of( "memory", "内存成本 (KiB)", "iterations", "时间成本 (迭代次数)", "parallelism", "并行度" ); } private Map<String, String> getConfig() { // 这里可以硬编码，或从外部配置源读取 return Map.of( "memory", String.valueOf(DEFAULT_MEMORY), "iterations", String.valueOf(DEFAULT_ITERATIONS), "parallelism", String.valueOf(DEFAULT_PARALLELISM) ); } }

实现PasswordHashProvider接口：核心逻辑所在，负责编码、验证和配置检查。

import org.keycloak.credential.hash.PasswordHashProvider; import org.bouncycastle.crypto.generators.Argon2BytesGenerator; // 使用BouncyCastle库 import org.bouncycastle.crypto.params.Argon2Parameters; import java.util.Base64; public class MyArgon2PasswordHashProvider implements PasswordHashProvider { private final Map<String, String> config; public MyArgon2PasswordHashProvider(Map<String, String> config) { this.config = config; } @Override public boolean policyCheck(String algorithm, Map<String, String> params) { // 检查传入的算法ID和参数是否符合本提供者的要求 return ID.equals(algorithm) && params != null; } @Override public void encode(String rawPassword, int iterations, String encodedPassword) { // 此方法在用户注册或修改密码时调用 // 1. 生成随机盐值 byte[] salt = new byte[16]; new SecureRandom().nextBytes(salt); // 2. 根据配置构建Argon2参数 Argon2Parameters.Builder builder = new Argon2Parameters.Builder(Argon2Parameters.ARGON2_id) .withSalt(salt) .withMemoryAsKB(Integer.parseInt(config.get("memory"))) .withIterations(Integer.parseInt(config.get("iterations"))) .withParallelism(Integer.parseInt(config.get("parallelism"))); // 3. 计算哈希 Argon2BytesGenerator generator = new Argon2BytesGenerator(); generator.init(builder.build()); byte[] hash = new byte[32]; // 输出32字节哈希 generator.generateBytes(rawPassword.toCharArray(), hash); // 4. 将算法ID、参数、盐值、哈希值编码成一个字符串，存入encodedPassword // 格式示例：$my-argon2$m=65536,t=3,p=4$<base64_salt>$<base64_hash> String encoded = String.format("$%s$m=%s,t=%s,p=%s$%s$%s", MyArgon2PasswordHashProviderFactory.ID, config.get("memory"), config.get("iterations"), config.get("parallelism"), Base64.getEncoder().encodeToString(salt), Base64.getEncoder().encodeToString(hash)); // 注意：encodedPassword是一个String参数，实际需要将其设置到用户凭证中。 // 这里为简化，直接说明逻辑。实际Keycloak SPI会通过回调或上下文设置。 } @Override public boolean verify(String rawPassword, String encodedPassword) { // 此方法在用户登录时调用 // 1. 从encodedPassword中解析出算法ID、参数、盐值和存储的哈希值 // 2. 使用解析出的盐值和参数，对输入的rawPassword重新计算哈希 // 3. 比较新计算的哈希值与存储的哈希值是否一致 // 伪代码： // String[] parts = encodedPassword.split("\\$"); // ... 解析 parts ... // byte[] salt = Base64.getDecoder().decode(parts[3]); // byte[] storedHash = Base64.getDecoder().decode(parts[4]); // // 使用相同的参数重新计算 // byte[] computedHash = computeArgon2(rawPassword, salt, parsedParams); // return MessageDigest.isEqual(computedHash, storedHash); // 使用恒定时间比较 return true; // 实际返回比较结果 } }

注册SPI：在resources/META-INF/services/目录下创建文件org.keycloak.credential.hash.PasswordHashProviderFactory，内容为你工厂类的全限定名。
```
com.yourcompany.keycloak.provider.MyArgon2PasswordHashProviderFactory
```
打包与部署：将项目打包为JAR，放入Keycloak的providers/目录，然后重启Keycloak服务器。之后在管理控制台的密码策略中，就能看到并选择你的my-argon2算法了。

踩坑实录：SPI开发中的关键点
恒定时间比较：在verify方法中比较哈希值时，绝对不能使用String.equals()或Arrays.equals()。必须使用MessageDigest.isEqual()或类似的安全比较函数，以防止基于时间的侧信道攻击。
编码格式：encode方法生成的字符串格式必须与verify方法解析的格式完全一致。建议采用类似$algorithm$params$salt$hash的通用格式。
配置热更新：如果你的哈希参数需要动态调整（不推荐频繁进行），工厂类需要能够重新读取配置。简单的做法是将配置放在外部文件或环境变量中，在create方法里读取。
版本兼容：确保你的SPI实现与Keycloak版本兼容。不同版本的SPI接口可能有细微变化。

5. 现有用户密码的动态迁移方案

这是实施新密码策略中最棘手、但必须妥善处理的一环。目标是在用户无感知的情况下，将其旧哈希密码升级为新哈希密码。

5.1 迁移策略设计

迁移的核心思想是“在验证时升级”。具体流程如下：

用户使用旧密码登录。
系统使用旧的哈希算法验证密码。
验证成功后，立即使用新的、更强的哈希算法对同一个明文密码重新计算哈希，并更新数据库中的存储。
下次用户登录时，将直接使用新的哈希算法进行验证。

这样，随着时间推移，活跃用户的密码会自动迁移到新算法。不活跃用户的密码则保持旧算法，直到他们下次登录。

5.2 实现方式：自定义用户存储SPI或事件监听器

Keycloak本身不直接提供一键迁移功能，但我们可以通过扩展点实现。

方案A：自定义UserStorageProvider(更彻底)如果你已经使用自定义的用户存储（如连接外部数据库），可以在其credentialValidation方法中实现迁移逻辑。

@Override public boolean credentialValidation(KeycloakSession session, RealmModel realm, UserModel user, CredentialInput input) { if (!(input instanceof UserCredentialModel)) return false; UserCredentialModel cred = (UserCredentialModel) input; if (!cred.getType().equals(CredentialModel.PASSWORD)) return false; // 1. 从你的存储中获取用户当前的密码哈希字符串 String currentHashedPassword = getPasswordFromStorage(user.getId()); // 2. 解析当前哈希字符串，判断其使用的算法 if (isLegacyAlgorithm(currentHashedPassword)) { // 3. 使用旧算法验证用户输入的密码 if (verifyWithLegacyAlgorithm(cred.getValue(), currentHashedPassword)) { // 4. 验证成功！立即使用新算法重新哈希密码 String newHashedPassword = encodeWithNewAlgorithm(cred.getValue()); // 5. 更新存储中的密码哈希 updatePasswordInStorage(user.getId(), newHashedPassword); // 6. （可选）在Keycloak内部也更新凭证，保持同步 user.credentialManager().updateCredential(...); return true; } else { return false; } } else { // 如果已经是新算法，直接用新算法验证 return verifyWithNewAlgorithm(cred.getValue(), currentHashedPassword); } }

这种方案将迁移逻辑与你的用户存储深度绑定，控制力最强。

方案B：使用EventListenerProvider(相对简单)你可以监听LoginEvent，在用户登录成功后触发迁移。

public class PasswordHashMigrationEventListenerProvider implements EventListenerProvider { @Override public void onEvent(Event event) { if (event.getType() != EventType.LOGIN) return; KeycloakSession session = //... 如何获取session是关键难点; RealmModel realm = session.realms().getRealm(event.getRealmId()); UserModel user = session.users().getUserById(realm, event.getUserId()); // 获取用户的密码凭证 CredentialModel passwordCred = user.credentialManager() .getStoredCredentialsByTypeStream(CredentialModel.PASSWORD) .findFirst().orElse(null); if (passwordCred != null && isLegacyAlgorithm(passwordCred.getCredentialData())) { // 注意：这里无法获取到用户刚输入的明文密码！ // 所以此方案无法直接完成迁移。需要结合其他方式，例如在自定义认证流程中处理。 } } }

注意：纯事件监听器方案有个致命缺陷——在登录成功事件中，你无法获取到用户刚刚输入的明文密码。因此，这个方案不能独立完成密码重哈希。它通常用于记录和触发异步任务，真正的迁移需要在自定义认证流程（如自定义Authenticator）中完成，那里可以访问到CredentialInput。

实操心得：迁移的灰度与回滚
先读后写：在迁移代码中，务必先验证旧密码，验证成功后再写入新密码。这是一个“比较-交换”的原子性操作，在并发登录时需考虑数据库锁或乐观锁机制，防止重复迁移或数据竞争。
记录日志：详细记录哪些用户被迁移、迁移时间、从何算法迁移至何算法。这对于问题排查和审计至关重要。
准备回滚方案：在迁移期间，可以考虑短暂地同时存储新旧两种哈希值（存储在额外字段）。如果新算法出现问题，可以快速将验证逻辑切回旧算法。待新算法稳定后，再清理旧哈希字段。这增加了复杂性，但在关键系统中是值得的。
通知用户：对于安全升级，可以考虑在用户登录后，通过界面提示“您的账户安全性已自动升级”，增强用户信任感。

6. 性能、监控与运维考量

6.1 性能基准测试与容量规划

将密码哈希强度提升一个数量级，对认证端点的性能影响是立竿见影的。你必须进行压测。

测试方法：

工具：使用wrk,jmeter或k6等工具模拟登录请求。
场景：
- 单请求延迟：测试单个登录请求从发送到收到响应的耗时。重点关注平均响应时间和P95、P99延迟。
- 并发吞吐量：逐步增加并发用户数，观察每秒成功认证请求数（RPS）的变化，以及服务器的CPU和内存使用率。找到系统的性能拐点。
对比测试：分别使用旧参数和新参数进行压测，量化性能损失。例如，迭代次数从27500提升到310000，可能导致单次认证耗时从10ms增加到300ms，同等资源下的最大RPS从1000下降到100。

容量规划建议：

水平扩展：认证服务（Keycloak）应设计为无状态，可以方便地水平扩展。当认证成为瓶颈时，增加实例数量是最直接的方法。
缓存策略：对于成功的登录，可以考虑短期缓存认证结果（如几分钟），但这会牺牲一些安全性（在缓存期内，即使用户密码在别处被修改，此处仍可登录），需要权衡。
硬件选型：CPU性能直接影响哈希计算速度。对于计算密集型的PBKDF2或bcrypt，选择更高主频的CPU可能比更多核心更有益。对于内存密集型的Argon2，确保每个实例有充足的内存。

6.2 监控与告警

一旦新的密码策略上线，监控必须跟上。

关键监控指标：

应用层：
- auth_login_attempts_total：登录尝试总数（分成功/失败）。
- auth_login_duration_seconds：登录请求的耗时分布（直方图）。这是最重要的指标之一，用于观察哈希计算是否导致延迟毛刺。
- credential_update_total：密码更新/迁移次数。
系统层：
- CPU使用率：特别是单个核心的CPU使用率。哈希计算是单线程的，高并发下可能使单个CPU核心饱和。
- 内存使用率：如果使用Argon2，监控进程内存增长是否稳定。
业务层：
- 用户登录失败率：迁移过程中，因新旧算法验证逻辑错误导致的失败率。
- 活跃用户迁移比例：通过日志分析，统计已迁移到新算法的活跃用户占比，评估迁移进度。

告警设置：

当登录平均延迟或P99延迟超过预定阈值（如1秒）时触发告警。
当登录失败率异常升高时触发告警。
当认证服务实例的CPU持续高于80%时触发告警。

6.3 密钥衍生函数（KDF）的未来与算法升级路径

密码学不是一成不变的。今天安全的算法，未来可能被破解。因此，设计一个支持算法升级的架构至关重要。

建议的升级路径：

抽象层：在业务代码和Keycloak密码验证之间，可以引入一个薄薄的抽象层。所有密码验证请求都通过这个层，该层内部决定使用哪种验证逻辑。未来更换算法时，只需修改这个层。
算法标识符：确保存储的密码哈希字符串始终包含明确的算法标识符（如$argon2id$...）。这样验证逻辑才能正确路由。
定期评估：每年或每两年，重新评估当前使用的哈希算法和参数是否仍符合安全最佳实践。关注NIST、OWASP等权威机构的最新指南。
计划性迁移：将密码哈希升级作为常规的运维任务。可以设定目标，例如“每三年启动一次全量密码哈希算法升级项目”，并为此预留资源和制定详细的实施与回滚方案。

我个人在实际操作中的体会是，密码加密方案的规划和实施，七分在设计和沟通，三分在技术。你需要说服团队和业务方，为了一次可能“看不见摸不着”的安全升级，投入开发、测试和运维资源，并接受性能上的一定损耗。这背后是对安全风险的共同认知。最成功的升级，是那些在问题发生之前就悄然完成，并且没有给用户带来任何感知的升级。它就像一座大楼的地基，平时无人提及，但决定了整座建筑能屹立多久。