Devs,
I've been looking at using a UsernameToken to derive a key to to "sign"
via HMAC some message content.
Both the UsernameTokenSignedAction (via the UT_SIGN action) and the
TestWSSecurityNew13 test deal with this functionality. There are two
problems. First of all, the Username Token that's created in both cases
with something like:
WSSecUsernameToken builder = new WSSecUsernameToken();
builder.setWsConfig(reqData.getWssConfig());
builder.setPasswordType(reqData.getPwType);
builder.setUserInfo(reqData.getUsername(), password);
builder.addCreated();
builder.addNonce();
still includes the password, which is a major security hole. This issue
was raised by Sergio here:
https://issues.apache.org/jira/browse/WSS-127
Secondly, the secret key to use with the HMAC is apparently derived
according to the WS-Trust spec, e.g. see the getSecretKey methods of:
http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/org/apache/ws/s
ecurity/message/token/UsernameToken.java?view=markup
IMO the default behaviour should instead be to use the
generateDerivedKey() method of UsernameToken, which is what is in the
UsernameToken Profile 1.1 specification. In other words, the
UsernameToken that's sent across the wire includes username, salt and
iteration values, which the receiving party can use with their password
to create a suitable secret key.
I would like to change the UsernameTokenSignedAction functionality to
comply with the U/T 1.1 spec, and also change the SignatureProcessor
functionality so that it calls to generateDerivedKey rather than
getSecretKey. Are there objections to this? Is anyone using this code?
Colm.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
