> Pardon the non-answer, and my knowledge in this area is incomplete, but
> are sure it's beneficial to use a digest password? If you're using SSL
> during the UsernameToken authentication clear text should be fine.
Hi Glen, thanks for the feedback,
The digested passwords we want to use are not related to communication
security but to externalizing user information database. So out goal is to be
able to persist them into a database/external file and thus this is the reason
why we don't want them in plain text.
This way we need some machanism to be able to check them.
Thanks again anyway.
>
> As I understand from my book "SOA Security" (Manning, p.168), password
> digests should contain just not the encrypted password but also a nonce
> and a timestamp to guard against replay attacks--so it would be
> difficult to do a hash comparison between your backend data store (which
> presumably encrypts just the password) and the client's request which
> should also contain those additional fields within the hash. Also, I'm
> not sure whether your backend would allow you to obtain an unencrypted
> password so you can do the hashing and compare it against what is being
> sent from the client. I.e., if my password in an Oracle database is
> "doughnuts" that might get stored internally by Oracle as "sdlkjfa",
> which by definition of a hash would be next to impossible to un-hash
> back to "doughnuts" necessary for you to *re*hash it along with the
> nonce and timestamp to compare it to what the client is sending.
>
> Adding insult to injury, I don't believe CXF WSP's (or Metro ones for
> that matter) have implemented nonce caching yet, necessary for guarding
> against replay attacks. (AFAIK nonces are not a factor with cleartext
> passwords over SSL.)
>
> Glen
>
> On 02/02/2012 05:03 AM, Francisco Serrano wrote:
>> Hi list,
>>
>> We are trying to integrate the STS into our solution for SSO but we
>> encountered an issue that is hard to solve.
>>
>> For the moment, the token validator uses a callback to be able to
>> verify the correct username and password to deliver the token.
>>
>> The problem appears when you need to store hashed passwords and check.
>> There would be needed some mechanism no to set the current password to the
>> WSPasswordCallback to be verified directly against the string value of the
>> password but to check it agains a hashed value.
>>
>> The following code is coming from the PasswordCallbackHandler:
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> public void handle(Callback[] callbacks) throws IOException,
>> UnsupportedCallbackException {
>>
>> if (getPasswords() == null || getPasswords().size() == 0)
>> return;
>>
>> for (int i = 0; i< callbacks.length; i++) {
>> if (callbacks[i] instanceof WSPasswordCallback) { // CXF
>> WSPasswordCallback pc = (WSPasswordCallback) callbacks[i];
>>
>> String pw = getPasswords().get(pc.getIdentifier());
>> pc.setPassword(pw);
>> }
>> }
>> }
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> The correct/original password and the one provided is evaluated at the
>> UsernameTokenValidator
>> (org.apache.ws.security.validate.UsernameTokenValidator). Method:
>> verifyDigestPassword (called from the "verifyPlaintextPassword" method).
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> if (!origPassword.equals(password)) {
>> throw new
>> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
>> }
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>>
>> I could imagine that it could be set a flag to indicate that the
>> password should be checked instead of compared and also the algorithm to be
>> used for the digest check.
>>
>> Any suggestion about how this could/should be done? Any other idea?
>>
>> Thanks in advance.
>>
>> Fran.
>>
>
>
> --
> Glen Mazza
> Talend Community Coders - coders.talend.com
> blog: www.jroller.com/gmazza
>
>
