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.
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
