2015-01-30 2 views
7

На всех ссылочных страницах, которые я нашел в отношении шифрования ViewState, единственным комментарием пароля является «ваш пароль здесь».com.sun.faces.ClientStateSavingPassword - рекомендации для фактического пароля?

Существуют ли какие-либо рекомендации относительно длины/сложности пароля, который мы должны использовать?

ответ

16

Зависит от версии Mojarra. В предыдущих версиях он имел несколько недостатков/сбоев.

В Mojarra 1.2.x - 2.1.18, он никогда не использовался. Имя записи JNDI было неправильно документировано. Это был documented как com.sun.faces.ClientStateSavingPassword (с таким же префиксом, как Mojarra's other web.xml context parameters), но код actually проверяет на ClientStateSavingPassword. Затем вы должны зарегистрировать его на этом имени.

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

В противном случае состояние клиента фактически не зашифрованы.

В Mojarra 1.2.x - 2.0.3, пароль will быть использован в качестве SecureRandom seed для создания DES algorithm key. Поэтому, как правило, применяются те же правила, что и для "real world" passwords. Только это может быть легко compromised, если пароль «слишком прост», и злоумышленник успешно угадывает/bruteforces/рисует пароль.

В Mojarra 2.0.4 - 2.1.x, они changed алгоритм из DES для AES и код теперь не actually использовать предоставленный пароль больше для генерации ключа (для предотвращения возможных comprisions). Вместо этого, полностью случайный ключ generated, который более безопасен. Теперь запись JNDI в основном контролирует, следует ли зашифровать состояние клиента или нет. Другими словами, он ведет себя теперь как логическая запись конфигурации. Таким образом, совершенно не важно, какой пароль вы используете.

<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, они fixed код для согласования документации по имени записи JNDI. Таким образом, вы могли бы использовать документированный JNDI имя входа:

<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, она до сих пор в основном только включает/отключает шифрование.

В Mojarra 2.2.0 - 2.3.x, как часть JSF 2.2 specification (глава 7.8.2), на стороне клиента состояние теперь по умолчанию always зашифрован. Он будет отключен только тогда, когда параметр web.xml контекста com.sun.faces.disableClientStateEncryption установлен со значением true. Он still использует алгоритм AES с completely random key. Запись JNDI com.sun.faces.ClientStateSavingPassword сейчас не используется больше.

В Mojarra 2.2.6 - 2.3.x, они добавили в соответствии issue 3087 новую запись JNDI, которая позволяет указать ключ AES в Base64 закодированном формате, the jsf/ClientSideSecretKey.Это является частью исправления при сбое состояния клиента, когда в среде кластера используется веб-приложение JSF, поскольку каждый сервер использовал другой ключ AES, который вызывал бы только ERROR: MAC did not verify!, когда состояние восстанавливается на другом сервере, чем тот, который сохранил состояние , как описано в 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 key generator, чтобы сгенерировать (обновить страницу, чтобы восстановить), или использовать ниже фрагмент кода, чтобы создать свой собственный Base64 закодирован AES256 ключа:

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. 
+0

О окончательном, как я мог надеяться для :) Я пойду проверю, какая версия работает - спасибо. У меня осталось 16 часов, пока я не смогу присудить награду, поэтому я отправлю ее на этот ответ. –

+0

Добро пожаловать. Вы также можете просто подождать, пока истечет срок награды. Как правило, у вас больше шансов на upvotes в последний день щедрости (так как этот вопрос затем плавает в верхней части списка «признакам»), таким образом вы можете вернуть очки. – BalusC

+0

Учитывая, что я знаю, что он не был зашифрован раньше, и что он использовал 'com.sun.faces.ClientStateSavingPassword', кажется вероятным, что я попадаю в блок 2.1.19 - 2.1.x. Мы находимся в кластерной среде - вероятно, у меня возникнут проблемы с разными ключами AES, которые будут использоваться на каждом сервере? –

Смежные вопросы