com.sun.xml.ws.security.impl.PasswordDerivedKey's generate160BitKey() not hardcoding use of UTF-8

[glassfishrobot]

Hi, we're testing interoperability between CXF and Metro w.r.t. UsernameToken password-derived keys (http://www.jroller.com/gmazza/entry/usernametoken_messagelayer_encryption). Dan Kulp of the CXF team noticed that PasswordDerivedKey's generate160BitKey() method is not hardcoding use of UTF-8 when calling password.getBytes(), it looks like it should be password.getBytes("UTF-8") instead, as getBytes() by itself is platform-dependent (http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#getBytes().

According to line 386 of the UsernameToken profile spec: http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf, the password is always UTF-8 encoded.

Environment

JDK 7 on Ubuntu Linux.

Affected Versions

[2.2.1-1]

[glassfishrobot]

Reported by gmazza

[glassfishrobot]

Was assigned to symonchang

[glassfishrobot]

symonchang said:
Same as #1663, UsernameToken auth w/password derived keys is not a prefer scenario in the real world. Use Encrypted UsernameToken is recommanded instead.

[glassfishrobot]

snajper said:
Symon, this as well appears well digested and simple to fix - could we address this? The scenario is one of the metro-default-defined ones, also exposed within NetBeans.

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-1662