Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login

I see no reason why someone would call login again on an already authenticated session. I believe that Seam 2.x used to catch this and throw an exception (though I could be misremembering). Personally, I would prefer an exception over silently ignoring the call or an option such as the one below. Unless there is a valid reason to call .login again? ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org > Sent: Wednesday, January 30, 2013 7:31:33 PM > Subject: Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login > > > > Actually, I do not see a problem in customizing the behavior of > repeated login() method calls: > > something like: > > identity.setOption(Option.LOGIN_REPEAT); > credential.setCredential(x); > identity.login(); > credential.setCredential(y); > identity.login(); > > If the option is set, then the second call of login() will > authenticate again. > > By default, we want to maintain the session behavior. But if Aerogear > wants repeated login() logic, they should be able to set it in the > option? > > Feedback? > > On 01/30/2013 11:47 AM, Bruno Oliveira wrote: > > > > I still don't agree with it, we're giving the benefit of the doubt to > developers. If I have a method which is invoked twice for example > via HTTP request with the following code: > > > >>> credential.setCredential(x); > > identity.login(); > Login should >>> be validate it again, but if you think that is not a problem, >>> I'm fine. > Anil, could you please provide the final solution for it? Examples of > usage? > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 30, 2013 at 1:40 PM, Anil Saldhana wrote: > >> On 01/30/2013 09:33 AM, Bruno Oliveira wrote: >>> 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? >>> Banks get over this by frequently being proactive using >>> Javascript. If the user has been idle for a minute, they give >>> out a warning and if there is no response, they log out the >>> user. > > >>> 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. https/ssl >>> should be mandatory for all critical web applications. Just have >>> a HTTP Header agent installed for your browser. Your passwords >>> are in the clear in the http header agent if you do not use >>> https. > >>> 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 ) ( >>>>> mailto:security-dev@lists.jboss.org ) > >>>>> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev