You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Dittmann Werner <we...@siemens.com> on 2004/12/21 08:51:40 UTC
AW: [jira] Updated: (WSFX-41) WSS4J accepts any username/password
if in text mode
Rami,
checked you proposed patch. However, I'm not sure if this
patch would be in contradiction of the patch we did for
the JIRA issue WSFX-34 (Usaername token handling). There
was also some discussion here on the mailing list about
the handling of plaintext passwords. The discussion took
place at August, 30th to September 2nd, the subject of the
thread was: "UsernameToken functionality in WSS4J". Can
you pls check if you patch is in-line with the findings
during that discussion?
Thanks.
Regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: Rami Jaamour (JIRA) [mailto:fx-dev@ws.apache.org]
> Gesendet: Montag, 20. Dezember 2004 19:19
> An: fx-dev@ws.apache.org
> Betreff: [jira] Updated: (WSFX-41) WSS4J accepts any
> username/password if in text mode
>
>
> [ http://nagoya.apache.org/jira/browse/WSFX-41?page=history ]
>
> Rami Jaamour updated WSFX-41:
> -----------------------------
>
> Attachment: WSSecurityEngine.java
> diff.txt
>
> I attached a possible fix for your review before I commit it
> please, because this seems like a major issue that requires
> more than one person's attention. I am also having it return
> a failed authentication if PWCallBack returned a null
> password for the given username to increase security so WSS4J
> does not reveal the fact that a username does not exist.
>
> > WSS4J accepts any username/password if in text mode
> > ---------------------------------------------------
> >
> > Key: WSFX-41
> > URL: http://nagoya.apache.org/jira/browse/WSFX-41
> > Project: WSFX
> > Type: Bug
> > Components: WSS4J
> > Environment: Linux
> > Reporter: Rami Jaamour
> > Priority: Critical
> > Attachments: WSSecurityEngine.java, diff.txt
> >
> > It appears to me that WSS4J is now letting requests with
> the wrong username/password pass through if the password was
> text (not digested)! Take a look at
> WSSecurityEngine.handleUsernameToken():
> > All the username and password stuff are wrapped in
> > if (ut.isHashed()) {
> > ...
> > }
> > but there is no case for when it is not hashed.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators:
> http://nagoya.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
Re: AW: [jira] Updated: (WSFX-41) WSS4J accepts any username/password
if in text mode
Posted by Rami Jaamour <rj...@parasoft.com>.
My patch is in fact not consistent with WSFX-34, but then what is the
recommended design for checking the usernames in the case of digested
passwords? I can see how PWCallback can be configured to return a
password given a WSPasswordCallback identifier (username), but I am not
sure where/how to handle invalid usernames. If I simply do not set the
password in PWCallback into bad usernames; example:
if (callbacks[i] instanceof WSPasswordCallback) {
WSPasswordCallback pc = (WSPasswordCallback) callbacks[i];
if ("wss4j".equals(pc.getIdentifer())) {
pc.setPassword("security");
}
} else {
throw new UnsupportedCallbackException(callbacks[i],
"Unrecognized Callback");
}
Then I get the service to reject unauthorized users, but the problem is
that the error message on bad usernames would be different than the one
on bad passwords, it would return
org.apache.ws.security.WSSecurityException: General security error
(WSSecurityEngine: Callback supplied no password for: wronguser
and I think that it should just return an "unauthorized" error message
(or whatever same error message) no matter if the username or the
password are wrong to prevent attackers from discovering valid usernames.
I understand that I can also get WSSecurityEngineResult in my
application and check the WSUsernameTokenPrincipal, but this way I would
have the checks in two different places (in PWCallback and in the
application) and still have the different error messages problem. Is
there another better way to do what I am trying?
Thanks,
Rami Jaamour
Software Engineer
Web Services Solutions
Parasoft Corporation
"We Make Software Work"
Dittmann Werner wrote:
>Rami,
>
>checked you proposed patch. However, I'm not sure if this
>patch would be in contradiction of the patch we did for
>the JIRA issue WSFX-34 (Usaername token handling). There
>was also some discussion here on the mailing list about
>the handling of plaintext passwords. The discussion took
>place at August, 30th to September 2nd, the subject of the
>thread was: "UsernameToken functionality in WSS4J". Can
>you pls check if you patch is in-line with the findings
>during that discussion?
>
>Thanks.
>
>Regards,
>Werner
>
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Rami Jaamour (JIRA) [mailto:fx-dev@ws.apache.org]
>>Gesendet: Montag, 20. Dezember 2004 19:19
>>An: fx-dev@ws.apache.org
>>Betreff: [jira] Updated: (WSFX-41) WSS4J accepts any
>>username/password if in text mode
>>
>>
>> [ http://nagoya.apache.org/jira/browse/WSFX-41?page=history ]
>>
>>Rami Jaamour updated WSFX-41:
>>-----------------------------
>>
>> Attachment: WSSecurityEngine.java
>> diff.txt
>>
>>I attached a possible fix for your review before I commit it
>>please, because this seems like a major issue that requires
>>more than one person's attention. I am also having it return
>>a failed authentication if PWCallBack returned a null
>>password for the given username to increase security so WSS4J
>>does not reveal the fact that a username does not exist.
>>
>>
>>
>>>WSS4J accepts any username/password if in text mode
>>>---------------------------------------------------
>>>
>>> Key: WSFX-41
>>> URL: http://nagoya.apache.org/jira/browse/WSFX-41
>>> Project: WSFX
>>> Type: Bug
>>> Components: WSS4J
>>> Environment: Linux
>>> Reporter: Rami Jaamour
>>> Priority: Critical
>>> Attachments: WSSecurityEngine.java, diff.txt
>>>
>>>It appears to me that WSS4J is now letting requests with
>>>
>>>
>>the wrong username/password pass through if the password was
>>text (not digested)! Take a look at
>>WSSecurityEngine.handleUsernameToken():
>>
>>
>>>All the username and password stuff are wrapped in
>>>if (ut.isHashed()) {
>>>...
>>>}
>>>but there is no case for when it is not hashed.
>>>
>>>
>>--
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the
>>administrators:
>> http://nagoya.apache.org/jira/secure/Administrators.jspa
>>-
>>If you want more information on JIRA, or have a bug to report see:
>> http://www.atlassian.com/software/jira
>>
>>
>>
>
>
>