You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2008/04/11 20:50:05 UTC

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

    [ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588073#action_12588073 ] 

Fred Dushin commented on WSS-66:
--------------------------------

Patch applied.

> 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, wss4j_wss66_revised.patch
>
>
> 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