Saving the credentials by browser on login page

Lukas Krejci lkrejci at redhat.com
Tue Sep 25 15:44:13 UTC 2012


What about constrained environments where users can't install their own 
browser addons?

I mean, c'mon. This is a very standard browser feature we're talking about 
here that we're preventing.

I personally can see no security threat to having a static HTML form to do the 
logging in. The server endpoints are still the same, the data passed to them 
is still the same. It's the server that does the authentication and no server 
logic is being changed here. Also, no data is stored on the client side.

Wrt XSS - maybe the exposure of the doLogin() method makes the potential 
breach a bit easier but that method always existed and was being translated 
into javascript by GWT compiler. So all Jirka did there was that he changed a 
a javascript function to have a "nicer name".

I am all for having another pair(s) of eyes on this, but I think we're being a 
bit paranoid here. 

Take a look at the diff 
http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=jkremser/loginSaving&id=36668b80ee7f8caef63bc3b6bdc10768038031e2

There is no new functionality there - it's just another way of calling the 
same method.

On Tuesday, September 25, 2012 11:11:41 John Mazzitelli wrote:
> IMO, just publish the grease monkey script and be done with it.
> 
> ----- Original Message -----
> 
> > I was under the impression that we had already decided that this was
> > a risky proposition? Typically, something like this would get
> > flagged in a code audit (manual or automated). The thing with
> > security is that you may not fully understand what you are exposing
> > as dangerous until you get hacked.   As JON can control other
> > servers it could quickly become a severe issue for a customer. Once
> > a product gets tainted by a serious security issue it is very hard
> > to recover from that kind of publicity.
> > 
> > Is there a Red Hat security team that can advise on this? Perhaps
> > standard practices...
> > 
> > 
> > -- Mike
> > 
> > On Sep 25, 2012, at 6:59 AM, Jiri Kremser <jkremser at redhat.com>
> > 
> > wrote:
> > > Hi,
> > > 
> > >  I've implemented the issue using the hidden form hack. I've found
> > >  only one example of this on the web
> > >  (http://borglin.net/gwt-project/?page_id=467, great blog btw.).
> > >  However, the example doesn't use the SmartGWT but pure GWT. They
> > >  actually use directly the hidden form for logging in by calling
> > >  FormPanel.wrap(Document.get().getElementById(LOGINFORM_ID)) and
> > >  rendering it. It wraps an existing element with pure GWT
> > >  component. SmartGWT, unfortunately, doesn't support such
> > >  functionality (I tried smartclient forum, stackoverflow and
> > >  JavaDoc :]), so I had to "mirror" the values between the two
> > >  forms (the hidden one and the SmartGWT one), and when submitting
> > >  the visible form, the submit is invoked on the hidden form too
> > >  which calls JSNI method for logging in.
> > > 
> > > It works without problems in Chrome21 and IE8. FF 10 asks for
> > > saving the credentials, but fills it only if the user access the
> > > page by pressing the logout (=> don't fill it if you access the
> > > page directly, strange).
> > > 
> > > The changes are pushed in git branch jkremser/loginSaving
> > > 
> > > Concerning security:
> > > * I had to expose the "doLogin()" function via JSNI in order to be
> > > able to call it from Java Script. doLogin() reads the credentials
> > > from the hidden form and with them performs the login(user,pass)
> > > and subsequently sends POST to portal's struts action
> > > (j_security_check.do). The only risk, I can see, is that attacker
> > > can make the hidden form visible and type the credentials directly
> > > to it (or from JavaScript) bypassing the form validation on the
> > > proper login form. However, right now we validate only if the
> > > username and password is not "".
> > > 
> > > * Credentials are NOT stored by the application logic. Browser asks
> > > the user and stores it if he/she confirms, like many other web
> > > application. Here, one can say, it is not a good practice and we
> > > should avoid it. We can discuss it. It depends, If the online
> > > banking app suggests me saving the password I would probably
> > > change the bank. I am not saying RHQ is not so critical (it may be
> > > in many cases), but don't forget it is only option. User can turn
> > > it off or use it, it is up to him. Same thing holds for securing
> > > the webapp with SSL + certificate. Because without running it on
> > > SSL it is quite funny to talk about security aspects, and send the
> > > password in plain text :]
> > > 
> > > * Other risk may come from the fact the login form (the hidden
> > > variant) is now present in the static html content, so if the
> > > webapp is hosted on public IP, some crawler or bot can potentially
> > > mark this page as hackable. Counterargument could be that the same
> > > thing is possible now after evaluating the JavaScript.
> > > 
> > > 
> > > I've also prepared the Grease Monkey script for FF and placed it to
> > > /etc/dev-utils. It fills the credentials if you press alt+c and it
> > > works well also in Chrome with Tampermonkey add-on. I haven't
> > > tried it with the IE yet.
> > > 
> > > JK
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Stefan Negrea" <snegrea at redhat.com>
> > > To: rhq-devel at lists.fedorahosted.org
> > > Sent: Wednesday, September 5, 2012 9:27:28 PM
> > > Subject: Re: Saving the credentials by browser on login page
> > > 
> > > Hello,
> > > 
> > > 
> > > This is a known issue with GWT applications and the fix is simple.
> > > This section explains well the strategy:
> > > http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurity
> > > FAQ#auto-complete_and_GWT
> > > 
> > > 
> > > Storing passwords or usernames in cookies is dangerous!
> > > 
> > > 
> > > Thank you,
> > > Stefan
> > > 
> > > ----- Original Message -----
> > > 
> > >> From: "Lukas Krejci" <lkrejci at redhat.com>
> > >> To: rhq-devel at lists.fedorahosted.org
> > >> Sent: Friday, August 31, 2012 8:16:53 AM
> > >> Subject: Re: Saving the credentials by browser on login page
> > >> 
> > >> On Friday, August 31, 2012 09:03:58 John Mazzitelli wrote:
> > >>> I would disagree that it is a "rather big" usability issue.
> > >>> Relative to all
> > >>> the other issues in the UI, I would put this low on the list.
> > >> 
> > >> Well, this one is right in the face of everybody using RHQ. It's
> > >> the
> > >> first
> > >> thing they see and there's no going around that.
> > >> Something along the lines of "they can't get right even such a
> > >> simple
> > >> thing as
> > >> password completion? They suck!"
> > >> 
> > >>> I would agree that if some solution can simply enable the browser
> > >>> to do "its
> > >>> thing", that would be nice. But I heard things like "storing the
> > >>> password
> > >>> in a cookie" and things like that - that's what I say we should
> > >>> not
> > >>> even
> > >>> entertain the thought.
> > >> 
> > >> +100
> > >> 
> > >>> If there is some magic to put some hidden dummy form
> > >>> in the page to trick the browser to remember the info using its
> > >>> normal
> > >>> mechanisms, then that would be different.
> > >> 
> > >> I actually thought this was the plan.
> > >> 
> > >>> But again, relative to everything else, this would be low on the
> > >>> list to
> > >>> implement IMO as we've got lots of other stuff that would be
> > >>> higher
> > >>> priority (is there even a BZ on this?). As Jiri mentioned
> > >>> earlier,
> > >>> for
> > >>> devs, it would probably be nice to have some a greasemonkey
> > >>> script
> > >>> to help
> > >>> out here. That would be a good solution for devs whose fingers
> > >>> hurt
> > >>> typing
> > >>> rhqadmin :}
> > >>> 
> > >>> ----- Original Message -----
> > >>> 
> > >>>> Well, this whole thing is not about us implementing some
> > >>>> convenience
> > >>>> for the users but about us NOT PREVENTING a convenience function
> > >>>> that browsers implement.
> > >>>> 
> > >>>> I see a big difference there. It is a standard feature of all
> > >>>> browsers to offer to "save passwords" on any page where people
> > >>>> put
> > >>>> in credentials. This is not possible on RHQ login page. It is
> > >>>> not
> > >>>> for us to answer the security aspects of this solution or to try
> > >>>> to
> > >>>> be "smarter" than the browsers are.
> > >>>> 
> > >>>> For me this is a rather big usability issue.
> > >>>> 
> > >>>> Lukas
> > >>>> 
> > >>>> ----- Original Message -----
> > >>>> 
> > >>>>> From: "John Mazzitelli" <mazz at redhat.com>
> > >>>>> To: rhq-devel at lists.fedorahosted.org
> > >>>>> Sent: Thursday, August 30, 2012 6:16:55 PM
> > >>>>> Subject: Re: Saving the credentials by browser on login page
> > >>>>> 
> > >>>>> IMO, I would recommend staying far away from doing anything
> > >>>>> "for
> > >>>>> convenience" that has anything to do with security. This is
> > >>>>> asking
> > >>>>> for trouble.
> > >>>>> 
> > >>>>> It is best if something like "my password was hacked" can be
> > >>>>> 100%
> > >>>>> blamed on, say, the browser or a weak password (as opposed to
> > >>>>> it
> > >>>>> being blamed on RHQ :-)
> > >>>>> 
> > >>>>> Seriously, the minute you start attempting to implement
> > >>>>> something
> > >>>>> around security like this, you WILL get people looking very
> > >>>>> closely
> > >>>>> at your code and dollars to donuts, some hole some where will
> > >>>>> be
> > >>>>> found (which I can attest to with the "convenience" feature we
> > >>>>> had
> > >>>>> for the agent token stuff a while ago that we ended up
> > >>>>> removing).
> > >>>>> 
> > >>>>> As the guy on that old TV cop show used to say, "Let's be
> > >>>>> careful
> > >>>>> out
> > >>>>> there!"
> > >>>>> 
> > >>>>> P.S. Your fingers learn to type "rhqadmin" really fast after
> > >>>>> you do
> > >>>>> it for a while. :)
> > >>>>> 
> > >>>>> ----- Original Message -----
> > >>>>> 
> > >>>>>> IMO storing the password is a poor choice (even if done
> > >>>>>> properly)
> > >>>>>> and
> > >>>>>> may not be welcomed as a feature by some organizations.
> > >>>>>> However,
> > >>>>>> storing the user name might be nice but even that should not
> > >>>>>> be
> > >>>>>> in
> > >>>>>> plain text. Here is another link to complement the link
> > >>>>>> below:
> > >>>>>> http://crackstation.net/hashing-security.htm
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Obviously this is a sensitive area.
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> HTML5 local storage is another option to cookies. Cookies get
> > >>>>>> sent
> > >>>>>> with every request including images and gwt-rpc. This way the
> > >>>>>> username would never leave the client (except for the actual
> > >>>>>> login).
> > >>>>>> FF and IE9 have support for it and there is a polyfill for
> > >>>>>> web
> > >>>>>> storage in IE8.
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> On Aug 30, 2012, at 7:36 AM, Jiri Kremser <
> > >>>>>> jkremser at redhat.com >
> > >>>>>> wrote:
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Hi,
> > >>>>>> I've found this page [1] and I am trying to get this idea
> > >>>>>> working.
> > >>>>>> Lukas suggested the values can be obtained from the hidden
> > >>>>>> form
> > >>>>>> by
> > >>>>>> JS (DOM manipulation). But there will be probably necessary
> > >>>>>> to do
> > >>>>>> the other way i.e. to fill the form and submit it with some
> > >>>>>> kind
> > >>>>>> of
> > >>>>>> no-op somehow on the background to let the browser to store
> > >>>>>> it.
> > >>>>>> Other option could be to use the cookies
> > >>>>>> com.google.gwt.user.client.Cookies.{get|set}Value() but I am
> > >>>>>> not
> > >>>>>> sure about storing the password in plaintext somewhere in the
> > >>>>>> cookie
> > >>>>>> without asking the user.
> > >>>>>> 
> > >>>>>> Browser does basically the same, but at least it asks :]
> > >>>>>> Yes, but this is not secure either.
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> 
> > >>>>>> [1]
> > >>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSec
> > >>>>>> uri
> > >>>>>> tyFAQ#auto-complete_and_GWT
> > >>>>>> _______________________________________________
> > >>>>>> rhq-devel mailing list
> > >>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>> 
> > >>>>>> 
> > >>>>>> _______________________________________________
> > >>>>>> rhq-devel mailing list
> > >>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>> 
> > >>>>> _______________________________________________
> > >>>>> rhq-devel mailing list
> > >>>>> rhq-devel at lists.fedorahosted.org
> > >>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>> 
> > >>>> _______________________________________________
> > >>>> rhq-devel mailing list
> > >>>> rhq-devel at lists.fedorahosted.org
> > >>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>> 
> > >>> _______________________________________________
> > >>> rhq-devel mailing list
> > >>> rhq-devel at lists.fedorahosted.org
> > >>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >> 
> > >> _______________________________________________
> > >> rhq-devel mailing list
> > >> rhq-devel at lists.fedorahosted.org
> > >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > 
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list