Title: Nachricht
|
Rami,
do I
understand correctly that the problem is mainly the error/reject message? If so,
then
you
are right: it should be the same message in both cases so that a potential "bad
guy"
cannot
see if the password is wrong or if no such user exists.
If
this is the main problem then IMO we can find a solution that is consistent
with
the
patch for WSFX-34.
Regards,
Werner
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:[email protected]]
Gesendet: Montag, 20. Dezember 2004 19:19
An: [email protected]
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
|
