[jira] Updated: (WSS-66) Possible security hole when PasswordDigest is used by client.

["Steve LeGault (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve LeGault updated WSS-66:
-----------------------------

    Attachment: wss-66.diff

I believe I have a fix for this issue which also fixes the ability to generate a UsernameToken without Nonce/Created elements.  Attached is the diff.

On the receive side, UsernameTokenProcessor will throw an exception if only one of Nonce or created is present in the header.   If neither nonce or created are present, then the digest is performed on just the password.  If both are present, then the digest is performed on password + nonce + created (as before).

On the generation side, users of UsernameToken class add the nonce and created based on configuration (specifically the MessageContext parameters WSHandlerConstants.ADD_UT_ELEMENTS) - this diff differentiates the case of "straight PasswordDigest" and "PasswordDigest with Nonce/created elements" (previously PasswordDigest always generated Nonce/Created regardless of config)

I tested this with SoapUI and it behaves as intended.

I'm a newbie with no commit privleges - so either I can go through the excercise to get commit privleges or someone with commit priveleges can commit the patch.

> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
>                 Key: WSS-66
>                 URL: https://issues.apache.org/jira/browse/WSS-66
>             Project: WSS4J
>          Issue Type: Bug
>         Environment: Any
>            Reporter: Ever A. Olano
>         Attachments: wss-66.diff
>
>
> Hello.  I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL.  However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
>             if (nonce != null && createdTime != null) {
>                 String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
>                 if (!passDigest.equals(password)) {
>                     throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
>                 }
>             }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself).  Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org