JasyptStringDigester с SHA2 внезапно становится очень медленным

Question

В моем веб-приложении пароли входа хэшируются и сохраняются с помощью JasyptStringDigester с SHA256. Во время входа в систему пароль вводится пользователем с помощью одного и того же варочного котла для сравнения.

Однако после того, как приложение работает около 2 дней, вход в систему становится очень медленным. Как только это произойдет, я должен перезагрузить сервер для восстановления.

С дампом нити я узнал, что замедление вызвано работой варочного котла и оно использует ресурсы ЦП. Я попытался изменить поставщика JCE от дефолтного до bouncycastle, но это не помогло.

Я также проверил использование momery в JVM, когда эта проблема возникает, но их много.

Окружающая среда:

JDK 7u60

JBoss 7.1.1 Окончательный

конфигурации Метантенк (используется в качестве одноэлементного):

<bean id="jasyptStringDigester" class="org.jasypt.digest.StandardStringDigester"> 
 
\t \t <property name="provider" ref="bouncyCastleProvider" /> 
 
      <property name="algorithm" value="SHA-256" /> 
 
      <property name="iterations" value="100000" /> 
 
      <property name="saltGenerator"> 
 
       <bean id="zeroSaltGenerator" class="org.jasypt.salt.ZeroSaltGenerator"/> 
 
      </property> 
 
      <property name="saltSizeBytes" value="10"/> 
 
</bean> 
 

 
    
 
<bean id="bouncyCastleProvider" class="org.bouncycastle.jce.provider.BouncyCastleProvider"/>

свалка

Тема:

\t "ajp--10.88.90.34-8009-22" daemon prio=10 tid=0x00007ff2100ad800 nid=0xc7e runnable [0x00007ff1a9ae4000] 
 
    java.lang.Thread.State: RUNNABLE 
 
     at org.bouncycastle.crypto.digests.SHA256Digest.Sum0(Unknown Source) 
 
     at org.bouncycastle.crypto.digests.SHA256Digest.processBlock(Unknown Source) 
 
     at org.bouncycastle.crypto.digests.GeneralDigest.finish(Unknown Source) 
 
     at org.bouncycastle.crypto.digests.SHA256Digest.doFinal(Unknown Source) 
 
     at org.bouncycastle.jcajce.provider.digest.BCMessageDigest.engineDigest(Unknown Source) 
 
     at java.security.MessageDigest.digest(MessageDigest.java:353) 
 
     at java.security.MessageDigest.digest(MessageDigest.java:399) 
 
     at org.jasypt.digest.StandardByteDigester.digest(StandardByteDigester.java:979) 
 
     - locked <0x0000000748e4a9c0> (a org.bouncycastle.jcajce.provider.digest.SHA256$Digest) 
 
     at org.jasypt.digest.StandardByteDigester.digest(StandardByteDigester.java:933)

Будет ли кто-нибудь помочь, пожалуйста? Я давно застрял в этой проблеме. Аналогичная проблема была обнаружена в https://bugs.openjdk.java.net/browse/JDK-8023983, но я не нашел никакого решения.

Спасибо.

Answer 1

Какая операционная система?

Если это Linux, то после его замедления взгляните на доступную энтропию (cat /proc/sys/kernel/random/entropy_avail). Если это число меньше 250 или около того, вам нужно больше случайности в системе. Это распространенная проблема на серверах. Сетевой трафик или диск ввода-вывода могут помочь.

Чтобы затруднить диагностику, вы можете получить небольшую скорость при входе в систему. Это связано с тем, что сам журнал генерирует некоторый сетевой трафик, который помогает добавить некоторую случайность в пул энтропии. С другой стороны, SSHing в ящик может быть болезненно медленным, так как ему нужна некоторая случайность для ключей сеанса SSH. В любом случае (ускорение после входа в систему или медленный вход в систему) энтропия является вероятной проблемой.

Вы можете рассмотреть возможность добавления дополнительных источников случайности, таких как haveged или rng-tools.

Возможно, вы увидите предложения скопировать некоторую «случайность» от /dev/urandom до /dev/random, которая появится, чтобы устранить проблему. Но /dev/urandom на самом деле не имеет случайности, это просто PRNG, засеянный случайностью. Таким образом, это просто позволяет избежать проблемы, поставив под угрозу безопасность криптона, которую вы используете. Просто сказать нет.

Answer 2

У меня была точно такая же проблема, энтропия не причина. SHA256 дайджест не нужен случайным образом.Проблема заключается в механизме компиляции JIT (Just in time), который позволяет скомпилировать некоторую функцию Hotspot непосредственно в собственном коде. В JDK7 есть известная проблема: http://www.oracle.com/technetwork/java/javase/documentation/javase7supportreleasenotes-1601161.html, которая отключает собственный компилятор, когда кеш кода заполнен. В этом случае дайджест SHA не выполняется изначально и становится очень длинным!

Чтобы воспроизвести просто отключить компилятор:

-Djava.compiler=NONE 

Решение перейти на Java 8, обходной путь для Java 7 является увеличение размера CodeCache в соответствии с вашими потребностями, используя опцию JVM.

-XX:ReservedCodeCacheSize=300m

Вы можете контролировать свой кэш кода через JConsole:

Я надеюсь, что это поможет :)

Эрик