ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (Closed) (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (WSS-66) Possible security hole when PasswordDigest is used by client.
Date Mon, 03 Oct 2011 09:04:37 GMT

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

Colm O hEigeartaigh closed WSS-66.
----------------------------------

    
> 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
>            Assignee: Fred Dushin
>             Fix For: 1.5.4
>
>         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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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


Mime
View raw message