[
https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-66:
-----------------------------------
Attachment: wss4j_wss66_revised.patch
Please see the attached for a (revised) patch for this problem. The original
patch has two issues:
1) No tests are included
2) The patch assumes that the processor should reject a UsernameToken if it is
missing either a Nonce or a Created element, but not if both are missing. As
this is a separate issue to the JIRA task in hand, it is more suitable that a
separate JIRA be created for this. In the meantime, it's better to stick with
the status quo, which incidentally conforms to the "recommended" approach in
the 1.1 spec - which is to reject an incoming UsernameToken with digested
password unless it has both Nonce and Created elements.
The revised patch fixes the (major) security hole in question + adds tests.
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
