[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jaxme-dev
Subject:    Re: WSS4J UsernameToken with Plain Text Password
From:       Ruchith Fernando <ruchith.fernando () gmail ! com>
Date:       2013-01-25 14:51:48
Message-ID: CAEYTqvL=DKaX2OSwDLezrnKg8gpsXNq5i=M7r37nu_mkAnmnyA () mail ! gmail ! com
[Download RAW message or body]

Hi Colm,

Thanks for the fast response.

On Fri, Jan 25, 2013 at 4:46 AM, Colm O hEigeartaigh
<coheigea@apache.org> wrote:
> Hi Ruchith,
>
> In 1.5.x, for the digest case the WSPasswordCallback was not supplied the
> password, but instead had to supply the password to the
> UsernameTokenProcessor. For every other case, it was given the raw password
> and expected to validate it itself. This was both inconsistent, and lead to
> a security hole in leaving it up to the user CallbackHandler to make sure
> that an exception was thrown for a non-matching plaintext case.

Regarding the security hole:
Do you mean the user may throw an exception with a message such as
"Invalid Password" leading to confirmation that a user exists?
But any exception can be wrapped/logged+ swallowed at the validator
and simply use that as a signal from the callback handler about
validation failure.
Also if we don't want to use exceptions we can have a flag in the
callback instance that the user can set when validation fails.

> In 1.6.x, the WSPasswordCallback never gets the received password (by
> default). The job is to supply the matching password to the
> UsernameTokenValidator for comparison of either plaintext or digested
> password. For the case that you don't have access to the plaintext password,
> you have the option of overriding the relevant method in the
> UsernameTokenValidator and performing some custom validation.

I was under the impression that plain text password case that I
explained was the scenario that one would use all the time. This is
because most of the time we won't store the plain text passwords to
validate against incoming plain text passwords and expected it to be a
part of the default behavior. Anyway I understand that this can be
overridden.

Thanks,
Ruchith

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

[prev in list] [next in list] [prev in thread] [next in thread]