[jboss-jira] [JBoss JIRA] (AS7-5915) HTTP Digest Fails when cnonce is Repeated

[Adam Halbardier (JIRA)]

    [ https://issues.jboss.org/browse/AS7-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733218#comment-12733218 ] 

Adam Halbardier commented on AS7-5915:
--------------------------------------

After some additional digging, I think the issue exists in org.apache.catalina.authenticator.DigestAuthenticator. Specifically, in DigestInfo.validate()

                long count;
                try {
                    count = Long.parseLong(nc, 16);
                } catch (NumberFormatException nfe) {
                    return false;
                }
                NonceInfo info;
                synchronized (cnonces) {
                    info = cnonces.get(cnonce);
                }
                if (info == null) {
                    info = new NonceInfo();
                } else {
                    if (count <= info.getCount()) {
                        return false;
                    }
                }

Notice how the nc is associated with the cnonce. This code requires that if a cnonce has previously been seen, then the nc must be greater than the last nc that had that cnonce. The correct interpretation of the RFC would be to associate nc with nonce. If the nonce value on the request has already been seen, then the nc on the request must be greater than the previous nc associated with that nonce value. From RFC 2716: "The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request."

While the fix seems trivial (change the Map to use the nonce instead of cnonce as the key), I don't have JBoss downloaded and built, so I'll leave that to whoever picks up this issue.

Thanks! Cheers...
                
> HTTP Digest Fails when cnonce is Repeated
> -----------------------------------------
>
>                 Key: AS7-5915
>                 URL: https://issues.jboss.org/browse/AS7-5915
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.1.1.Final
>         Environment: Windows 7
>            Reporter: Adam Halbardier
>            Assignee: Remy Maucherat
>
> HTTP digest authentication requests seem to fail when the cnonce from the browser is repeated across multiple requests. (Firefox often does this.) For example:
> 1) Request resource protected by HTTP digest authentication
> 2) Receive response with header: WWW-Authenticate=Digest realm="helios", qop="auth", nonce="1352490667388:dbdb24005a909963fabb3fd5e18711a9", opaque="Yy4sDZbcknyS26MFy7VH2tfm"
> 3) Send auth request with header: authorization=Digest username="helios", realm="helios", nonce="1352490667388:dbdb24005a909963fabb3fd5e18711a9", uri="/rest-services/rs/architecture/ui/waveforms", response="b4900878b8ffdf49e8216d706420871e", opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001, cnonce="082c875dcb2ca740"
> 4) Receive an HTTP 200
> 5) Close Firefox
> 6) Open Firefox and send request to same resource
> 7) Receive response with header: WWW-Authenticate=Digest realm="helios", qop="auth", nonce="1352490696962:b2318fc8d36fda0a46e9b8b4de62c597", opaque="Yy4sDZbcknyS26MFy7VH2tfm"
> 8) Send request with header: authorization=Digest username="helios", realm="helios", nonce="1352490696962:b2318fc8d36fda0a46e9b8b4de62c597", uri="/rest-services/rs/architecture/ui/waveforms", response="03c3ee574d29c7ce911b645b9a4e7f0c", opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001, cnonce="082c875dcb2ca740"
> 9) Receive an HTTP 401 with header: WWW-Authenticate=Digest realm="helios", qop="auth", nonce="1352490703289:9ce53cff6e7ba74f12b8d440bd4ec04c", opaque="Yy4sDZbcknyS26MFy7VH2tfm"
> 10) Send request with header: authorization=Digest username="helios", realm="helios", nonce="1352490703289:9ce53cff6e7ba74f12b8d440bd4ec04c", uri="/rest-services/rs/architecture/ui/waveforms", response="43acf50b9a019c9c26464e5cd43b0942", opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001, cnonce="1522e61005789929"
> 11) Receives HTTP 200
> Notice that the cnonce in the first and second auth requests are the same. In the third the cnonce changes and the auth request is accepted. This pattern is repeatable over and over again (sometimes the cnonce does not change for many attempts, all of which fail, but as soon as the browser changes it, the request succeeds). In all cases, the response is computed correctly. This behavior does not appear consistent with RFC 2617 (it's acceptable to repeat the nc and cnonce values across different 401 challenges). Further investigation found that when the 401 is returned in the second case, the storeDigestCallback is never executed, suggesting the failure happens before the response digest is ever evaluated.
> This is the security domain configuration in standalone.xml
>                 <security-domain name="helios" cache-type="default">
>                     <authentication>
>                         <login-module code="UsersRoles" flag="required">
>                             <module-option name="usersProperties" value="${jboss.server.config.dir}/helios-users.properties"/>
>                             <module-option name="rolesProperties" value="${jboss.server.config.dir}/helios-roles.properties"/>
>                             <module-option name="hashAlgorithm" value="MD5"/>
>                             <module-option name="hashEncoding" value="RFC2617"/>
>                             <module-option name="hashUserPassword" value="false"/>
>                             <module-option name="hashStorePassword" value="true"/>
>                             <module-option name="passwordIsA1Hash" value="true"/>
>                             <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira