Zależy od wersji Mojarra. Miał kilka wad/błędów we wcześniejszych wersjach.
W Mojarra 1.2.x - 2.1.18, nigdy nie była używana. Nazwa wpisu JNDI została niepoprawnie udokumentowana. Był to documented jako com.sun.faces.ClientStateSavingPassword
(z tym samym prefiksem, co Mojarra's other web.xml
context parameters), ale kod actually sprawdza dla . Powinieneś wtedy zarejestrować go na tej nazwie.
<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>
W przeciwnym razie, państwo klient jest faktycznie nie szyfrowane.
W Mojarra 1.2.x - 2.0.3, hasło will być stosowany jako SecureRandom
seed wygenerować DES algorithm key. Zasadniczo obowiązują te same zasady co w przypadku "real world" passwords. Tylko to może być łatwo compromised, jeśli hasło jest "zbyt łatwe", a osoba atakująca skutecznie odgaduje/bruteforces/oblicza hasło.
W Mojarra 2.0.4 - 2.1.x one changed algorytm DES z AES oraz kod teraz nie actually używać już dostarczonego hasła do wygenerowania klucza (aby zapobiec potencjalnym comprisions). Zamiast tego całkowicie losowy klucz to bardziej bezpieczny niż generated. Wpis JNDI kontroluje teraz w zasadzie, czy stan klienta powinien być zaszyfrowany, czy nie. Innymi słowy, zachowuje się teraz jak wpis konfiguracji boolowskiej. W związku z tym absolutnie nie ma znaczenia, którego hasła używasz.
<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>
W Mojarra 2.1.19 - 2.1.x one fixed kod, aby wyrównać dokumentacji dotyczącej wprowadzania nazwy JNDI. Więc można używać udokumentowanej JNDI nazwę aktu:
<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>
Jednak to nadal nie ma wpływu na klucz AES, który został zmieniony od 2.0.4, to jeszcze w zasadzie tylko włącza/wyłącza szyfrowanie.
W Mojarra 2.2.0 - 2.3.x, w ramach JSF 2.2 specification (rozdział 7.8.2), stan po stronie klienta jest teraz domyślnie always zaszyfrowanej. Zostanie wyłączony tylko wtedy, gdy parametr kontekstowy web.xml
zostanie ustawiony na wartość true
. To still wykorzystuje algorytm AES z completely random key. Wpis JNDI com.sun.faces.ClientStateSavingPassword
jest już używany nie.
W Mojarra 2.2.6 - 2.3.x, dodali zgodnie issue 3087 nowy wpis JNDI, który pozwala określić klucz AES w formacie Base64 zakodowane the jsf/ClientSideSecretKey
.Jest to część poprawki błędu w stanie awarii po stronie klienta, gdy aplikacja webowa JSF jest używana w środowisku klastrowym, ponieważ każdy serwer użył innego klucza AES, który spowodowałby tylko ERROR: MAC did not verify!
, gdy stan zostanie przywrócony na innym serwerze niż ten, który zapisał stan , jak opisano w 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>
Można użyć tej AES key generator wygenerować jeden (odśwież stronę, aby zregenerować) lub skorzystać z poniższego fragmentu kodu, aby wygenerować własny Base64 kodowanego AES256 klucz:
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.
O jako ostateczne jak mogę mieć nadzieję dla :) Sprawdzę dokładnie, która wersja działa - dziękuję. Mam 16 godzin, zanim mogę nagrodzić nagrodę, więc opublikuję ją w tej odpowiedzi. –
Nie ma za co. Możesz także poczekać, aż upłynie okres nagród. Ogólnie rzecz biorąc, masz największą szansę na awans w ostatnim dniu nagród (ponieważ to pytanie następnie pojawia się na górze listy "polecanych"), w ten sposób możesz odzyskać punkty. – BalusC
Biorąc pod uwagę, że wiem, że nie był on wcześniej szyfrowany i użył "com.sun.faces.ClientStateSavingPassword", wydaje mi się prawdopodobne, że wpadnę w blok 2.1.19 - 2.1.x. Jesteśmy w środowisku klastrowym - czy napotkasz problemy z różnymi kluczami AES używanymi na każdym serwerze? –