Depends on Mojarra version. It had several flaws/fails in earlier versions.
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.
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.
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>
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>
However, this still doesn't affect the AES key, which was changed since 2.0.4, it still basically only enables/disables the encryption.
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.
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>
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.
