cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <>
Subject Re: STS Support for digested passwords / (MD5/SHA) check.
Date Thu, 02 Feb 2012 14:45:51 GMT
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.)


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

View raw message