Shiro
  1. Shiro
  2. SHIRO-183

Unable to correctly extract the Initialization Vector or ciphertext

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.1.0
    • Component/s: Subject
    • Labels:
      None
    • Environment:
      GNU/Linux Debian Lenny, Java 1.6

      Description

      I obtain following exception while entering the secure page:

      [java] 101637 [http-8080-1] WARN org.apache.shiro.mgt.DefaultSecurityManager - Delegate RememberMeManager instance of type [org.apache.shiro.web.mgt.CookieRememberMeManager] threw an exception during getRememberedPrincipals().
      [java] org.apache.shiro.crypto.CryptoException: Unable to correctly extract the Initialization Vector or ciphertext.
      [java] at org.apache.shiro.crypto.JcaCipherService.decrypt(JcaCipherService.java:381)
      [java] at org.apache.shiro.mgt.AbstractRememberMeManager.decrypt(AbstractRememberMeManager.java:491)
      [java] at org.apache.shiro.mgt.AbstractRememberMeManager.convertBytesToPrincipals(AbstractRememberMeManager.java:431)
      [java] at org.apache.shiro.mgt.AbstractRememberMeManager.getRememberedPrincipals(AbstractRememberMeManager.java:398)
      [java] at org.apache.shiro.mgt.DefaultSecurityManager.getRememberedIdentity(DefaultSecurityManager.java:567)
      [java] at org.apache.shiro.mgt.DefaultSecurityManager.resolvePrincipals(DefaultSecurityManager.java:434)
      [java] at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:335)
      [java] at org.apache.shiro.subject.Subject$Builder.buildSubject(Subject.java:819)
      [java] at org.apache.shiro.web.subject.WebSubject$Builder.buildWebSubject(WebSubject.java:149)
      [java] at org.apache.shiro.web.servlet.AbstractShiroFilter.createSubject(AbstractShiroFilter.java:202)
      [java] at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:269)
      [java] at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:83)
      [java] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      [java] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      [java] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
      [java] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
      [java] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
      [java] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
      [java] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      [java] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
      [java] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
      [java] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
      [java] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
      [java] at java.lang.Thread.run(Thread.java:619)
      [java] Caused by: java.lang.ArrayIndexOutOfBoundsException
      [java] at java.lang.System.arraycopy(Native Method)
      [java] at org.apache.shiro.crypto.JcaCipherService.decrypt(JcaCipherService.java:373)
      [java] ... 23 more

      Of course I have set the "securityManager.rememberMeManager.cipherKey" in shiro.ini but it did not help.

      kind regards.

      1. shiro.ini
        1 kB
        RynekMedyczny.pl

        Activity

        Hide
        Les Hazlewood added a comment -

        Hi there,

        It is quite possible this is not be a bug - this can happen if a remember me cookie was created before upgrading to Shiro 1.0.0 and then the same cookie was read during a request after the upgrade. Or it can happen if a remember me cookie was created when securityManager.rememberMeManager.cipherService.generateInitializationVectors = false and then it was set to true at a later time, the read cookie would fail to be decrypted.

        Odds are very high the first scenario occurred and caused you to see these warning messages. If so, you can completely ignore these warnings - the next time a user logs in, the faulty cookie will be deleted and reset with a new (correct) one.

        Setting a cipherKey is recommended to ensure that no-one else can decrypt your data (instead of using the default cipherKey which can known since Shiro's source code is readily available). The cipherKey itself has nothing to do with how the initialization vector is generated or read, so setting the key, while still a good thing to do, won't make this warning go away.

        If you still think this is a bug, do you have a test case to verify the issue? It is impossible for us to track down the issue unless we can re-create it.

        Show
        Les Hazlewood added a comment - Hi there, It is quite possible this is not be a bug - this can happen if a remember me cookie was created before upgrading to Shiro 1.0.0 and then the same cookie was read during a request after the upgrade. Or it can happen if a remember me cookie was created when securityManager.rememberMeManager.cipherService.generateInitializationVectors = false and then it was set to true at a later time, the read cookie would fail to be decrypted. Odds are very high the first scenario occurred and caused you to see these warning messages. If so, you can completely ignore these warnings - the next time a user logs in, the faulty cookie will be deleted and reset with a new (correct) one. Setting a cipherKey is recommended to ensure that no-one else can decrypt your data (instead of using the default cipherKey which can known since Shiro's source code is readily available). The cipherKey itself has nothing to do with how the initialization vector is generated or read, so setting the key, while still a good thing to do, won't make this warning go away. If you still think this is a bug, do you have a test case to verify the issue? It is impossible for us to track down the issue unless we can re-create it.
        Hide
        RynekMedyczny.pl added a comment -

        1) Negative - It is my first time when I use Shiro
        2) Negative - I have not changed any of the properties connected with "securityManager.rememberMeManager.cipherService.generateInitializationVectors"
        3) It happens all the time when I try to log in.

        Kind regards

        Show
        RynekMedyczny.pl added a comment - 1) Negative - It is my first time when I use Shiro 2) Negative - I have not changed any of the properties connected with "securityManager.rememberMeManager.cipherService.generateInitializationVectors" 3) It happens all the time when I try to log in. Kind regards
        Hide
        Les Hazlewood added a comment -

        Ok, good - this should be easy to reproduce.

        Could you please use one of Shiro's sample web applications and change the shiro.ini configuration to replicate your issue? If you can do that, I can use that shiro.ini to create a test case.

        Show
        Les Hazlewood added a comment - Ok, good - this should be easy to reproduce. Could you please use one of Shiro's sample web applications and change the shiro.ini configuration to replicate your issue? If you can do that, I can use that shiro.ini to create a test case.
        Hide
        RynekMedyczny.pl added a comment -

        I have cleared all cookies and the warning stopped occurring.
        The question is - why the cookie was not replaced if it was invalid?
        And another one - why don't you provide clear message about the cause of the problem instead of that ugly exception?

        Kind regards

        Show
        RynekMedyczny.pl added a comment - I have cleared all cookies and the warning stopped occurring. The question is - why the cookie was not replaced if it was invalid? And another one - why don't you provide clear message about the cause of the problem instead of that ugly exception? Kind regards
        Hide
        Les Hazlewood added a comment -

        Those are two good questions, and ones that we could address in the form of adding them as new features to the codebase

        Thanks so much for verifying that the cleared cookies solved this problem - that confirms my assumptions in my first comment above. We can now use this information as the basis for implementing the two changes you recommended.

        We'll use this issue to implement those two changes.

        Thanks,

        Les

        Show
        Les Hazlewood added a comment - Those are two good questions, and ones that we could address in the form of adding them as new features to the codebase Thanks so much for verifying that the cleared cookies solved this problem - that confirms my assumptions in my first comment above. We can now use this information as the basis for implementing the two changes you recommended. We'll use this issue to implement those two changes. Thanks, Les
        Hide
        RynekMedyczny.pl added a comment -

        Thank you so much.

        One more thing - these exceptions keep occurring after each redeploy of my application.

        Kind regards.

        Show
        RynekMedyczny.pl added a comment - Thank you so much. One more thing - these exceptions keep occurring after each redeploy of my application. Kind regards.
        Hide
        Les Hazlewood added a comment -

        That shouldn't be happening if you clear out the cookies at least once, like you already have.

        Can you please attach a version of shiro.ini that replicates this issue? We really should have a test case for what you're experiencing - beyond just changing an exception message and removing the cookie.

        Show
        Les Hazlewood added a comment - That shouldn't be happening if you clear out the cookies at least once, like you already have. Can you please attach a version of shiro.ini that replicates this issue? We really should have a test case for what you're experiencing - beyond just changing an exception message and removing the cookie.
        Hide
        RynekMedyczny.pl added a comment -

        Here you are

        Show
        RynekMedyczny.pl added a comment - Here you are
        Hide
        Les Hazlewood added a comment -

        Thanks!

        Show
        Les Hazlewood added a comment - Thanks!
        Hide
        Kalle Korhonen added a comment -

        Les - are you working on this? This just popped up in one of the Tapestry-based apps I'm involved with. I could take this if you are not claiming first dibs.

        Show
        Kalle Korhonen added a comment - Les - are you working on this? This just popped up in one of the Tapestry-based apps I'm involved with. I could take this if you are not claiming first dibs.
        Hide
        Les Hazlewood added a comment -

        Nope, I'm not working on this at the moment. I still don't know exactly what the problem is - this should only happen when changing the cipher key or if the data serialized is an older serialization format than what the runtime environment reflects. Are you trying to solve why this occurs? Or clean up the code so that the cookie is removed upon seeing a failure? Or both?

        Show
        Les Hazlewood added a comment - Nope, I'm not working on this at the moment. I still don't know exactly what the problem is - this should only happen when changing the cipher key or if the data serialized is an older serialization format than what the runtime environment reflects. Are you trying to solve why this occurs? Or clean up the code so that the cookie is removed upon seeing a failure? Or both?
        Hide
        Kalle Korhonen added a comment -

        Assigned to myself. We know it occurs so the immediate priority is to resolve that. I may clean up the code as I go or leave it for another issue.

        Show
        Kalle Korhonen added a comment - Assigned to myself. We know it occurs so the immediate priority is to resolve that. I may clean up the code as I go or leave it for another issue.
        Hide
        Les Hazlewood added a comment -

        Sounds good to me!

        Show
        Les Hazlewood added a comment - Sounds good to me!
        Hide
        RynekMedyczny.pl added a comment -

        This exception seriously disturbs our development work!
        It occurs several times per page view (our logs are full of it) and causes that recognising real exceptions is realy hard!
        I think that this is a major flaw...

        Show
        RynekMedyczny.pl added a comment - This exception seriously disturbs our development work! It occurs several times per page view (our logs are full of it) and causes that recognising real exceptions is realy hard! I think that this is a major flaw...
        Hide
        Kalle Korhonen added a comment -

        I can easily reproduce the issue with a unit test (you'll get the same stack trace whenever the ciphertext is shorter than the initialization vector size). However, it's just a warning and the code is doing it right in my opinion. Rynek, if you just want to get rid of the log message, you can easily configure your logging system to squelch just that warning. However, if you want to help, can you answer the following questions:

        • Have you tried with 1.1.0-SNAPSHOT and if so, do you get the same warning? (I'm not able to reproduce this myself in a web app)
        • Are you simultaneously developing some other web applications and/or using cookie named rememberMe?(you'd easily run into the same exception in that case)
        • Have you tried different browsers (there's the remote chance that a particular browser is truncating the cookie value)
        Show
        Kalle Korhonen added a comment - I can easily reproduce the issue with a unit test (you'll get the same stack trace whenever the ciphertext is shorter than the initialization vector size). However, it's just a warning and the code is doing it right in my opinion. Rynek, if you just want to get rid of the log message, you can easily configure your logging system to squelch just that warning. However, if you want to help, can you answer the following questions: Have you tried with 1.1.0-SNAPSHOT and if so, do you get the same warning? (I'm not able to reproduce this myself in a web app) Are you simultaneously developing some other web applications and/or using cookie named rememberMe?(you'd easily run into the same exception in that case) Have you tried different browsers (there's the remote chance that a particular browser is truncating the cookie value)
        Hide
        Peng Wong added a comment -

        This problem bothers me as well. SHIRO 1.1-SNAPSHOT Plugin with Grails 1.3.5, JDK1.6_20 on OSX and Centos Linux, using Safari 5 to browse.

        Show
        Peng Wong added a comment - This problem bothers me as well. SHIRO 1.1-SNAPSHOT Plugin with Grails 1.3.5, JDK1.6_20 on OSX and Centos Linux, using Safari 5 to browse.
        Hide
        Kalle Korhonen added a comment -

        Thanks Peng. Can you please please verify the following:

        • Are you using the latest Shiro 1.1.0-SNAPSHOT (i.e. not the -incubating one)?
        • Do you get the same results with different browsers? (e.g. Firefox, Konqueror)?
        • What's approximate length of the rememberMe cookie value, i.e. does it look short?

        I'm scrambling to find somebody to follow up on this since I cannot seem to reproduce it myself - I've tried it on Windows and FC11 Linux with no exceptions. I'm guessing the root cause is that something along the way is truncating the cookie value, but since I can't verify that myself I'm forced to rely on feedback from others.

        Show
        Kalle Korhonen added a comment - Thanks Peng. Can you please please verify the following: Are you using the latest Shiro 1.1.0-SNAPSHOT (i.e. not the -incubating one)? Do you get the same results with different browsers? (e.g. Firefox, Konqueror)? What's approximate length of the rememberMe cookie value, i.e. does it look short? I'm scrambling to find somebody to follow up on this since I cannot seem to reproduce it myself - I've tried it on Windows and FC11 Linux with no exceptions. I'm guessing the root cause is that something along the way is truncating the cookie value, but since I can't verify that myself I'm forced to rely on feedback from others.
        Hide
        Borut Bolcina added a comment -

        I am using tapestry-security-0.2.0 which is dependent on shiro-web-1.0.0-incubating.

        The url with a login form looks like http://localhost:8080/security/login;jsessionid=3gy546y02uhnw8p05i3kvs2p
        There are no cookies for localhost in the firefox 3.6.10 browser.
        Remember me checkbox is NOT ticked. I hit the Enter button, I got logged in AND the rememberMe cookie with default valaue (deleteMe) gets written (18 bytes).

        Now when I click the logout link I get the familiar waning message:
        [WARN] 21:37:57,885 org.apache.shiro.mgt.DefaultSecurityManager Delegate RememberMeManager instance of type [org.apache.shiro.web.mgt.CookieRememberMeManager] threw an exception during getRememberedPrincipals().
        org.apache.shiro.crypto.CryptoException: Unable to correctly extract the Initialization Vector or ciphertext.
        at org.apache.shiro.crypto.JcaCipherService.decrypt(JcaCipherService.java:381)
        ...

        This is 100% repeatable.

        If you now want to login again, the warning appears again. So it seem only if the rememberMe cookie is not present the warnings do not show up.

        I battle the plagued logs with:
        log4j.logger.org.apache.shiro.mgt.DefaultSecurityManager=error

        The same applies for IE 8.

        Show
        Borut Bolcina added a comment - I am using tapestry-security-0.2.0 which is dependent on shiro-web-1.0.0-incubating. The url with a login form looks like http://localhost:8080/security/login;jsessionid=3gy546y02uhnw8p05i3kvs2p There are no cookies for localhost in the firefox 3.6.10 browser. Remember me checkbox is NOT ticked. I hit the Enter button, I got logged in AND the rememberMe cookie with default valaue (deleteMe) gets written (18 bytes). Now when I click the logout link I get the familiar waning message: [WARN] 21:37:57,885 org.apache.shiro.mgt.DefaultSecurityManager Delegate RememberMeManager instance of type [org.apache.shiro.web.mgt.CookieRememberMeManager] threw an exception during getRememberedPrincipals(). org.apache.shiro.crypto.CryptoException: Unable to correctly extract the Initialization Vector or ciphertext. at org.apache.shiro.crypto.JcaCipherService.decrypt(JcaCipherService.java:381) ... This is 100% repeatable. If you now want to login again, the warning appears again. So it seem only if the rememberMe cookie is not present the warnings do not show up. I battle the plagued logs with: log4j.logger.org.apache.shiro.mgt.DefaultSecurityManager=error The same applies for IE 8.
        Hide
        Kalle Korhonen added a comment -

        Very good, thanks Borut for the detailed error report. The deleteMe value will certainly cause this exception, I'll dig into it more. Any chance you could try with tapestry-security 0.3.0-SNAPSHOT (that'll pull in Shiro 1.1.0-SNAPSHOT). The tapestry-security snapshots are available from http://ci.repository.codehaus.org/org/tynamo/. In the meantime, I'll try out the scenario with those dependencies.

        Show
        Kalle Korhonen added a comment - Very good, thanks Borut for the detailed error report. The deleteMe value will certainly cause this exception, I'll dig into it more. Any chance you could try with tapestry-security 0.3.0-SNAPSHOT (that'll pull in Shiro 1.1.0-SNAPSHOT). The tapestry-security snapshots are available from http://ci.repository.codehaus.org/org/tynamo/ . In the meantime, I'll try out the scenario with those dependencies.
        Hide
        Kalle Korhonen added a comment -

        Ok, this does seem to be browser/platform dependent. I'm assuming that in some environments a browser may not immediately delete a cookie that is scheduled for removal but sends it back in the headers. Added a fix to address this specific case. Still cannot reproduce myself. Everybody interested, please re-test with the latest Shiro 1.1.0-SNAPSHOT and report back. Please also check that you don't have multiple "rememberMe" cookies, otherwise it may imply another issue with Shiro. Will close the issue if I don't hear further comments.

        Show
        Kalle Korhonen added a comment - Ok, this does seem to be browser/platform dependent. I'm assuming that in some environments a browser may not immediately delete a cookie that is scheduled for removal but sends it back in the headers. Added a fix to address this specific case. Still cannot reproduce myself. Everybody interested, please re-test with the latest Shiro 1.1.0-SNAPSHOT and report back. Please also check that you don't have multiple "rememberMe" cookies, otherwise it may imply another issue with Shiro. Will close the issue if I don't hear further comments.
        Hide
        Peng Wong added a comment -

        Thanks in advance. The 1.1-SNAPSHOT i'm using is a Grails Plugin, so i'll have to wait for that rebuilded. From my debugging the issue is that, wether or not the rememberMe feature ist turned on, a rememberMe Cookie is created with the value deleteMe. The MaxAge isn't set at all. It isn't deleted. So the decrypt function tries to decrypt the value "deleteMe", - don't know if that causes the excpetion?
        When i manually delete the cookie, everything is fine. But the Cookie with value 'deleteMe' (rememberME disabled) reappears. And the exception occurs again.
        I tried to replace the CookieRememberMeManager with my own one to hinder the cookie from beeing created, - but without that cookie SHIRO stopped working with a bunch of NullPointers. I'm not that deep in SHIRO nor grails...
        Despite of this exception i never got rememberMe to work. Maybe this is only a documentation issue - so i may have missed something? A working (for you) example would b helpful...

        regards from germany!

        Show
        Peng Wong added a comment - Thanks in advance. The 1.1-SNAPSHOT i'm using is a Grails Plugin, so i'll have to wait for that rebuilded. From my debugging the issue is that, wether or not the rememberMe feature ist turned on, a rememberMe Cookie is created with the value deleteMe. The MaxAge isn't set at all. It isn't deleted. So the decrypt function tries to decrypt the value "deleteMe", - don't know if that causes the excpetion? When i manually delete the cookie, everything is fine. But the Cookie with value 'deleteMe' (rememberME disabled) reappears. And the exception occurs again. I tried to replace the CookieRememberMeManager with my own one to hinder the cookie from beeing created, - but without that cookie SHIRO stopped working with a bunch of NullPointers. I'm not that deep in SHIRO nor grails... Despite of this exception i never got rememberMe to work. Maybe this is only a documentation issue - so i may have missed something? A working (for you) example would b helpful... regards from germany!
        Hide
        Borut Bolcina added a comment -

        Kalle, for some reason mavne can not download the 0.3.0-SNAPSHOT from the repo

        <repository>
        <releases>
        <enabled>false</enabled>
        </releases>
        <snapshots>
        <updatePolicy>daily</updatePolicy>
        <checksumPolicy>warn</checksumPolicy>
        </snapshots>
        <id>codehaus.ci</id>
        <name>Codehaus CI</name>
        <url>http://ci.repository.codehaus.org/org/tynamo/</url>
        </repository>

        it gives me

        9.10.10 11:11:50 CEST: [WARN] repository metadata for: 'snapshot org.tynamo:tapestry-security:0.3.0-SNAPSHOT' could not be retrieved from repository: codehaus.ci due to an error: Transfer error: null
        9.10.10 11:11:53 CEST: Missing artifact org.tynamo:tapestry-security:jar:0.3.0-SNAPSHOT:compile

        Tried several times, also with "frozen snapshot version" tapestry-security-0.3.0-20101008.094550-4 but with no luck. I will investigate later, as right now I do not have time.

        Show
        Borut Bolcina added a comment - Kalle, for some reason mavne can not download the 0.3.0-SNAPSHOT from the repo <repository> <releases> <enabled>false</enabled> </releases> <snapshots> <updatePolicy>daily</updatePolicy> <checksumPolicy>warn</checksumPolicy> </snapshots> <id>codehaus.ci</id> <name>Codehaus CI</name> <url> http://ci.repository.codehaus.org/org/tynamo/ </url> </repository> it gives me 9.10.10 11:11:50 CEST: [WARN] repository metadata for: 'snapshot org.tynamo:tapestry-security:0.3.0-SNAPSHOT' could not be retrieved from repository: codehaus.ci due to an error: Transfer error: null 9.10.10 11:11:53 CEST: Missing artifact org.tynamo:tapestry-security:jar:0.3.0-SNAPSHOT:compile Tried several times, also with "frozen snapshot version" tapestry-security-0.3.0-20101008.094550-4 but with no luck. I will investigate later, as right now I do not have time.
        Hide
        Kalle Korhonen added a comment -

        No, the repo is http://ci.repository.codehaus.org, I just added the org/tynamo as a supposedly helpful hint to find it in case you were not using Maven.

        Show
        Kalle Korhonen added a comment - No, the repo is http://ci.repository.codehaus.org , I just added the org/tynamo as a supposedly helpful hint to find it in case you were not using Maven.
        Hide
        Kalle Korhonen added a comment -

        I believe the root cause of the issue is that Max-Age attribute wasn't written at all (instead it was using non-standard Expires). Added and using both now, other checks left in place as well.

        Show
        Kalle Korhonen added a comment - I believe the root cause of the issue is that Max-Age attribute wasn't written at all (instead it was using non-standard Expires). Added and using both now, other checks left in place as well.
        Hide
        Les Hazlewood added a comment -

        Closing as this was released in 1.1.0

        Show
        Les Hazlewood added a comment - Closing as this was released in 1.1.0

          People

          • Assignee:
            Kalle Korhonen
            Reporter:
            RynekMedyczny.pl
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development