Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login
So if I'm a bank where the user account is logged in, this user has just forgot to
'logout'. Another person using his computer can just bypass the login, because the
session still exists?
Another scenario, I'm at the same network of John, running my whatever-sniffer, then
is just a matter of grab the current session ID and login? Am I wrong? Because If
understood correctly, after user login, even if I invoke this method for a second time,
what really matters is the session ID.
I'm confused.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote:
On 01/29/2013 08:08 PM, Douglas Campos wrote:
> On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote:
> > Shane,
> > this is not a bug rather a feature request.
>
>
> it's a bug
> > Aerogear has the following sequence:
> >
> > credential.setCredential(x);
> > identity.login();
> > credential.setCredential(y);
> > identity.login();
> >
> > Aerogear wants PicketLink to reauthenticate during the second login()
> > call. Currently
> > it will not because the first login() established a User instance and
> > subsequent login()
> > calls will just bypass the auth process.
>
>
> If my API doesn't do the login process on the login() call, am I not
> failing with the "least surprise principle"? If it doesn't do all the
> login procedure when called, better rename it then: mayLogin(),
> loginWithCaching() or anything like this.
Your usage:
User user = null;
AuthenticationResult result = identity.login();
if(result == AuthenticationResult.SUCCESS){
user = identity.getUser();
} else {
throw new RuntimeException("Authentication Failed");
}
//Now identity has an user
//Irrespective of what you want to put in credential, you are
authenticated already until you logout
result = identity.login();
//result is always SUCCESS.
>
> IMO, this is not only wrong, but I think it can be used as a potential
> attack vector.
How?
>
> -- qmx
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/security-dev