Need ability to handle password "equivalent" between WSPasswordCallback and UsernameToken when it's binary data

[Jim Utter <ju...@gmail.com>]

Per the oasis spec, the UsernamePassword is summarized by the algorithm:
   base64(sha-1(nonce+created+password))

But, n our scenario we don't store cleartext passwords - only the sha-1 hash
of them.  The oasis spec allows this via what they claim as "..password
equivalent".  The problem I'm running into is that our password equivalent
is sha-1(password) or ultimately this equivalent:
   base64(sha-1(nonce+created+sha-1(password)))

When the applicability of this approach was questioned to the oasis list,
they confirmed it:
http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html

But, when using the wss4j WSPasswordCallback mechanism, the call expects the
password to be a string but the binary output of the digest if converted to
a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does
not result in the original byte array - causing any digest calculations to
fail.

Since I cannot change the framework, I was curious if there was a way to
supercede or register the UsernameToken class with my own so I can pass a
base64(sha-1(password)) through the current api's via the WSPasswordCallback
mechanism and have the custom UsernameToken class perform the base64 decode
to get the original binary bytes of the sha-1(password) we need to pass
through.

I'm also open to other suggestions and for additional context - I'm
attempting to use the spring-ws package as a client with a custom callback
handler like this:

    <bean id="securityClientInterceptor"
class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
        <property name="securementActions" value="UsernameToken"/>
        <property name="securementUsername" value="${username}"/>
        <property name="securementUsernameTokenElements" value="Nonce
Created"/>
        <property name="securementPasswordType" value="PasswordDigest"/>
        <property name="securementMustUnderstand" value="true"/>
        <property name="securementCallbackHandler">
            <!-- this will pre-hash the password with sha-1 before the
password is passed through wss4j -->
            <bean id="preHashedWSPasswordCallbackHandler"
class="xxx.xxx.xxx.PreHashedWSPasswordCallbackHandler">
                <property name="cleartextPassword" value="${password}"/>
            </bean>
        </property>
    </bean>

Thanks,

Jim

Re: Need ability to handle password "equivalent" between WSPasswordCallback and UsernameToken when it's binary data

[Colm O hEigeartaigh <co...@apache.org>]

I don't think this approach will work, as the UsernameToken class
converts the password String to an array of bytes using UTF-8
encoding, which probably isn't what you want.

What's needed is a patch to add functionality to WSS4J to add/process
passwords as arrays of bytes for the digest case, rather than
insisting on a String. Would you be interested in taking on this
patch? :-)

Colm.

On Fri, Jun 18, 2010 at 9:52 PM, Jim Utter <ju...@gmail.com> wrote:
> Per the oasis spec, the UsernamePassword is summarized by the algorithm:
>    base64(sha-1(nonce+created+password))
>
> But, n our scenario we don't store cleartext passwords - only the sha-1 hash
> of them.  The oasis spec allows this via what they claim as "..password
> equivalent".  The problem I'm running into is that our password equivalent
> is sha-1(password) or ultimately this equivalent:
>    base64(sha-1(nonce+created+sha-1(password)))
>
> When the applicability of this approach was questioned to the oasis list,
> they confirmed it:
> http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html
>
> But, when using the wss4j WSPasswordCallback mechanism, the call expects the
> password to be a string but the binary output of the digest if converted to
> a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does
> not result in the original byte array - causing any digest calculations to
> fail.
>
> Since I cannot change the framework, I was curious if there was a way to
> supercede or register the UsernameToken class with my own so I can pass a
> base64(sha-1(password)) through the current api's via the WSPasswordCallback
> mechanism and have the custom UsernameToken class perform the base64 decode
> to get the original binary bytes of the sha-1(password) we need to pass
> through.
>
> I'm also open to other suggestions and for additional context - I'm
> attempting to use the spring-ws package as a client with a custom callback
> handler like this:
>
>     <bean id="securityClientInterceptor"
> class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
>         <property name="securementActions" value="UsernameToken"/>
>         <property name="securementUsername" value="${username}"/>
>         <property name="securementUsernameTokenElements" value="Nonce
> Created"/>
>         <property name="securementPasswordType" value="PasswordDigest"/>
>         <property name="securementMustUnderstand" value="true"/>
>         <property name="securementCallbackHandler">
>             <!-- this will pre-hash the password with sha-1 before the
> password is passed through wss4j -->
>             <bean id="preHashedWSPasswordCallbackHandler"
> class="xxx.xxx.xxx.PreHashedWSPasswordCallbackHandler">
>                 <property name="cleartextPassword" value="${password}"/>
>             </bean>
>         </property>
>     </bean>
>
> Thanks,
>
> Jim
>
>

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