Security hole in example password handler code?

[Dustin Henson <dh...@sddpc.org>]

I think I've discovered a security hole in the example code for handling digested passwords. The examples do not check the type of the password. If the caller sends a clear text password instead of digested, then the setPassword() call is ignored and WSDoAllReceiver accepts ANY password.

Am I off base? Can anyone else confirm this? It seems to be due to the handler only checking digested passwords as discussed in bug WSS-25(http://issues.apache.org/jira/browse/WSS-25). This bug was closed as Won't Fix, so I assume that this issue was not realized at the time (or that I am wrong).

Initially I tried to fix it by checking the password type and throwing an error, but for digested passwords getPasswordType() returns a null. Benjamin Pieritz responded to my original post with the helpful advice that pc.getPassword() && pc.getPasswordType() are not null if "PasswordText" is used. I am implementing this check in my code now.

A possible fix:
I think the addition of the following methods would fix the problem while still being compatible with existing code.
    handlerChecked() -  Returns true if the callback handler is required to check the password.
    passwordAccepted(boolean) - The callback handler calls this to indicate that the password is correct. If it is not called then the password is rejected.

Since passwordAccepted() is not called in existing implementations then they would reject clear text passwords.

-Dustin




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