com.sun.faces.ClientStateSavingPassword - 实际密码的建议? [英] com.sun.faces.ClientStateSavingPassword - recommendations for actual password?

问题描述

在我找到的有关加密 ViewState 的所有参考页面中，对密码的唯一评论是您的密码在这里".

In all of the reference pages I've found with regards to encrypting the ViewState, the only comment on the password is "your password here".

对于我们应该使用的密码的长度/复杂性有什么建议吗?

Are there any recommendations regarding the length / complexity of the password that we should use?

推荐答案

取决于 Mojarra 版本.它在早期版本中有几个缺陷/失败.

Depends on Mojarra version. It had several flaws/fails in earlier versions.

在 Mojarra 1.2.x - 2.1.18 中，它从未被实际使用过.JNDI 条目名称记录不正确.它被记录为com.sun.faces.ClientStateSavingPassword(前缀与 Mojarra 的其他 web.xml 上下文参数)，但代码 实际上检查ClientStateSavingPassword.然后你应该用那个名字注册它.

In Mojarra 1.2.x - 2.1.18, it was never actually used. The JNDI entry name was namely incorrectly documented. It was documented as com.sun.faces.ClientStateSavingPassword (with same prefix as Mojarra's other web.xml context parameters), but the code actually checks for ClientStateSavingPassword. You should then register it on that name instead.

<env-entry>
    <env-entry-name>ClientStateSavingPassword</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>[Your Password]</env-entry-value>
</env-entry>

否则，客户端状态实际上没有加密.

Otherwise, the client state is actually not encrypted.

在 Mojarra 1.2.x - 2.0.3 中，密码 将用作SecureRandom 种子 生成 DES 算法密钥.因此，一般来说，相同的规则适用于真实世界"密码.只是，这很容易 如果密码太简单"并且攻击者成功猜测/暴力破解/计算密码，则被盗用.

In Mojarra 1.2.x - 2.0.3, the password will be used as a SecureRandom seed to generate a DES algorithm key. So, generally, the same rules apply as to "real world" passwords. Only, this can be easily compromised if the password is "too easy" and the attacker successfully guesses/bruteforces/figures the password.

在 Mojarra 2.0.4 - 2.1.x 中，他们将算法从 DES 更改为 AES 并且代码现在不实际上 不再使用提供的密码来生成密钥(以防止潜在的冲突).相反，一个完全随机的密钥是 生成，更安全.JNDI 条目现在基本上控制是否应该加密客户端状态.换句话说，它现在的行为就像一个布尔配置条目.因此，您使用哪个密码绝对不再重要.

In Mojarra 2.0.4 - 2.1.x, they changed the algorithm from DES to AES and the code now don't actually use the provided password anymore to generate the key (to prevent potential comprisions). Instead, a completely random key is generated, which is more safe. The JNDI entry now basically controls whether the client state should be encrypted or not. In other words, it behaves now like a boolean configuration entry. It thus absolutely doesn't matter anymore which password you use.

<env-entry>
    <env-entry-name>ClientStateSavingPassword</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value>
</env-entry>

在 Mojarra 2.1.19 - 2.1.x 中，他们 修复代码以对齐 JNDI 条目名称的文档.所以你可以使用记录的 JNDI 条目名称:

In Mojarra 2.1.19 - 2.1.x, they fixed the code to align the documentation on JNDI entry name. So you could use the documented JNDI entry name:

<env-entry>
    <env-entry-name>com.sun.faces.ClientStateSavingPassword</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value>
</env-entry>

但是，这仍然不影响 AES 密钥，从 2.0.4 开始更改，它仍然基本上只启用/禁用加密.

However, this still doesn't affect the AES key, which was changed since 2.0.4, it still basically only enables/disables the encryption.

在 Mojarra 2.2.0 - 2.3.x 中，作为 JSF 2.2 规范(第 7.8.2 章)，客户端状态现在默认为 总是 加密.它只会在 web.xml 上下文参数 com.sun.faces.disableClientStateEncryption 设置为 真的.它 仍然 使用带有 完全随机密钥.JNDI 条目 com.sun.faces.ClientStateSavingPassword 现在不再使用.

In Mojarra 2.2.0 - 2.3.x, as part of JSF 2.2 specification (chapter 7.8.2), client side state is now by default always encrypted. It will only be disabled when web.xml context parameter com.sun.faces.disableClientStateEncryption is set with value true. It still uses AES algorithm with a completely random key. The JNDI entry com.sun.faces.ClientStateSavingPassword is now not used anymore.

在 Mojarra 2.2.6 - 2.3.x 中，他们根据 issue 3087 一个新的 JNDI 条目，它允许您以 Base64 编码格式指定 AES 密钥，jsf/ClientSideSecretKey.这是在集群环境中使用 JSF webapp 时客户端状态失败的错误修复的一部分，因为每个服务器使用不同的 AES 密钥，这只会导致 ERROR: MAC did not verify! 当状态在与保存状态的服务器不同的服务器中恢复，如 issue 2557 中所述.

In Mojarra 2.2.6 - 2.3.x, they added as per issue 3087 a new JNDI entry which allows you to specify the AES key in Base64 encoded format, the jsf/ClientSideSecretKey. This is part of the bugfix on failing client side state when a JSF webapp is used in cluster environment, because each server used a different AES key which would only cause a ERROR: MAC did not verify! when state is restored in a different server than the one which saved the state, as described in issue 2557.

<env-entry>
    <env-entry-name>jsf/ClientSideSecretKey</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>[AES key in Base64 format]</env-entry-value>
</env-entry>

您可以使用这个 AES 密钥生成器来生成一个(刷新页面重新生成)，或使用以下代码段生成您自己的 Base64 编码的 AES256 密钥:

You can use this AES key generator to generate one (refresh the page to regenerate), or use below snippet to generate your own Base64-encoded AES256 key:

KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256); // Use 128 for AES128 (when server don't have JCE installed).
String key = Base64.getEncoder().encodeToString(keyGen.generateKey().getEncoded());
System.out.println(key); // Prints AES key in Base64 format.

这篇关于com.sun.faces.ClientStateSavingPassword - 实际密码的建议?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！