ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Utter (JIRA)" <>
Subject [jira] Commented: (WSS-239) Need ability to handle password "equivalent" between WSPasswordCallback and UsernameToken when it's binary data
Date Tue, 02 Nov 2010 14:26:24 GMT


Jim Utter commented on WSS-239:

I believe this is acceptable as it solves the problem via convention (of assuming all passwords
are base64 encoded) rather than changing a ton of code.  Basically, representing the binary
password in a base64 form until it's consumed in the digest calculation is a portable method
of overloading the String password signatures to accept such an argument.  The patch I had
originally submitted was very complicated compared to this solution.  With Patrick's patch,
I would simply need to ensure I base64 encode my external password equivalent prior to passing
it into the wss4j signatures and configure wss4j to decode it prior to using it in any digest
calculations.  Unfortunately, wss4j is not the only library that handles passwords as strings
so base64 provides a consistent mechanism to move binary passwords around as long as they
can be decoded prior to being used.

Prior to seeing Patrick's post I had started to pursue another route which allowed the developer
to subclass UsernameToken and eliminated it's static methods.  This allowed me to specify
my own implementation of UsernameToken via the existing action/processor config methods and
simply overload the doPasswordDigest() signature to do basically the same thing that Patrick
is doing above as custom code (decode a base64 encoded string prior to digesting).  Thus,
the outcome would be the same - but Patrick's solution has much less code movement/refactoring.
 It would be nice to be able to overload UsernameToken methods but Patrick's solution is much
more surgical to our immediate problem and I believe would provide no risk to any backwards

> Need ability to handle password "equivalent" between WSPasswordCallback and UsernameToken
when it's binary data
> ---------------------------------------------------------------------------------------------------------------
>                 Key: WSS-239
>                 URL:
>             Project: WSS4J
>          Issue Type: Improvement
>          Components: WSS4J Core
>    Affects Versions: 1.5.8
>            Reporter: Jim Utter
>            Assignee: Ruchith Udayanga Fernando
>         Attachments: WSS-239-1_5_x-fixes.patch, wss4j-1.5.9-password-equivalence.patch
> Per the oasis spec, the UsernamePassword is summarized by the algorithm:
>    base64(sha-1(nonce+created+password))
> But, in some scenarios you 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 the 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:
> 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.
> This was originally posted in the mailing list below where Colm suggested I provide a

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message