com.sun.faces.ClientStateSavingPassword - Empfehlungen für das tatsächliche Passwort?

Question

In allen Referenzseiten, die ich in Bezug auf die Verschlüsselung des ViewState gefunden habe, lautet der einzige Kommentar zum Passwort "Ihr Passwort hier".

Gibt es Empfehlungen hinsichtlich der Länge/Komplexität des zu verwendenden Passworts?

Answer 1

Hängt von der Mojarra-Version ab. In früheren Versionen hatte es einige Fehler.

In Mojarra 1.2.x - 2.1.18 wurde es nie wirklich verwendet. Der JNDI-Eintragsname wurde nämlich falsch dokumentiert. Es war documented als com.sun.faces.ClientStateSavingPassword (mit demselben Präfix wie Mojarra's other web.xml context parameters), aber der Code actually prüft auf ClientStateSavingPassword. Sie sollten es stattdessen auf diesen Namen registrieren.

<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> 

Andernfalls wird der Client-Zustand ist eigentlich nicht verschlüsselt.

In Mojarra 1.2.x - 2.0.3, will das Passwort als ein DES algorithm key zu erzeugen SecureRandom seed verwendet werden. Im Allgemeinen gelten die gleichen Regeln wie für "real world" passwords. Nur kann dies leicht compromised sein, wenn das Passwort "zu einfach" ist und der Angreifer das Passwort erfolgreich errät/bruteforces/faßt.

In Mojarra 2.0.4 - 2.1.x sie den Algorithmus von DER zu AES und den Code actually jetzt nicht verwenden, um das angegebene Passwort changed mehr den Schlüssel zu generieren (potenzielle comprisions zu verhindern). Stattdessen ist ein völlig zufälliger Schlüssel generated, der sicherer ist. Der JNDI-Eintrag steuert nun im Grunde, ob der Client-Status verschlüsselt werden soll oder nicht. Mit anderen Worten, es verhält sich jetzt wie ein boolescher Konfigurationseintrag. Es spielt also absolut keine Rolle mehr, welches Passwort Sie verwenden.

<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, fixed sie den Code in der Dokumentation zu JNDI Eintragsnamen auszurichten. So könnte man die dokumentierte JNDI Eintragsnamen verwenden:

<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> 

Dies ist jedoch immer noch nicht den AES-Schlüssel nicht beeinflusst, die seit 2.0.4 geändert wurde, ist es nach wie vor grundsätzlich nur aktiviert/deaktiviert die Verschlüsselung.

In Mojarra 2.2.0 - 2.3.x als Teil JSF 2.2 specification (Kapitel 7.8.2), Client-Seite-Zustand ist jetzt standardmäßig always verschlüsselt. Es wird nur deaktiviert, wenn der web.xml Kontextparameter com.sun.faces.disableClientStateEncryption mit dem Wert true festgelegt wird. Es still verwendet AES-Algorithmus mit einem completely random key. Der JNDI-Eintrag com.sun.faces.ClientStateSavingPassword wird jetzt nicht mehr verwendet.

In Mojarra 2.2.6 - 2.3.x, fügten sie per issue 3087 einen neuen JNDI Eintrag, den Sie den AES-Schlüssel in Base64 codierten Format angeben können, the jsf/ClientSideSecretKey.Dies ist Teil der bugfix auf andernfalls Client-Seite-Zustand, wenn ein JSF webapp in Cluster-Umgebung verwendet wird, da jeder Server einen anderen AES-Schlüssel verwendet, der nur ein ERROR: MAC did not verify! verursachen würde, wenn Zustand in einem anderen Server als der gestellt wird, die den Zustand gespeichert wie in issue 2557 beschrieben.

<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> 

Sie diese AES key generator kann eine (aktualisieren Sie die Seite zu regenerieren) zu erzeugen, oder unter Snippet verwenden, um Ihre eigenen Base64 zu generieren-codierte AES256 Schlüssel:

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.